
Долгие годы одной из самых больших болей в Docker Compose была инициализация окружения. Нам приходилось:
- Использовать
depends_onсcondition: service_started(что не гарантирует готовность). - Добавлять
healthcheckк БД и ждать его. - Писать монструозные entrypoint-скрипты на bash, которые пытались совмещать логику «подождать» и «запустить приложение».
С выходом Docker Compose 5.3 (и включенной поддержкой спецификации Compose 1.5.0) это осталось в прошлом.
Что такое init-контейнер в новом понимании?
Это временный контейнер, который:
- Запускается до основных сервисов.
- Выполняет строго определенную задачу (миграции, создание схемы, заполнение Redis-кеша, проверка доступности S3).
- Завершается с кодом
0(успех) или1(ошибка). - Блокирует запуск зависимых сервисов до своего успешного завершения.
Пример реального сценария:
yaml
services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: secret
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
redis:
image: redis:7
# Инициализация БД
db-migrate:
image: myapp:latest
init: true
command: ["npm", "run", "migrate"]
depends_on:
postgres:
condition: service_healthy
# Загрузка начальных данных в Redis
cache-warmup:
image: myapp:latest
init: true
command: ["npm", "run", "cache:seed"]
depends_on:
redis:
condition: service_started
# Основное приложение стартует ТОЛЬКО после всех инициализаций
app:
image: myapp:latest
ports:
- "3000:3000"
depends_on:
db-migrate:
condition: service_completed_successfully
cache-warmup:
condition: service_completed_successfully
Ключевые нововведения:
- Добавлено поле
init: true(не путать сinit: trueдля PID 1 — это другое). - Новое условие
service_completed_successfullyдляdepends_on. - Init-контейнеры не перезапускаются автоматически (restart: «no» по умолчанию).
Вывод:
Init-контейнеры в Compose 5.3 делают локальную разработку и CI/CD-пайплайны значительно проще и надежнее. Больше никаких хаков — только декларативная логика.
Обновляйтесь и пробуйте!
#Docker #DockerCompose #InitContainers #DevOpsBestPractices