Docker

Docker — це платформа контейнеризації, яка допомагає розробляти, пакувати, доставляти й запускати застосунки в ізольованих середовищах, які називаються контейнерами. Docker дозволяє зібрати застосунок разом із його залежностями в образ і запускати його однаково на різних машинах: ноутбуці розробника, тестовому сервері, CI/CD, хмарі або production-інфраструктурі.

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

Основна ідея: Docker пакує застосунок і його залежності в контейнер, щоб він запускався передбачувано, а не “тільки на моєму комп’ютері”.

Цікавий факт

Docker не винайшов саму ідею контейнерів, але зробив її масовою для розробників. До Docker контейнеризація вже існувала у світі Linux, але була складнішою, менш зручною й не мала такого простого developer experience.

Docker популяризував підхід, де застосунок описується через Dockerfile, збирається в image, пушиться в registry і запускається через одну команду. Саме ця простота зробила контейнери звичним інструментом навіть для невеликих команд.

Найлюдяніший факт: Docker став популярним не тому, що контейнери були новими, а тому, що він зробив їх зрозумілими для звичайного розробника.

Загальний опис

Офіційна документація Docker описує Docker як open platform for developing, shipping, and running applications. Docker дозволяє відокремлювати застосунки від інфраструктури, щоб швидше доставляти програмне забезпечення. :contentReference[oaicite:1]{index=1}

Docker використовується для:

локальної розробки;
запуску залежностей, наприклад PostgreSQL, Redis або RabbitMQ;
CI/CD pipeline;
тестування;
microservices;
web applications;
API;
background workers;
build environments;
DevOps;
deployment;
cloud workloads;
Kubernetes images;
reproducible environments;
навчальних лабораторій;
ізоляції застосунків;
швидкого запуску сервісів.

Перевага: Docker дозволяє описати середовище застосунку як код, а не як список ручних команд на сервері.

Docker Engine

Docker Engine — це основна технологія Docker для створення й запуску контейнерів. Офіційна документація описує Docker Engine як open source containerization technology for building and containerizing applications. Docker Engine має client-server архітектуру. :contentReference[oaicite:2]{index=2}

Docker Engine складається з:

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

Docker Engine version 29 є актуальною гілкою release notes, у якій Docker публікує зміни, known issues і fixes. :contentReference[oaicite:3]{index=3}

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

Docker Desktop

Docker Desktop — це застосунок для Windows, macOS і Linux, який спрощує використання Docker на робочому комп’ютері.

Docker Desktop зазвичай включає:

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

Важливо: Docker Engine і Docker Desktop — не одне й те саме. Docker Engine є open source container engine, а Docker Desktop — окремий desktop-продукт із власними умовами використання.

Docker CLI

Docker CLI — command-line інтерфейс для роботи з Docker.

Основні команди:

docker version
docker info
docker run hello-world
docker ps
docker images
docker build -t my-app .
docker stop container_name
docker rm container_name

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

запуску контейнерів;
збірки образів;
перегляду логів;
керування volumes;
керування networks;
роботи з registry;
debugging;
автоматизації;
CI/CD.

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

Контейнер

Контейнер — це ізольований процес або група процесів, які запускаються з Docker image. Контейнер має власну файлову систему, network namespace, process namespace і набір налаштувань, але використовує ядро host-системи.

Контейнер зазвичай містить:

застосунок;
runtime;
бібліотеки;
конфігурацію;
environment variables;
entrypoint;
filesystem layer;
exposed ports.

Контейнер не є повною віртуальною машиною. Він легший, швидше стартує й використовує менше ресурсів, але має іншу модель ізоляції.

Проста аналогія: контейнер — це не цілий будинок, а окрема кімната з потрібними інструментами, яка ділить фундамент із будівлею.

Docker Image

Docker Image — це шаблон, з якого запускаються контейнери. Image складається з шарів і зазвичай створюється з Dockerfile.

Image містить:

base image;
installed packages;
application files;
dependencies;
environment variables;
metadata;
default command;
exposed ports;
filesystem layers.

Приклад:

docker pull nginx:latest
docker run -p 8080:80 nginx:latest

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

Dockerfile

Dockerfile — це файл інструкцій для збірки Docker image. Офіційна довідка Docker описує Dockerfile як файл, що визначає вміст і startup behavior одного контейнера. :contentReference[oaicite:4]{index=4}

Приклад:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Dockerfile може містити:

`FROM`;
`WORKDIR`;
`COPY`;
`RUN`;
`ENV`;
`ARG`;
`EXPOSE`;
`CMD`;
`ENTRYPOINT`;
`USER`;
`HEALTHCHECK`.

Важливо: Dockerfile має бути відтворюваним. Якщо він залежить від випадкових ручних кроків, Docker втрачає одну зі своїх головних переваг.

Docker Compose

Docker Compose — інструмент для опису й запуску multi-container applications. Офіційна довідка Docker описує Compose file як файл, що визначає multi-container application. :contentReference[oaicite:5]{index=5}

Compose зручний для локальної розробки, де застосунку потрібні кілька сервісів.

Приклад:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/appdb
    depends_on:
      - db

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Docker Compose використовується для:

локальних dev environments;
multi-service apps;
test stacks;
databases;
queues;
cache;
reverse proxy;
small deployments у частині сценаріїв.

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

Docker Hub

Docker Hub — популярний registry для Docker images.

Docker Hub використовується для:

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

Приклад:

docker pull redis:latest
docker pull postgres:18
docker pull nginx:alpine

Важливо: не кожен image у registry є безпечним або офіційним. Потрібно перевіряти джерело, теги, оновлення й репутацію image.

Registry

Container registry — це сховище для container images.

Registry може бути:

Docker Hub;
GitHub Container Registry;
GitLab Container Registry;
Amazon ECR;
Google Artifact Registry;
Azure Container Registry;
self-hosted registry;
Harbor;
private enterprise registry.

Registry зберігає:

images;
tags;
digests;
layers;
metadata;
signatures у відповідних сценаріях;
vulnerability scan results у частині платформ.

Практична роль: registry — це як склад контейнерних образів, з якого production або CI/CD бере потрібні версії.

Tags і digests

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

nginx:1.27-alpine
postgres:18
my-app:2026-05-09

Digest — це content-addressed ідентифікатор image.

Приклад:

image@sha256:...

Важливо: tag може змінитися, а digest вказує на конкретний вміст. Для production часто краще pin version або digest, а не покладатися на `latest`.

Volumes

Docker volume — механізм для збереження даних поза життєвим циклом контейнера.

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

баз даних;
uploaded files;
кешів;
persistent data;
logs у частині сценаріїв;
shared data між контейнерами;
local development state.

Приклад:

docker volume create pgdata

docker run -d \
  --name db \
  -v pgdata:/var/lib/postgresql/data \
  postgres:18

Критично: якщо контейнер видалити, його writable layer може зникнути. Для важливих даних потрібні volumes, backups і перевірений restore.

Bind mounts

Bind mount підключає директорію host-системи в контейнер.

Приклад:

docker run --rm -v "$PWD":/app -w /app node:22-alpine npm test

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

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

Важливо: bind mount дає контейнеру доступ до host-файлів. Не монтуйте чутливі директорії без потреби.

Docker Network

Docker має власну network model.

Типові network modes:

bridge;
host;
none;
overlay;
macvlan;
custom bridge networks.

Для Compose сервіси в одній мережі можуть звертатися один до одного за service name.

Приклад:

services:
  app:
    build: .
    depends_on:
      - redis

  redis:
    image: redis:latest

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

Практична роль: Docker network дозволяє контейнерам спілкуватися між собою без ручного прописування IP-адрес.

Ports

Порти дозволяють відкрити сервіс контейнера назовні.

Приклад:

docker run -p 8080:80 nginx:alpine

Це означає:

порт 8080 на host;
перенаправляється в порт 80 контейнера.

Важливо: `EXPOSE` у Dockerfile документує порт, але не завжди відкриває його назовні. Для публікації потрібен `-p` або відповідна Compose-конфігурація.

Environment variables

Environment variables часто використовують для конфігурації контейнерів.

Приклад:

docker run -e NODE_ENV=production -e PORT=3000 my-app:1.0

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

config;
connection strings;
feature flags;
environment-specific settings;
runtime behavior.

Критично: secrets не варто бездумно зберігати в environment variables, особливо в shared environments. Для секретів краще використовувати secret manager або спеціальні механізми платформи.

BuildKit

BuildKit — сучасний backend для збірки Docker images.

BuildKit дає:

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

Приклад:

docker buildx build --platform linux/amd64,linux/arm64 -t my-app:1.0 .

Практична роль: BuildKit робить Docker builds швидшими, безпечнішими й краще придатними для CI/CD.

Multi-stage builds

Multi-stage build дозволяє мати кілька етапів у Dockerfile й переносити в фінальний image тільки потрібні файли.

Приклад:

FROM golang:1.24-alpine AS build
WORKDIR /src
COPY . .
RUN go build -o app ./cmd/app

FROM alpine:3.22
WORKDIR /app
COPY --from=build /src/app /app/app
CMD ["./app"]

Переваги:

менший final image;
менше build tools у production image;
менша attack surface;
чистіша структура;
швидші deployments.

Проста аналогія: multi-stage build — це як приготувати їжу на кухні, але в коробку покласти тільки готову страву, а не всю кухню.

.dockerignore

`.dockerignore` виключає файли з build context.

Приклад:

node_modules
.git
.env
dist
coverage
*.log

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

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

Критично: якщо `.env`, private keys або tokens потрапили в image layer, їх може бути складно повністю прибрати з історії image. `.dockerignore` дуже важливий.

Docker logs

Docker дозволяє переглядати logs контейнера.

Приклад:

docker logs app
docker logs -f app

Для production важливо:

писати logs у stdout/stderr;
збирати logs централізовано;
не зберігати важливі logs лише в контейнері;
контролювати log rotation;
не писати secrets у logs.

Практична роль: у контейнерному світі лог краще сприймати як потік подій, який забирає зовнішня система логування.

Healthcheck

HEALTHCHECK дозволяє Docker або orchestrator зрозуміти, чи контейнер здоровий.

Приклад:

HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost:3000/health || exit 1

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

monitoring;
restart policies;
orchestration;
load balancers;
production diagnostics;
zero-downtime deployment;
readiness/liveness logic у ширших платформах.

Важливо: healthcheck має перевіряти реальну готовність сервісу, а не просто факт, що процес ще не завершився.

Docker і віртуальні машини

Docker-контейнери й virtual machines вирішують схожі, але різні задачі.

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

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

Docker і Kubernetes

Docker часто використовується для створення container images, які потім запускаються в Kubernetes.

Kubernetes додає:

orchestration;
scheduling;
services;
deployments;
scaling;
rolling updates;
config maps;
secrets;
persistent volumes;
cluster management;
self-healing.

Docker краще для:

локальної розробки;
збірки images;
простих контейнерів;
Compose-сценаріїв;
навчання container basics.

Kubernetes краще для:

production orchestration;
multi-node clusters;
service discovery;
autoscaling;
complex deployments;
cloud-native platforms.

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

Docker Swarm

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

Swarm може використовуватися для:

services;
replicated containers;
overlay networks;
rolling updates;
secrets;
configs;
простіших cluster deployments.

Сьогодні Kubernetes значно популярніший для великих production-сценаріїв, але Swarm може бути простішим для невеликих Docker-native кластерів.

Важливо: Docker Swarm простіший за Kubernetes, але має меншу ecosystem і менше поширення в сучасному cloud-native production.

Docker і Podman

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

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

Висновок: Docker має найширше developer adoption, а Podman часто цікавий там, де важливий daemonless і rootless Linux-підхід.

Docker і LXC

LXC — Linux containers на нижчому рівні, які часто більше схожі на lightweight system containers.

Docker зазвичай фокусується на application containers.

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

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

Безпека Docker

Docker дає ізоляцію, але контейнер не є абсолютним security boundary.

Потрібно контролювати:

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.

Критично: не монтуйте Docker socket у контейнер без дуже вагомої причини. Контейнер із доступом до Docker socket часто фактично отримує контроль над host.

Root user у контейнері

Багато container images за замовчуванням запускають процес від root. Це зручно, але ризиково.

Краще:

створити non-root user;
використовувати `USER`;
мінімізувати capabilities;
не запускати privileged container;
не монтувати host filesystem без потреби;
використовувати read-only root filesystem у частині сценаріїв.

Приклад:

RUN addgroup -S app && adduser -S app -G app
USER app

Практична порада: якщо застосунку не потрібен root, не запускайте його від root.

Privileged containers

`--privileged` дає контейнеру дуже широкі права.

Приклад небезпечного запуску:

docker run --privileged some-image

Це може бути потрібно для деяких low-level або lab-сценаріїв, але в production зазвичай небажано.

Критично: privileged container сильно зменшує ізоляцію. У production його потрібно уникати, якщо немає чіткої й перевіреної причини.

Secrets

Docker-проєкти часто працюють із секретами:

database passwords;
API keys;
tokens;
private keys;
certificates;
cloud credentials.

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

класти secrets у Dockerfile;
комітити `.env`;
передавати secrets через build args без захисту;
друкувати secrets у logs;
зберігати secrets у image layers;
використовувати один secret для всіх середовищ.

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

secret manager;
Docker secrets у Swarm-сценаріях;
Kubernetes Secrets із додатковим захистом;
cloud secret managers;
BuildKit secrets для build-time secrets;
least privilege credentials.

Критично: якщо secret потрапив у image layer, просте видалення файлу в наступному Dockerfile-кроці може не прибрати його з історії.

Image scanning

Container image scanning шукає відомі вразливості в base image і packages.

Scanning допомагає перевіряти:

OS packages;
language dependencies;
CVE;
outdated libraries;
risky images;
supply chain;
policy compliance;
SBOM.

Важливо: image scanning не гарантує безпеку. Він знаходить відомі проблеми, але не замінює code review, тестування й threat modeling.

SBOM

SBOM або Software Bill of Materials — список компонентів у software artifact, зокрема container image.

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

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

Практична роль: якщо завтра знайдуть уразливість у бібліотеці, SBOM допоможе швидко зрозуміти, чи є вона у вашому image.

CI/CD

Docker дуже часто використовується в CI/CD.

Сценарії:

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.

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

Code push
Run tests
Build Docker image
Scan image
Push to registry
Deploy to staging
Run checks
Deploy to production

Практична роль: Docker робить CI/CD чистішим, бо pipeline працює з конкретним artifact — container image.

Dev containers

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

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

однакових toolchains;
швидкого onboarding;
VS Code Dev Containers;
ізоляції dependencies;
різних версій мов;
навчальних середовищ;
reproducible development;
командної роботи.

Практична роль: dev container допомагає новому розробнику стартувати не за день налаштувань, а за кілька команд.

Docker у production

Docker у production потребує дисципліни.

Потрібно продумати:

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

Важливо: контейнеризація не замінює production-архітектуру. Вона лише пакує й запускає застосунок зручніше.

Resource limits

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

Приклад:

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

Resource limits корисні для:

захисту host;
стабільності;
multi-service environments;
production isolation;
тестування поведінки при нестачі ресурсів;
cost control.

Практична порада: без resource limits один контейнер може з’їсти більше пам’яті або CPU, ніж ви очікували.

Docker і бази даних

Бази даних можна запускати в Docker, особливо для локальної розробки й тестів.

Добрі сценарії:

local PostgreSQL;
test MySQL;
Redis для dev;
integration tests;
temporary databases;
demo environments.

Для production потрібно уважно продумати:

volumes;
backups;
restore;
disk performance;
upgrades;
monitoring;
replication;
graceful shutdown;
data corruption risks;
orchestration.

Критично: база даних у контейнері — це нормально, але дані мають жити не “в контейнері”, а в правильно керованому storage з backup.

Docker і мікросервіси

Docker часто використовують у microservices architecture.

Переваги:

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

Але мікросервіси додають:

network complexity;
distributed tracing;
service discovery;
versioning;
observability;
latency;
data consistency;
operational complexity.

Важливо: Docker полегшує мікросервіси, але не робить distributed systems простими.

Docker і моноліт

Docker корисний не лише для мікросервісів. Монолітний застосунок також можна контейнеризувати.

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

однакове середовище;
простіший deploy;
isolation dependencies;
rollback через image tag;
CI/CD;
локальна розробка;
staging parity;
менше “works on my machine”.

Цікавий факт: Docker не змушує переходити на мікросервіси. Іноді найкращий перший крок — просто добре контейнеризований моноліт.

Docker і ліцензії

Docker Engine є open source containerization technology. У документації встановлення Docker Engine згадується Apache License, Version 2.0. :contentReference[oaicite:6]{index=6}

Але Docker ecosystem ширший за Docker Engine:

Docker Engine;
Docker CLI;
Docker Desktop;
Docker Compose;
Docker Hub;
Docker Scout;
Docker Hardened Images;
commercial services.

Для реального використання потрібно розрізняти open source компоненти, desktop-продукти, hosted services і commercial features.

Важливо: ліцензування Docker Engine і умови Docker Desktop або Docker Hub можуть відрізнятися. Для компанії це потрібно перевіряти окремо.

Переваги Docker

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

reproducible environments;
швидкий запуск контейнерів;
ізоляція залежностей;
Dockerfile як infrastructure-as-code;
Docker Compose для локальних stacks;
велика ecosystem;
Docker Hub і registries;
CI/CD-friendly workflow;
multi-stage builds;
BuildKit;
простіший onboarding;
зручність для microservices;
переносимість між середовищами;
менше ручної інсталяції на сервері;
зручність для тестування.

Головна перевага: Docker робить середовище застосунку частиною самого проєкту, а не усною інструкцією для адміністратора.

Обмеження Docker

Docker має обмеження.

Можливі проблеми:

контейнер не є повною 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.

Помилка: думати, що Docker автоматично робить застосунок безпечним, масштабованим і production-ready.

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

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

однакове dev/test/prod середовище;
швидко піднімати залежності;
пакувати застосунок із dependencies;
запускати integration tests;
використовувати CI/CD;
створювати microservices;
запускати локальний PostgreSQL або Redis;
робити reproducible builds;
деплоїти container images;
працювати з Kubernetes;
спростити onboarding;
ізолювати toolchains.

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

Коли Docker може бути невдалим вибором

Docker може бути не найкращим вибором, якщо:

застосунок дуже простий і не має складних dependencies;
потрібна повна VM-ізоляція;
потрібна GUI-heavy desktop application без спеціальної підготовки;
команда не готова вчити container basics;
production storage не продуманий;
потрібно запускати системні сервіси як у повній ОС;
security policy забороняє Docker daemon;
потрібна дуже проста static deployment без runtime;
проблему можна вирішити пакетним менеджером або single binary.

Важливо: Docker — сильний інструмент, але не кожен проєкт потребує контейнеризації.

Хороші практики Docker

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

використовувати `.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 обережно.

Головне правило: хороший Docker-проєкт має маленький image, зрозумілий Dockerfile, безпечні secrets, reproducible build і чіткий шлях до deployment.

Типові помилки початківців

Поширені помилки:

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

Небезпека: найболючіша помилка Docker-початківця — видалити контейнер із важливими даними й тільки потім дізнатися, що volume не був налаштований.

Цікаві факти про Docker

Docker зробив контейнери масовим developer tool, хоча Linux-контейнери існували й до нього.
Dockerfile описує не тільки файли image, а й startup behavior контейнера. :contentReference[oaicite:7]{index=7}
Docker Compose починався як зручний інструмент для локальних multi-container stacks, але став стандартною частиною багатьох dev workflows.
Docker image складається з шарів, тому порядок інструкцій у Dockerfile впливає на cache і швидкість build.
Контейнер може стартувати за секунди, бо не завантажує повну guest OS як VM.
`latest` — це просто tag, а не гарантія найкращої або стабільної версії.
Docker добре підходить і для монолітів, і для мікросервісів.
Найбільша сила Docker — не “магічна ізоляція”, а повторюваність середовища.

Найлюдяніший факт: Docker — це спосіб перестати сперечатися, у кого яка версія Node, Python або PostgreSQL стоїть локально, і просто запустити однакове середовище.

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

Локальна розробка web app

Розробник запускає застосунок, PostgreSQL і Redis через Docker Compose, не встановлюючи всі залежності напряму в систему.

CI pipeline

CI збирає Docker image, запускає тести, сканує image і пушить його в registry.

Production deployment

Застосунок деплоїться як image з конкретним tag або digest, а rollback означає повернення до попереднього image.

Integration tests

Тести піднімають тимчасову базу даних у контейнері, проганяють сценарії й видаляють середовище після завершення.

Dev container

Команда описує середовище розробки в контейнері, щоб усі мали однакові версії інструментів.

Підказка: найкращий перший Docker-сценарій — підняти локальні залежності проєкту через Compose: базу, кеш і застосунок.

Приклад простого Dockerfile для Python

FROM python:3.13-slim

WORKDIR /app

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

COPY . .

EXPOSE 8000

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

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

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

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/appdb
    depends_on:
      - db

  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Практична роль: цей Compose-файл піднімає застосунок і базу як один локальний stack.

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

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

RUN addgroup -S app && adduser -S app -G app
USER app

EXPOSE 3000

CMD ["node", "server.js"]

Практична роль: запуск від non-root user зменшує ризики, якщо застосунок або dependency має вразливість.

Джерела

Docker Documentation.
Docker overview.
Docker Engine documentation.
Docker Engine release notes.
Docker reference documentation.
Dockerfile reference.
Docker Compose file reference.
Docker Build documentation.
Docker security documentation.
Docker Hub documentation.
Документація щодо containers, images, registries, volumes, networks, BuildKit, multi-stage builds, CI/CD, Kubernetes, Docker Swarm, SBOM і container security.

Висновок

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

Docker не є магічною заміною архітектури, безпеки, backup або моніторингу. Він дуже сильний у відтворюваності, пакуванні, ізоляції залежностей і developer experience, але потребує правильних практик: `.dockerignore`, non-root users, volumes для даних, image scanning, secrets management, healthchecks, resource limits і продуманий deployment.

Головна думка: Docker — це не просто спосіб “запустити щось у контейнері”. Це спосіб зробити середовище застосунку відтворюваним, переносимим і керованим.

Цікавий факт

Загальний опис

Docker Engine

Docker Desktop

Docker CLI

Контейнер

Docker Image

Dockerfile

Docker Compose

Docker Hub

Registry

Tags і digests

Volumes

Bind mounts

Docker Network

Ports

Environment variables

BuildKit

Multi-stage builds

.dockerignore

Docker logs

Healthcheck

Docker і віртуальні машини

Docker і Kubernetes

Docker Swarm

Docker і Podman

Docker і LXC

Безпека Docker

Root user у контейнері

Privileged containers

Secrets

Image scanning

SBOM

CI/CD

Dev containers

Docker у production

Resource limits

Docker і бази даних

Docker і мікросервіси

Docker і моноліт

Docker і ліцензії

Переваги Docker

Обмеження Docker

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

Коли Docker може бути невдалим вибором

Хороші практики Docker

Типові помилки початківців

Цікаві факти про Docker

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

Локальна розробка web app

CI pipeline

Production deployment

Integration tests

Dev container

Приклад простого Dockerfile для Python

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

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

Джерела

Висновок

Див. також

Тематичні мітки