Пошук уроків, статей та іншого контенту
Один декларативний файл замість довгих ручних команд docker run для кожного сервісу застосунку.
Типовий застосунок складається не з одного контейнера, а з кількох, що працюють разом: сам застосунок, база даних, можливо кеш чи черга повідомлень. Запускати кожен вручну окремими довгими командами docker run (зі своїми мережами, volumes, змінними середовища для кожного) незручно й важко відтворити точно однаково між запусками.
services:
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: fullstack_ua
POSTGRES_PASSWORD: fullstack_ua
POSTGRES_DB: fullstack_ua
ports:
- "5434:5432"
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:Цей приклад навмисно відповідає реальному docker-compose.yml цього проєкту — один сервіс бази даних, з проброшеним портом (урок про networks) і named volume (урок про volumes) для персистентності даних розробки.
docker compose up -d # запустити всі сервіси файлу у фоновому режимі
docker compose down # зупинити й видалити контейнери (volumes лишаються за замовчуванням)
docker compose ps # статус сервісів, описаних у цьому файлі
docker compose logs db # логи конкретного сервісуDocker Compose автоматично створює спільну мережу для всіх сервісів одного файлу — вони одразу можуть звертатись один до одного за іменем сервісу (тим самим ключем, що й у секції services), без ручного docker network create з попереднього модуля.
services:
api:
build: .
depends_on:
- db
db:
image: postgres:16-alpinedepends_on гарантує лише порядок запуску контейнера (спершу db, потім api), а не те, що PostgreSQL усередині db-контейнера вже готовий приймати підключення на момент старту api — контейнер бази даних може ще виконувати внутрішню ініціалізацію кілька секунд після старту процесу. Застосунки, чутливі до цього, зазвичай реалізують повторні спроби підключення (retry) при старті, а не покладаються лише на depends_on.
Вважати, що depends_on гарантує повну готовність залежного сервісу, а не лише порядок запуску контейнера, — призводить до нестабільних помилок підключення одразу після docker compose up.
docker compose down -v (з прапорцем -v) не усвідомлюючи, що це видаляє й volumes разом із контейнерами, — знищує накопичені дані розробки, а не лише зупиняє сервіси.
Ручні окремі docker run для кількох пов'язаних сервісів замість одного docker-compose.yml — втрачає відтворюваність і декларативність опису всього оточення одним файлом.
Docker Compose описує кілька пов'язаних сервісів одним декларативним YAML-файлом замість ручних окремих команд docker run для кожного — з автоматичною спільною мережею між сервісами файлу. depends_on визначає лише порядок запуску контейнерів, не готовність застосунку всередині них, тож чутливий до цього код повинен мати власну логіку повторних спроб підключення.