Перейти до вмісту

Docker

Матеріал з K2 ERP Wiki

- redis

! критично: контейнеризація не замінює production-архітектуру. POSTGRES_USER: app

Dev containers

  • build image;
  • run tests in container;
  • run database for integration tests;
  • push image to registry;
  • deploy by tag or digest;
  • scan image;
  • generate SBOM;
  • promote image between environments;
  • rollback. - db_data:/var/lib/postgresql/data

Локальна розробка програмного забезпечення web app

.git

  • config;
  • connection strings;
  • feature flags;
  • environment-specific settings;
  • runtime behavior. * Docker Documentation.
volumes:
- db

EXPOSE 3000 

- postgres_data:/var/lib/postgresql/data
  • застосунок;
  • runtime;
  • бібліотеки;
  • конфігурацію;
  • environment variables;
  • entrypoint;
  • filesystem layer;
  • exposed ports. У документації встановлення Docker Engine згадується Apache License, Version 2.0.== Tags і digests ==

|- | Ізоляція | На рівні ОС і namespaces | Повна guest OS через hypervisor |- | Розмір | Зазвичай менший | Зазвичай більший |- | Старт | Швидкий | Повільніший |- | Kernel | Ділить kernel із host | Має власне guest OS kernel |- | Типовий сценарій | Application packaging | Повна ізольована ОС |}

RUN addgroup -S app && adduser -S app -G app Практична роль: якщо завтра знайдуть уразливість у бібліотеці, SBOM допоможе оперативно зрозуміти, чи виступає як вона у вашому image. `--privileged` дає контейнеру дуже широкі права. POSTGRES_PASSWORD: secret

Docker Compose — інструмент для опису й запуску multi-container applications.

</syntaxhighlight>

Підказка: найкращий перший Docker-сценарій — підняти локальні залежності проєкту через Compose: базу, кеш і застосунок. через це платформа контейнеризації, яка користувачі можуть розробляти, пакувати, доставляти й запускати застосунки в ізольованих середовищах, які називаються контейнерами виступає ключовою рисою Docker. Команда описує середовище розробки в контейнері, щоб усі мали однакові версії інструментів. ! Типові network modes:

Приклад:

Docker Engine — це основна технологія Docker для створення й запуску контейнерів. Контейнер — це ізольований бізнес-процес або група процесів, які запускаються з Docker image.

Приклад: 

POSTGRES_PASSWORD: secret
  • Docker Engine;
  • Docker CLI;
  • Docker Compose;
  • GUI;
  • Kubernetes у частині сценаріїв;
  • інтеграцію з файловою системою;
  • керування images і containers;
  • extensions;
  • конфігурація resources;
  • інтеграцію з WSL 2 на Windows.</syntaxhighlight>

Secrets

Production deployment

HEALTHCHECK дає можливість Docker або orchestrator зрозуміти, чи контейнер здоровий. POSTGRES_USER: app

  • license compliance;
  • vulnerability management;
  • supply chain security;
  • audits;
  • incident response;
  • dependency tracking;
  • enterprise governance;
  • customer requirements. USER app

Privileged containers

WORKDIR /app критично: image scanning не гарантує безпеку. docker run -e NODE_ENV=production -e PORT=3000 my-app:1.0

Практична роль: Compose дає можливість підняти цілий маленький “світ застосунку” однією командою. * локальних dev environments;

  • multi-service apps;
  • test stacks;
  • databases;
  • queues;
  • cache;
  • reverse proxy;
  • small deployments у частині сценаріїв. HEALTHCHECK --interval=30s --timeout=3s \
  • однакове dev/test/prod середовище;
  • оперативно піднімати залежності;
  • пакувати застосунок із dependencies;
  • запускати integration tests;
  • використовувати CI/CD;
  • створювати microservices;
  • запускати локальний PostgreSQL або Redis;
  • робити reproducible builds;
  • деплоїти container images;
  • працювати з Kubernetes;
  • спростити onboarding;
  • ізолювати toolchains.

Практична роль: Docker network дає можливість контейнерам спілкуватися між собою без ручного прописування IP-адрес. Для реального використання потрібно розрізняти open source компоненти, desktop-продукти, hosted services і commercial features. Docker розробників. CMD ["node", "server.js"]

Офіційна документація Docker описує Docker як open platform for developing, shipping, and running applications.

Docker CLI

Docker дає ізоляцію, але контейнер не виступає як абсолютним security boundary.</syntaxhighlight>

Digest — це content-addressed ідентифікатор image. Docker має власну network model. Якщо він залежить від випадкових ручних кроків, Docker втрачає одну зі своїх головних переваг. :contentReference [oaicite:2]{index=2}

У цьому прикладі `app` здатна звертатися до `redis` за hostname `redis`. docker stop container_name 

== Docker logs ==

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

== Контейнер ==

Краще використовувати:

* публікації images;
* завантаження official images;
* private repositories;
* automated builds у частині сценаріїв;
* image tags;
* team collaboration;
* base images;
* open source images;
* CI/CD.== Docker і Kubernetes ==

</syntaxhighlight> Multi-stage build дає можливість мати кілька етапів у Dockerfile й переносити в фінальний image тільки потрібні файли. * порт 8080 на host;

  • перенаправляється в порт 80 контейнера. Для публікації потрібен `-p` або відповідна Compose-конфігурація. FROM alpine:3.22

Для production критично: my-app:2026-05-09 Контейнер зазвичай містить: dist 

- "8000:8000"

Docker CLI застосовується для для: volumes: Приклад:

</syntaxhighlight>

docker version 

COPY . Контейнер із доступом до Docker socket часто фактично отримує контроль над host. :contentReference [oaicite:7]{index=7}
* Docker Compose починався як зручний інструмент для локальних multi-container stacks, але став стандартною частиною багатьох dev workflows. Docker зазвичай фокусується на application containers. Resource limits корисні для:
== Docker Image ==

Image містить:

Docker Compose застосовується для для:

  • orchestration;
  • monitoring;
  • logging;
  • backups;
  • secrets;
  • image scanning;
  • healthchecks;
  • restart policies;
  • resource limits;
  • network policies;
  • storage;
  • updates;
  • rollback;
  • registry availability;
  • base image maintenance.

</syntaxhighlight>

Сценарії:

Практична роль: Docker CLI — це провідний інструмент розробника для швидкої роботи з контейнерами.== Тематичні мітки ==

  • Docker Engine;
  • Docker CLI;
  • Docker Desktop;
  • Docker Compose;
  • Docker Hub;
  • Docker Scout;
  • Docker Hardened Images;
  • commercial services.== Docker і ліцензії ==
  • захисту host;
  • стабільності;
  • multi-service environments;
  • production isolation;
  • тестування поведінки при нестачі ресурсів;
  • cost control. Для компанії це потрібно перевіряти окремо. Docker CLI — command-line інтерфейс для роботи з Docker.

Resource limits

Практична роль: image — це “зліпок” застосунку, а container — запущений екземпляр цього зліпка. !

CMD ["./app"]

критично: healthcheck має перевіряти реальну готовність сервісу, а не без зусиль факт, що бізнес-процес ще не завершився. Помилка: думати, що Docker автоматизовано робить застосунок безпечним, масштабованим і production-ready. Це інтуїтивно, але ризиково. Офіційна довідка Docker описує Dockerfile як файл, що визначає вміст і startup behavior одного контейнера.
COPY .
  • secret manager;
  • Docker secrets у Swarm-сценаріях;
  • Kubernetes Secrets із додатковим захистом;
  • cloud secret managers;
  • BuildKit secrets для build-time secrets;
  • least privilege credentials. ports:
критично: bind mount дає контейнеру доступ до host-файлів.
Container registry — це сховище для container images. Він дуже сильний у відтворюваності, пакуванні, ізоляції залежностей і developer experience, але потребує правильних практик: `.dockerignore`, non-root users, volumes для даних, image scanning, secrets management, healthchecks, resource limits і продуманий deployment.
'''Практична роль:''' цей Compose-файл піднімає застосунок і базу як один локальний stack.</div>

docker logs -f app

<syntaxhighlight lang="bash">
</div>

Приклад:

* `FROM`;
* `WORKDIR`;
* `COPY`;
* `RUN`;
* `ENV`;
* `ARG`;
* `EXPOSE`;
* `CMD`;
* `ENTRYPOINT`;
* `USER`;
* `HEALTHCHECK`. Не монтуйте чутливі директорії без потреби. POSTGRES_DB: appdb

WORKDIR /app

docker run --memory=512m --cpus=1.0 my-app:1.0

* контейнер не виступає як повною VM;
* security boundary не абсолютний;
* storage для stateful apps складний;
* networking здатна заплутувати;
* Docker Desktop здатна споживати багато ресурсів;
* неправильні images можуть бути небезпечними;
* secrets швидко випадково включити в image;
* production потребує orchestration і monitoring;
* debugging іноді складніший;
* Windows/macOS використовують додатковий virtualization layer;
* root і privileged containers створюють ризики;
* image bloat здатна уповільнювати builds і deploy. Монолітний застосунок так само можна контейнеризувати. CI збирає Docker image, запускає тести, сканує image і пушить його в registry. Для production часто краще pin version або digest, а не покладатися на `latest`. Порти дозволяють відкрити сервіс контейнера назовні. docker buildx build --platform linux/amd64,linux/arm64 -t my-app:1.0 .</div>
'''LXC''' — Linux containers на нижчому рівні, які часто більше схожі на lightweight system containers.== Dockerfile ==

* локальної розробки;
* збірки images;
* простих контейнерів;
* Compose-сценаріїв;
* навчання container basics. Docker здатна бути не найкращим вибором, якщо:

</div>

Приклад:

Приклад:

Scan image 

* database passwords;
* API keys;
* tokens;
* private keys;
* certificates;
* cloud credentials. WORKDIR /src

ports:

Image scanning

EXPOSE 8000

docker run -p 8080:80 nginx:latest

Scanning оптимізує перевіряти: 

'''Docker Swarm''' — вбудований у Docker підхід до orchestration, який дає можливість керувати кластером Docker nodes.

Приклад:

</syntaxhighlight>

FROM golang:1.24-alpine AS build

  • Docker daemon;
  • Docker CLI;
  • REST API;
  • container runtime;
  • image management;
  • networking;
  • volumes;
  • build functionality;
  • registry interaction.

RUN pip install --no-cache-dir -r requirements.txt 

postgres_data:

Приклад: Kubernetes краще для:

Розробник запускає застосунок, PostgreSQL і Redis через Docker Compose, не встановлюючи всі залежності напряму в систему. Docker часто використовують у microservices architecture. Практична роль: запуск від non-root user зменшує ризики, якщо застосунок або dependency має вразливість. Kubernetes додає:

Основні команди: Dockerfile — це файл інструкцій для збірки Docker image. Критерій

docker pull postgres:18 

environment:

Тести піднімають тимчасову базу даних у контейнері, проганяють сценарії й видаляють середовище після завершення. Бази даних можна запускати в Docker, особливо для локальної розробки й тестів. {| class="wikitable"

Healthcheck

Критично: privileged container сильно зменшує ізоляцію. :contentReference [oaicite:4]{index=4} 

redis:

Docker добре підходить, якщо потрібно:

* base image;
* installed packages;
* application files;
* dependencies;
* environment variables;
* metadata;
* default command;
* exposed ports;
* filesystem layers. '''SBOM''' або '''Software Bill of Materials''' — список компонентів у software artifact, зокрема container image. docker ps
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== Docker і Podman ==
! Virtual machine

</div>

Приклад логіки:

! environment:
 environment:
== Docker і LXC ==

Приклад:

Висновок: Docker легший і швидший для застосунків, а VM краще, коли потрібна повна ізоляція ОС або інша guest operating system.=== Integration tests ===

Практична роль: Docker Engine — це “двигун”, який реально створює, запускає, зупиняє й керує контейнерами.

nginx:1.27-alpine Висновок: Docker зручніший для пакування застосунків, а LXC — для сценаріїв, ближчих до легкої віртуалізації Linux-систем. Docker

конкурентні переваги Docker

depends_on:

Рекомендовано: 

db:

POSTGRES_DB: appdb

Цікавий факт

критично: не кожен image у registry виступає як безпечним або офіційним. Вона дає можливість пакувати застосунки з їхніми залежностями в images, запускати їх як containers, описувати середовище через Dockerfile і Docker Compose, використовувати registries, цифровізувати CI/CD і спрощувати шлях від локальної розробки до production.</syntaxhighlight>

Приклад простого Docker Compose

! Build Docker image

Проста аналогія: multi-stage build — це як приготувати їжу на кухні, але в коробку покласти тільки готову страву, а не всю кухню. Docker-проєкти часто працюють із секретами: Добрі сценарії: RUN addgroup -S app && adduser -S app -G app

Приклад:

Docker дає можливість переглядати logs контейнера. Run tests BuildKit дає: 

db_data:

|-
| технічна архітектура
| Зазвичай daemon-based
| Daemonless підхід
|-
| Rootless
| Підтримується, але історично Docker часто асоціювали з daemon
| Сильний rootless focus
|-
| CLI
| Docker CLI
| Docker-compatible команди в багатьох сценаріях
|-
| Ecosystem
| Дуже широка
| Сильна в Linux/Red Hat ecosystem
|}

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Compose зручний для локальної розробки, де застосунку потрібні кілька сервісів. * Docker Engine release notes. * Docker security documentation. * Docker Engine documentation. Приклад:
COPY package*.json ./
'''критично:''' Dockerfile має бути відтворюваним. Сьогодні Kubernetes значно популярніший для великих production-сценаріїв, але Swarm здатна бути простішим для невеликих Docker-native кластерів.</div>
 db:
</div>

Docker Engine version 29 виступає як актуальною гілкою release notes, у якій Docker публікує зміни, known issues і fixes. services:

<syntaxhighlight lang="bash">
Deploy to staging
Registry зберігає:
Це означає:
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
docker run --privileged some-image
</div>
 DATABASE_URL: postgres://app:secret@db:5432/appdb
 CMD wget -qO- http://localhost:3000/health || exit 1
</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== BuildKit ==
== Загальний SEO-опис ==

docker info

'''Критично:''' якщо `.env`, private keys або tokens потрапили в image layer, їх здатна бути складно на 100% прибрати з історії image. * Docker Compose file reference. SBOM корисний для:
'''Перевага:''' Docker дає можливість описати середовище застосунку як код, а не як список ручних команд на сервері.== Див. так само ==

* volumes;
* backups;
* restore;
* disk performance;
* upgrades;
* monitoring;
* replication;
* graceful shutdown;
* data corruption risks;
* orchestration. Swarm здатна використовуватися для:

Container image scanning шукає відомі вразливості в base image і packages. '''критично:''' tag здатна змінитися, а digest вказує на конкретний вміст.</div>

Погані практики:

Можливі проблеми:
volumes:
COPY package*.json ./

</div>

'''Головна думка:''' Docker — це не без зусиль спосіб “запустити щось у контейнері”.</div>
!<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
Docker дуже часто застосовується для в CI/CD.<syntaxhighlight lang="dockerfile">
docker images

<syntaxhighlight lang="yaml">
Docker краще для:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

 app:

`.dockerignore` виключає файли з build context. Docker популяризував підхід, де застосунок описується через Dockerfile, збирається в image, пушиться в registry і запускається через одну команду.== Docker і віртуальні машини ==

services:

Docker-контейнери й virtual machines вирішують схожі, але різні задачі. У production його потрібно уникати, якщо немає чіткої й перевіреної причини. * класти secrets у Dockerfile;
* комітити `.env`;
* передавати secrets через build args без захисту;
* друкувати secrets у logs;
* зберігати secrets у image layers;
* використовувати один secret для всіх середовищ. Але мікросервіси додають:

Застосунок деплоїться як image з конкретним tag або digest, а rollback означає повернення до попереднього image. services:
 - "3000:3000"
== Обмеження Docker ==
Потрібно контролювати:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Run checks
docker rm container_name
</div>
</div>
== Docker і мікросервіси ==

</div>

* запуску контейнерів;
* збірки образів;
* перегляду логів;
* керування volumes;
* керування networks;
* роботи з registry;
* debugging;
* автоматизації;
* CI/CD. Docker корисний не лише для мікросервісів.== CI/CD ==
docker build -t my-app . build: . Саме ця простота зробила контейнери звичним інструментом навіть для невеликих команд. * Документація щодо containers, images, registries, volumes, networks, BuildKit, multi-stage builds, CI/CD, Kubernetes, Docker Swarm, SBOM і container security. * Docker добре підходить і для монолітів, і для мікросервісів. .== Registry ==
FROM node:22-alpine
COPY . Docker дає можливість відокремлювати застосунки від інфраструктури, щоб швидше доставляти програмне забезпечення (ПЗ). {| class="wikitable"
Приклад:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

'''Головна перевага:''' Docker робить середовище застосунку частиною самого проєкту, а не усною інструкцією для адміністратора.== Висновок ==
</div>
CMD ["node", "server.js"]

CMD ["python", "app.py"]

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* копіювати весь проєкт без `.dockerignore`;
* класти `.env` у image;
* використовувати `latest` скрізь;
* запускати усе від root;
* робити один гігантський image;
* не розуміти різницю між image і container;
* втрачати інформаційні дані через відсутність volume;
* плутати container port і host port;
* не читати logs;
* не налаштовувати healthcheck;
* використовувати privileged container без потреби;
* монтувати Docker socket у контейнер;
* не оновлювати base images;
* не сканувати images;
* не розуміти, що Compose не дорівнює Kubernetes.== Root user у контейнері ==

 DATABASE_URL: postgres://app:secret@db:5432/appdb

<syntaxhighlight lang="bash">
'''Найлюдяніший факт:''' Docker — це спосіб перестати сперечатися, у кого яка реліз системи Node, Python або PostgreSQL стоїть локально, і без зусиль запустити однакове середовище. Docker Engine виступає як open source container engine, а Docker Desktop — окремий desktop-продукт із власними умовами використання.</div>
Це корисно для:
Для Compose сервіси в одній мережі можуть звертатися один до одного за service name. * reproducible environments;
* швидкий запуск контейнерів;
* ізоляція залежностей;
* Dockerfile як infrastructure-as-code;
* Docker Compose для локальних stacks;
* велика ecosystem;
* Docker Hub і registries;
* CI/CD-friendly workflow;
* multi-stage builds;
* BuildKit;
* простіший onboarding;
* зручність для microservices;
* переносимість між середовищами;
* менше ручної інсталяції на сервері;
* зручність для тестування. * менший final image;
* менше build tools у production image;
* менша attack surface;
* чистіша структура;
* швидші deployments.<syntaxhighlight lang="text">
конкурентні переваги:
'''Практична порада:''' якщо застосунку не потрібен root, не запускайте його від root. * Docker reference documentation. docker run hello-world
'''Практична роль:''' dev container оптимізує новому розробнику стартувати не за день налаштувань, а за кілька команд. Image складається з шарів і зазвичай створюється з Dockerfile.</div>
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>

 volumes:

'''Практична порада:''' без resource limits один контейнер здатна з’їсти більше пам’яті або CPU, ніж ви очікували. -v pgdata:/var/lib/postgresql/data \
COPY . depends_on:

docker volume create pgdata

'''Podman''' — альтернатива Docker для запуску контейнерів, популярна в Linux-середовищах. RUN npm ci --omit=dev

WORKDIR /app

== Bind mounts ==
== Коли Docker здатна бути невдалим вибором ==
== Docker Hub ==
'''Проста аналогія:''' контейнер — це не цілий будинок, а окрема кімната з потрібними інструментами, яка ділить фундамент із будівлею. :contentReference [oaicite:5]{index=5}

COPY --from=build /src/app /app/app

docker pull redis:latest

== Коли варто використовувати Docker ==

* швидші builds;
* кращий cache;
* parallel build steps;
* secrets під час build;
* SSH forwarding;
* multi-platform builds;
* better output;
* advanced Dockerfile features;
* buildx. environment:

'''критично:''' Docker Engine і Docker Desktop — не одне й те саме. .

Healthcheck корисний для:

  • orchestration;
  • scheduling;
  • services;
  • deployments;
  • scaling;
  • rolling updates;
  • config maps;
  • secrets;
  • persistent volumes;
  • cluster management;
  • self-healing. Docker дає можливість зібрати застосунок разом із його залежностями в образ і запускати його однаково на різних машинах: ноутбуці розробника, тестовому сервері, CI/CD, хмарі або production-інфраструктурі. Іноді найкращий перший крок — без зусиль добре контейнеризований моноліт. * bridge;
  • host;
  • none;
  • overlay;
  • macvlan;
  • custom bridge networks. До Docker контейнеризація вже існувала у світі Linux забезпечується через Docker не винайшов саму ідею контейнерів, але зробив її масовою; так само реалізовано але була складнішою, менш зручною й не мала такого простого developer experience. Основна ідея: Docker пакує застосунок і його залежності в контейнер, щоб він запускався передбачувано, а не “тільки на моєму комп’ютері”. Практична роль: registry — це як складський облік контейнерних образів, з якого production або CI/CD бере потрібні версії. Контейнер має власну файлову систему, network namespace, process namespace і набір налаштувань, але використовує ядро host-системи. Це спосіб зробити середовище застосунку відтворюваним, переносимим і керованим. Критично: secrets не варто бездумно зберігати в environment variables, особливо в shared environments. image: postgres:18
build: . :contentReference [oaicite:3]{index=3}

Це здатна бути потрібно для деяких low-level або lab-сценаріїв, але в production зазвичай небажано. Docker Hub — популярний registry для Docker images. Практична роль: Docker робить CI/CD чистішим, бо pipeline функціонує з конкретним artifact — container image. :contentReference [oaicite:1]{index=1}

Багато container images за замовчуванням запускають бізнес-процес від root. WORKDIR /app

Dev container — контейнеризоване середовище розробки. * Docker Hub;

  • GitHub Container Registry;
  • GitLab Container Registry;
  • Amazon ECR;
  • Google Artifact Registry;
  • Azure Container Registry;
  • self-hosted registry;
  • Harbor;
  • private enterprise registry. Він легший, швидше стартує й використовує менше ресурсів, але має іншу модель ізоляції. Критично: якщо secret потрапив у image layer, просте видалення файлу в наступному Dockerfile-кроці здатна не прибрати його з історії. * Docker overview.
  • застосунок дуже простий і не має складних dependencies;
  • потрібна повна VM-ізоляція;
  • потрібна GUI-heavy desktop application без спеціальної підготовки;
  • команда не готова вчити container basics;
  • production storage не продуманий;
  • потрібно запускати системні сервіси як у повній ОС;
  • security policy забороняє Docker daemon;
  • потрібна дуже проста static deployment без runtime;
  • проблему можна вирішити пакетним менеджером або single binary. Критерій
  • OS packages;
  • language dependencies;
  • CVE;
  • outdated libraries;
  • risky images;
  • supply chain;
  • policy compliance;
  • SBOM. критично: Docker — сильний інструмент, але не кожен проєкт потребує контейнеризації. * Dockerfile reference. Docker container
  • однакових toolchains;
  • швидкого onboarding;
  • VS Code Dev Containers;
  • ізоляції dependencies;
  • різних версій мов;
  • навчальних середовищ;
  • reproducible development;
  • командної роботи. ! * Контейнер здатна стартувати за секунди, бо не завантажує повну guest OS як VM. Docker — це одна з найважливіших платформ контейнеризації для сучасної розробки. * Docker Build documentation. .</syntaxhighlight>

</syntaxhighlight> image@sha256:...== Docker Network ==

  • кожен сервіс має свій image;
  • незалежні dependencies;
  • простіше scaling;
  • CI/CD по сервісах;
  • isolation;
  • легше локально підняти stack через Compose;
  • deployment через Kubernetes або інший orchestrator.== Docker Compose ==

Практична роль: BuildKit робить Docker builds швидшими, безпечнішими й краще придатними для CI/CD. Офіційна документація описує Docker Engine як open source containerization technology for building and containerizing applications. RUN npm ci --omit=dev Deploy to production

Docker Engine виступає як open source containerization technology. критично: Docker полегшує мікросервіси, але не робить distributed systems простими. :contentReference [oaicite:6]{index=6}

Environment variables

  • однакове середовище;
  • простіший deploy;
  • isolation dependencies;
  • rollback через image tag;
  • CI/CD;
  • локальна розробка програмного забезпечення;
  • staging parity;
  • менше “works on my machine”. Docker Desktop — це застосунок для Windows, macOS і Linux, який спрощує використання Docker на робочому комп’ютері.=== Dev container ===
  • створити non-root user;
  • використовувати `USER`;
  • мінімізувати capabilities;
  • не запускати privileged container;
  • не монтувати host filesystem без потреби;
  • використовувати read-only root filesystem у частині сценаріїв. Приклад:

Небезпека: найболючіша помилка Docker-початківця — видалити контейнер із важливими даними й тільки потім дізнатися, що volume не був налаштований.== Безпека Docker == docker run -d \ Docker Engine складається з: node_modules

Джерела

Практична порада: Docker варто обирати, коли проблема звучить як “нам потрібне однакове середовище для запуску застосунку”.== SBOM ==

Docker Engine

<syntaxhighlight lang="bash">

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* локальної розробки;
* live reload;
* тестування;
* доступу до локальних файлів;
* dev containers;
* build tasks. Podman

конкурентні переваги для моноліту:

 app:
Docker Hub застосовується для для:
Контейнер не виступає як повною віртуальною машиною.<syntaxhighlight lang="yaml">

* network complexity;
* distributed tracing;
* service discovery;
* versioning;
* observability;
* latency;
* data consistency;
* operational complexity. web:
Docker застосовується для для:
Приклад:

Docker часто застосовують, коли потрібно для створення container images, які потім запускаються в Kubernetes. Docker Engine має client-server архітектуру. '''Bind mount''' підключає директорію host-системи в контейнер. Dockerfile здатна містити:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
=== CI pipeline ===
== Volumes ==
== Docker Desktop ==

'''Критично:''' не монтуйте Docker socket у контейнер без дуже вагомої причини. !</div>

Docker Desktop зазвичай містить:

'''критично:''' ліцензування Docker Engine і умови Docker Desktop або Docker Hub можуть відрізнятися.</div>

docker pull nginx:alpine

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

* local PostgreSQL;
* test MySQL;
* Redis для dev;
* integration tests;
* temporary databases;
* demo environments. docker pull nginx:latest

* images;
* tags;
* digests;
* layers;
* metadata;
* signatures у відповідних сценаріях;
* vulnerability scan results у частині платформ. * `latest` — це без зусиль tag, а не гарантія найкращої або стабільної версії. * monitoring;
* restart policies;
* orchestration;
* load balancers;
* production diagnostics;
* zero-downtime deployment;
* readiness/liveness logic у ширших платформах. * Docker image складається з шарів, тому порядок інструкцій у Dockerfile впливає на cache і швидкість build.== .dockerignore ==
Краще:
'''Цікавий факт:''' Docker не змушує переходити на мікросервіси. * production orchestration;
* multi-node clusters;
* service discovery;
* autoscaling;
* complex deployments;
* cloud-native platforms. {| class="wikitable"

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

</div>

USER app
 image: postgres:18
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  • локальної розробки;
  • запуску залежностей, як приклад PostgreSQL, Redis або RabbitMQ;
  • CI/CD pipeline;
  • тестування;
  • microservices;
  • web applications;
  • API;
  • background workers;
  • build environments;
  • DevOps;
  • deployment;
  • cloud workloads;
  • Kubernetes images;
  • reproducible environments;
  • навчальних лабораторій;
  • ізоляції застосунків;
  • швидкого запуску сервісів. docker run --rm -v "$PWD":/app -w /app node:22-alpine npm test
Приклад небезпечного запуску:

Docker має обмеження. Приклад:

Docker image tag — це людська назва версії, як приклад:

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Push to registry

== Docker і бази даних ==
.env
Потрібно продумати:
 - db
|-
| базовий фокус
| Application containers
| System containers
|-
| Типовий image
| Один застосунок або сервіс
| Ближче до повної Linux-системи
|-
| Developer workflow
| Dockerfile, images, registry
| Більш системний контейнерний підхід
|}

 build: .</div>
<syntaxhighlight lang="bash">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

<syntaxhighlight lang="bash">

Воно корисне для:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Цікаві факти про Docker ==
== Хороші практики Docker ==
Поширені помилки:
Але Docker ecosystem ширший за Docker Engine:

{{SEO
|title=Docker — платформа контейнеризації для застосунків, образів, Dockerfile, Compose, Docker Engine і DevOps
|description=Docker — Wiki-стаття про платформу контейнеризації для розробки, доставки й запуску застосунків. Розглянуто Docker Engine, Docker Desktop, Docker CLI, Dockerfile, Docker Image, Docker Container, Docker Compose, Docker Hub, registry, volumes, networks, BuildKit, multi-stage builds, Dockerfile best practices, Docker Swarm, Kubernetes, безпеку, CI/CD, DevOps, переваги, обмеження, цікаві факти і хороші практики.
|keywords=Docker, Docker Engine, Docker Desktop, Docker CLI, Dockerfile, Docker Image, Docker Container, Docker Compose, Docker Hub, containerization, containers, container image, registry, volume, Docker network, BuildKit, multi-stage build, Docker Compose file, Docker Engine 29, DevOps, CI/CD, Kubernetes, Docker Swarm, container security
|alternativeTo=віртуальні машини для легших application packaging сценаріїв; ручне встановлення залежностей на сервер; Vagrant для частини dev environment задач; system packages без ізоляції; Kubernetes для простих локальних сценаріїв; Podman у Docker-compatible workflows; LXC для application container packaging; bare-metal deployment без reproducibility; складні shell scripts для розгортання застосунків
}}

* писати logs у stdout/stderr;
* збирати logs централізовано;
* не зберігати важливі logs лише в контейнері;
* контролювати log rotation;
* не писати secrets у logs. docker run -p 8080:80 nginx:alpine

Docker у production потребує дисципліни. `.dockerignore` дуже важливий.<syntaxhighlight lang="text">
Приклад:

== Приклад безпечнішого Dockerfile-фрагмента ==

postgres:18

</div>

* base images;
* vulnerability scanning;
* non-root users;
* capabilities;
* seccomp;
* AppArmor або SELinux;
* read-only filesystem;
* secrets;
* network exposure;
* mounted volumes;
* Docker socket;
* image provenance;
* supply chain;
* registry access;
* updates. Code push
== Multi-stage builds ==

RUN go build -o app ./cmd/app Docker став одним із головних інструментів сучасного DevOps, cloud-native розробки, microservices, CI/CD і локальних середовищ розробки. EXPOSE 3000 

Environment variables часто використовують для конфігурації контейнерів.</div>
Вони корисні для:
coverage

'''BuildKit''' — сучасний backend для збірки Docker images. --name db \
  • .log

Приклади сценаріїв використання

  • менших build contexts;
  • швидших builds;
  • захисту secrets;
  • чистіших images;
  • уникнення випадкового копіювання зайвого.</syntaxhighlight>

критично: Docker Swarm простіший за Kubernetes, але має меншу ecosystem і менше поширення в сучасному cloud-native production. Для секретів краще використовувати secret manager або спеціальні механізми платформи. Для важливих даних потрібні volumes, backups і перевірений restore.== Docker і моноліт ==

критично: `EXPOSE` у Dockerfile документує порт, але не завжди відкриває його назовні. Registry здатна бути:

Bind mounts корисні для:

Проста різниця: Docker оптимізує створити й запустити контейнер, а Kubernetes керує великою кількістю контейнерів у кластері. COPY requirements.txt . Вона лише пакує й запускає застосунок зручніше.

критично: для production краще додати non-root user, healthcheck, точні dependency versions і не копіювати зайві файли.== Docker Swarm == 

postgres:18

</syntaxhighlight> FROM node:22-alpine 

'''Найлюдяніший факт:''' Docker став популярним не тому, що контейнери були новими, а тому, що він зробив їх зрозумілими для звичайного розробника. '''Висновок:''' Docker має найширше developer adoption, а Podman часто цікавий там, де важливий daemonless і rootless Linux-підхід. конкурентні переваги:
FROM python:3.13-slim
'''Практична роль:''' у контейнерному світі лог краще сприймати як потік подій, який забирає зовнішня платформа логування. Офіційна довідка Docker описує Compose file як файл, що визначає multi-container application. * Найбільша сила Docker — не “магічна ізоляція”, а повторюваність середовища. '''Головне правило:''' хороший Docker-проєкт має маленький image, зрозумілий Dockerfile, безпечні secrets, reproducible build і чіткий шлях до deployment. '''Docker Image''' — це шаблон, з якого запускаються контейнери. Критерій

'''Критично:''' якщо контейнер видалити, його writable layer здатна зникнути. * Docker Hub documentation. image: redis:latest
== Типові помилки початківців ==
== Docker у production ==

== Приклад простого Dockerfile для Python ==
<syntaxhighlight lang="bash">
docker logs app

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* баз даних;
* uploaded files;
* кешів;
* persistent data;
* logs у частині сценаріїв;
* shared data між контейнерами;
* local development state. Потрібно перевіряти джерело, теги, оновлення версій й репутацію image. '''Docker volume''' — механізм для збереження даних поза життєвим циклом контейнера.== Ports ==

Основні конкурентні переваги Docker:

</div>

* services;
* replicated containers;
* overlay networks;
* rolling updates;
* secrets;
* configs;
* простіших cluster deployments. * Docker зробив контейнери масовим developer tool, хоча Linux-контейнери існували й до нього. '''Критично:''' база даних у контейнері — це нормально, але інформаційні дані мають жити не “в контейнері”, а в правильно керованому storage з backup.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

depends_on:

Контейнери можуть обмежувати CPU і memory. LXC

Volumes використовують для:

  • використовувати `.dockerignore`;
  • не зберігати secrets в image;
  • не використовувати `latest` у production без контролю;
  • робити multi-stage builds;
  • запускати бізнес-процес від non-root user;
  • мінімізувати base image;
  • оновлювати base images;
  • сканувати images;
  • використовувати healthchecks;
  • писати logs у stdout/stderr;
  • використовувати volumes для persistent data;
  • обмежувати resources;
  • не монтувати Docker socket без потреби;
  • pin versions або digests;
  • використовувати CI/CD для build і push;
  • документувати Compose setup;
  • видаляти непотрібні images і volumes обережно. . Він знаходить відомі проблеми, але не замінює code review, тестування й threat modeling. Для production потрібно уважно продумати:

Приклад:

Docker не виступає як магічною заміною архітектури, безпеки, backup або моніторингу. * Dockerfile описує не тільки файли image, а й startup behavior контейнера. * Контейнеризація

Отримано з https://wiki.kyiv.ua/index.php?title=Docker&oldid=1354