Як працює Docker: контейнери, образи, шари і реєстри

Навіщо Docker

Класична проблема: «у мене працює, а на сервері — ні». Інша версія Python, бракує системної бібліотеки, конфлікт залежностей двох застосунків на одному сервері. Docker вирішує це так: застосунок пакується разом з усім оточенням (рантайм, бібліотеки, налаштування) в образ, і цей образ однаково запускається на ноутбуці, у CI і на проді.

Що це дає на практиці:

• Відтворюваність — той самий образ, що пройшов тести, їде в прод.
• Ізоляція — десять застосунків на одному сервері не заважають один одному.
• Швидкість — контейнер стартує за секунди, а не за хвилини.
• Стандарт — один формат для будь-якої мови: Kubernetes, CI, хмари й PaaS (Dokploy, Coolify, Render) приймають образ.

Актуальність

Розділ написано для Docker Engine 29.x і Docker Desktop 4.x (жовтень 2026). Команди docker compose (з пробілом) і BuildKit — стандарт з 2023 року; старий docker-compose (з дефісом) більше не підтримується.

Контейнер — це не віртуальна машина

Віртуальна машина емулює цілий комп'ютер: свої віртуальні диски, своє ядро ОС, свій завантажувач. Важить гігабайти, стартує хвилини.

Контейнер — це звичайний процес Linux, якого ядро ізолювало від решти системи. Ядро спільне з хостом, тож контейнер важить мегабайти й стартує за частки секунди. Переконайтеся самі:

docker run -d --name web nginx:stable-alpine
ps aux | grep "nginx: master"      # на хості видно процес nginx!

root  48213  0.0  0.0  9220  6144 ?  Ss  14:02  0:00 nginx: master process nginx -g daemon off;

Ізоляцію забезпечують два механізми ядра Linux:

Наслідок спільного ядра

Контейнер ізольований слабше за ВМ: вразливість ядра зачіпає всіх. І ще: Linux-контейнери потребують ядра Linux. Тому Docker Desktop на Windows і macOS запускає маленьку Linux-віртуалку (див. «Встановлення і налаштування»).

Образ і контейнер

Найважливіша пара понять:

docker pull redis:7-alpine                 # завантажили образ
docker run -d --name cache1 redis:7-alpine # контейнер №1
docker run -d --name cache2 redis:7-alpine # контейнер №2 з того самого образу
docker ps

CONTAINER ID   IMAGE            COMMAND                  STATUS         NAMES
3f1a2b4c5d6e   redis:7-alpine   "docker-entrypoint.s…"   Up 3 seconds   cache2
9e8d7c6b5a4f   redis:7-alpine   "docker-entrypoint.s…"   Up 5 seconds   cache1

Шари: з чого складається образ

Образ — не один великий архів, а стос шарів. Кожна інструкція RUN, COPY, ADD у Dockerfile додає шар зі змінами файлової системи. Контейнер отримує поверх них свій тонкий шар для запису.

Чому це важливо:

• Економія місця і трафіку. Десять образів на базі python:3.13-slim зберігають базовий шар один раз. docker pull завантажує лише шари, яких у вас ще немає.
• Швидка збірка. Незмінені шари беруться з кешу — про це в нотатці «Dockerfile».
• Дані в контейнері тимчасові. Шар контейнера видаляється разом із контейнером. Базу даних без тому втратите з першим docker rm.

docker history nginx:stable-alpine   # шари образу і їхні розміри

Ім'я образу: реєстр, репозиторій, тег, digest

Повне ім'я образу складається з частин:

ghcr.io/olena/notes-app:1.4.0@sha256:9f86d081884c7d65...
└──┬──┘ └───────┬─────┘ └─┬─┘ └──────────┬──────────┘
 реєстр     репозиторій    тег          digest

Тобто nginx — це насправді docker.io/library/nginx:latest.

Тег можна перезаписати, digest — ні

Тег — лише ярлик, автор може в будь-який момент перевісити nginx:stable на новий образ. latest не означає «найновіший» — це просто тег за замовчуванням. Для відтворюваних збірок і продакшену вказуйте конкретну версію (postgres:17.6-alpine), а для максимальної гарантії — digest: postgres@sha256:….

Реєстри

Реєстр (registry) — сховище образів, як GitHub для коду.

docker login ghcr.io                     # увійти (токен замість пароля)
docker tag notes-app:1.4.0 ghcr.io/olena/notes-app:1.4.0
docker push ghcr.io/olena/notes-app:1.4.0
docker pull ghcr.io/olena/notes-app:1.4.0

Як влаштований Docker усередині

Усе це відповідає відкритим стандартам OCI (Open Container Initiative). Тому образ, зібраний Docker, запуститься в Podman, containerd чи Kubernetes, і навпаки.

docker.sock = root

Хто може писати в /var/run/docker.sock, той фактично root на хості: можна запустити контейнер із примонтованим / і зробити з системою що завгодно. Тому членство в групі docker і монтування сокета в контейнери (-v /var/run/docker.sock:...) — питання безпеки, а не зручності.

Альтернативи

• Podman — сумісний CLI (alias docker=podman), без демона, rootless за замовчуванням. Популярний на RHEL/Fedora.
• containerd + nerdctl — легший стек без Docker Engine.
• Kubernetes — не замінює Docker, а оркеструє контейнери на багатьох серверах; образи для нього збирають тим самим Docker.

Коротко

• Контейнер — ізольований процес на спільному ядрі, а не ВМ.
• Образ — незмінний шаблон зі стосу шарів; контейнер — його запущений екземпляр зі своїм шаром для запису.
• Дані в шарі контейнера зникають разом із контейнером — для даних є томи.
• Повне ім'я образу: реєстр/репозиторій:тег@digest; latest — пастка.
• Доступ до docker.sock дорівнює правам root.