Docker compose не запускает сервисы по порядку зависимостей как решить

[sainty]

Замучился с банальной проблемой: есть docker-compose с тремя сервисами — postgres, redis и app. В depends_on указал зависимости, но app стартует раньше чем postgres успевает принять соединения, и падает с ошибкой connection refused. Перезапускаю вручную — работает. Как сделать нормальное ожидание готовности?

[radiomaker]

depends_on по умолчанию ждёт только запуска контейнера, не готовности сервиса внутри. Тебе нужен healthcheck. В секции postgres добавь healthcheck с командой pg_isready, а в depends_on для app укажи condition: service_healthy. Тогда app не стартует пока postgres не пройдёт healthcheck.

[burg0809]

Вот рабочий пример конфига который я использую в продакшене уже год без проблем. Для postgres в healthcheck пишешь: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"], interval: 5s, timeout: 5s, retries: 5. В depends_on для app: postgres: condition: service_healthy. Для redis аналогично, только test: ["CMD", "redis-cli", "ping"]. Это решает 95% случаев с очерёдностью старта.

[togashi]

Помимо healthcheck советую добавить в само приложение логику retry при подключении к БД. Даже если postgres ответил на pg_isready, инициализация схемы и первые запросы могут занять время. В Python это asyncpg с retry через tenacity, в Go — стандартный backoff. Инфраструктурное решение + application-level retry = надёжность.

[sleepyraccoon]

А ещё есть утилита wait-for-it.sh — добавляешь её в образ и в command пишешь wait-for-it postgres:5432 -- python app.py. Старый способ, но до сих пор работает если по каким-то причинам не хочешь трогать compose-файл.

[ollies]

Классическая ловушка для новичков. Я когда-то потратил на это полдня. Сейчас всегда добавляю healthcheck в базовые compose-шаблоны сразу, ещё на этапе создания проекта.

[matguyvr]

Один нюанс к healthcheck с pg_isready: на старте postgres сначала поднимает временный локальный сервер для прогона init-скриптов, и pg_isready может ответить «accepting connections» ещё до того, как основной инстанс открыл TCP-порт. Если у тебя есть init.sql или заливка дампа — вешай healthcheck на реальный запрос вроде psql -c 'select 1', а не на голый pg_isready, иначе app проскочит на этом ложном «готово» и снова поймает connection refused.

[torchchan]

@togashi, вот это и есть главное, что все пропускают. condition: service_healthy спасает ровно один раз — на старте. А postgres может уйти в рестарт посреди работы: OOM, failover, ребут ноды — и healthcheck тебе тут уже ничем не поможет, app просто получит connection refused на живом проде. Без retry с backoff в самом приложении ты падения не убираешь, а только делаешь реже.

[much]

@burg0809, к твоему конфигу я бы обязательно добавил start_period. Без него первые медленные healthcheck'и на холодном старте съедают retries, и контейнер помечается unhealthy ещё до того, как база реально поднялась — особенно на большом образе или с первичной инициализацией. Что-то вроде start_period: 30s, и тогда interval 5s/retries 5 уже работают как задумано, а не отсчитывают провалы на пустом месте.