Docker Compose

Определение многоконтейнерных приложений требует аккуратной работы с зависимостями, сетью и томами. Ниже — практические правила и нюансы использования Docker Compose, которые помогают избежать типичных ошибок и сделать конфигурацию предсказуемой.

depends_on и реальная готовность сервиса

Директива depends_on сама по себе лишь ожидает запуск контейнера — но это не означает, что сервис внутри уже готов принимать подключения.

depends_on:
 db:
 condition: service_healthy

Чтобы гарантировать готовность, необходимо добавить healthcheck и использовать условие service_healthy. Без этого Compose может запустить зависимый сервис слишком рано.

Важно: если у целевого сервиса не определён healthcheck, условие не сработает.

Параметр start_period в healthcheck

healthcheck:
 test: ["CMD", "pg_isready"]
 start_period: 30s

start_period задаёт начальный период, в течение которого ошибки проверки игнорируются. Это критично для медленно стартующих сервисов (например, базы данных или Java-приложений).

Без этого параметра контейнер может быть помечен как «неработоспособный» ещё до завершения инициализации.

Удаление томов

Команда docker compose down по умолчанию сохраняет тома. Но:

• docker compose down -v удаляет ВСЕ тома
• это приводит к полной потере данных
• часто флаг -v добавляют по привычке из туториалов

Именованные тома сохраняются после down, а анонимные — удаляются.

Ограничение ресурсов на этапе разработки

deploy:
 resources:
 limits:
 memory: 512M

Устанавливайте лимиты ресурсов уже в разработке — это позволяет выявить проблемы с памятью заранее.

Контейнер без ограничений может занять всю память хоста и «убить» другие процессы. Те же ограничения следует переносить в production.

.dockerignore

Без файла .dockerignore в образ попадают лишние файлы:

• node_modules
• .git
• секреты и конфигурации

Синтаксис аналогичен .gitignore. Файл должен находиться рядом с Dockerfile.

Минимальный набор:

• .git
• node_modules
• .env
• *.log
• артефакты сборки

Большой build-контекст замедляет сборку и увеличивает размер образа, а также может привести к утечке данных.

Паттерн override-файлов

• docker-compose.yml — базовая конфигурация
• docker-compose.override.yml — автоматически подключается для разработки

Для production:

docker compose -f docker-compose.yml -f docker-compose.prod.yml up

Секреты и окружение лучше хранить в override-файлах, а не в базовом конфиге.

Profiles для опциональных сервисов

services:
 mailhog:
 profiles: [dev]

Сервисы с профилями не запускаются по умолчанию. Это делает docker compose up чище и предсказуемее.

Включение:

docker compose --profile dev up

Используйте для тестовых баз, инструментов отладки, mock-сервисов и админ-панелей.

Приоритет переменных окружения

1. Переменные оболочки
2. Файл .env
3. env_file
4. environment в compose

Файл должен называться строго .env — другие варианты автоматически не подхватываются.

Для отладки используйте:

docker compose config

Команда покажет итоговые значения переменных после разрешения всех источников.