Перейти к содержанию

Проверяемый шаблон Docker Compose

Ненормативный пример для INF-CMP-002INF-CMP-004, INF-CMP-006, INF-CMP-008 и INF-CMP-009. Это шаблон интеграции, а не готовый production deployment.

Что можно взять из примера

compose.yaml показывает один проверяемый способ связать приложение и PostgreSQL без публикации database-порта:

  • оба image передаются извне и должны быть зафиксированы digest;
  • приложение начинает запуск после успешного healthcheck PostgreSQL;
  • credentials передаются файлами Compose secrets, а не значениями environment;
  • database data хранится в named volume;
  • внешний HTTP-порт привязан к loopback;
  • для долгоживущих services заданы healthcheck, restart policy, resource limits и ограниченная ротация логов;
  • backend network объявлена internal, поэтому database не имеет прямого исходящего маршрута через эту сеть.

Это не доказывает production-готовность приложения: шаблон не создаёт TLS reverse proxy, backup, alerting, delivery job и защищённый Docker host.

Ограничения применимости

Шаблон предназначен для local Compose-цели с одним экземпляром приложения и PostgreSQL. Он не моделирует high availability, миграцию production-данных, переключение primary или работу внешнего reverse proxy.

Контракт приложения

Чтобы применить шаблон, image приложения должен:

  1. запускать HTTP service на порту 8080;
  2. содержать исполняемый /app/healthcheck, возвращающий exit code 0 только при готовности обслуживать запросы;
  3. читать URL подключения из файла, указанного в DATABASE_URL_FILE;
  4. работать с read-only root filesystem и использовать /tmp для временных файлов;
  5. завершаться в пределах stop timeout Docker после SIGTERM.

Если приложение использует HTTP health endpoint вместо executable, замените healthcheck.test на команду, которая уже присутствует в runtime image. Не добавляйте shell или curl в image только ради healthcheck.

Подготовка

Docker Engine и Compose должны поддерживать docker compose up --wait. Скопируйте пример переменных и укажите реальные release digests:

cp .env.example .env

Создайте только синтетические local credentials:

install -d -m 0700 .secrets
printf '%s' 'local-only-password' >.secrets/database_password
printf '%s' \
  'postgresql://postgres:local-only-password@database:5432/postgres' \
  >.secrets/database_url
chmod 0600 .secrets/database_password .secrets/database_url

Файлы .env и .secrets/ не должны попадать в commit. Перед запуском убедитесь, что APPLICATION_IMAGE и POSTGRES_IMAGE содержат @sha256:<64 hex>, а не плавающий tag.

Проверка до запуска

docker compose config --quiet
docker compose config --images
docker compose config >rendered-compose.yaml

В списке image должны быть только ожидаемые registry/repository и digest. rendered-compose.yaml содержит разрешённые пути secret-файлов и значения несекретных переменных; его можно проверить в review, но не следует коммитить как отдельный источник конфигурации.

Запуск и проверка результата

docker compose pull
docker compose up --detach --wait
docker compose ps
docker compose exec application /app/healthcheck

Ожидаемый результат: application и database имеют состояние healthy, healthcheck приложения завершается с кодом 0, а database не публикует порт на host. Проверка фактических ограничений:

docker compose ps --quiet |
  xargs docker inspect \
    --format '{{.Name}} memory={{.HostConfig.Memory}} pids={{.HostConfig.PidsLimit}} readonly={{.HostConfig.ReadonlyRootfs}}'

Для диагностики неуспешного запуска:

docker compose ps
docker compose logs --since 10m application database
docker compose config

Не выводите содержимое .secrets/ в job log.

Остановка и сброс local state

Обычная остановка сохраняет database volume:

docker compose down

Полный сброс синтетических local-данных выполняется только явно:

docker compose down --volumes
rm -f rendered-compose.yaml

Для production нужны отдельные решения по INF-CMP-001, INF-CMP-005, INF-CMP-007, TLS по INF-CMP-003, backup по INF-BCK и наблюдаемости по INF-OBS.