depends_on в Docker Compose гарантирует только порядок старта контейнеров, но не то, что зависящий сервис уже реально готов принимать соединения. Поэтому одного depends_on недостаточно: нужны healthcheck, скрипты ожидания или логика повторных попыток в самом приложении.
depends_on решает очень узкую задачу: он говорит Docker Compose запустить контейнер A после контейнера B. Но в реальных системах важна не просто последовательность запуска, а именно готовность зависимого сервиса: чтобы база данных уже слушала порт, завершила инициализацию и миграции, кеш прогрелся и т.п. Если полагаться только на depends_on, приложение может стартовать тогда, когда, например, база всё ещё поднимается, и начать падать с ошибками подключения.
Основные ограничения depends_on:
depends_on это никак не отработает.healthcheck.Поэтому depends_on обычно дополняют более надёжными механизмами. Первый распространённый подход — использовать healthcheck, чтобы считать контейнер «готовым» только после успешной проверки (например, успешного подключения к БД или 200 OK по HTTP), а затем ждать именно состояния service_healthy, а не просто «запущен».
Второй важный приём — заложить устойчивость прямо в приложение или в стартовый скрипт: при старте не падать сразу при первой ошибке подключения, а делать несколько попыток с паузами. Это работает и в Docker Compose, и в любых других средах, и помогает переживать не только медленный старт, но и кратковременные отказы зависимостей.
Итого, depends_on годится только для грубого управления порядком запуска контейнеров и не гарантирует готовность сервисов. Для предсказуемого и устойчивого старта системы его нужно обязательно комбинировать с healthcheck, скриптами ожидания и логикой повторных попыток в коде приложения или в оркестраторе.
Отметьте свой прогресс