Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
healthy-check-timed-out Linux / DevOps

Docker Compose: container healthy check timed out — Исправление

Обновлено: 19.08.2026  ·  Официальная база знаний

Механизм оркестрации depends_on и подсистема Healthcheck

Ошибка ERROR: dependency failed to start: container is unhealthy или container healthy check timed out возникает при использовании механизма управления зависимостями depends_on с условием condition: service_healthy. Docker Compose запускает зависимый сервис только после того, как целевой контейнер перейдет из статуса starting в статус healthy. Если команда проверки здоровья (healthcheck probe) возвращает ненулевой код выхода (exit code > 0) или не успевает завершиться за время timeout на протяжении всех попыток retries, запуск всего стека аварийно прерывается.

Бизнес-риски:

Полный сбой автоматического развертывания приложений, каскадный отказ связанных сервисов (микросервисы не могут подключиться к нестартовавшей БД), задержки релизов.

Таблица параметров директивы Healthcheck

ПараметрРекомендуемое значениеНазначение
test['CMD', 'curl', '-f', 'http://localhost:8080/health']Команда проверки жизнеспособности внутри контейнера.
interval10s - 30sИнтервал времени между последовательными проверками.
timeout5s - 10sМаксимальное время ожидания ответа на одну проверку.
retries3 - 5Количество последовательных неудач до статуса unhealthy.
start_period30s - 60sВремя на холодный старт (проверки в этот период не штрафуют статус).

Пошаговая оптимизация и отладка проверок Healthcheck

Сценарий 1: Увеличение start_period для тяжелых сервисов (БД, Java/Spring)

Тяжелые базы данных или Java-приложения долго инициализируют структуры при первом старте:

services:
  database:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U postgres']
      interval: 10s
      timeout: 5s
      retries: 5
      # Параметр для предотвращения таймаута при инициализации:
      start_period: 45s

  api:
    image: myapi:latest
    depends_on:
      database:
        condition: service_healthy

Сценарий 2: Тестирование команды Healthcheck вручную внутри контейнера

Проверьте, установлена ли утилита проверки (curl/wget/pg_isready) в базовом образе:

# Вход в работающий контейнер зависимости
docker exec -it <container_name> sh

# Ручной запуск команды проверки и просмотр кода выхода:
pg_isready -U postgres
echo $?

Сценарий 3: Просмотр логов неудавшихся проверок Healthcheck

Узнайте точную причину падения проверок через детальную инспекцию Docker:

# Получение последних результатов проверок healthcheck и их вывода
docker inspect <container_name> --format='{{json .State.Health}}' | jq .

Типовые ошибки администраторов

  • Использование curl в легковесных alpine-образах: В базовых образах Alpine утилита curl отсутствует. Используйте wget -q --spider http://127.0.0.1:80/ || exit 1.
  • Отсутствие start_period при миграциях БД: Если сервис выполняет долгие миграции базы данных при первом старте, он гарантированно получит статус unhealthy без start_period.
Сложные микросервисные стеки падают из-за некорректного порядка запуска?
ITSTM настроит надежные readiness/liveness пробы, оптимизирует запуск баз данных и обеспечит 100% стабильность ваших стеков.
Практический опыт инженера: Никогда не проверяйте внешние сетевые зависимости в healthcheck контейнера. Проверка должна тестировать ТОЛЬКО локальный процесс (127.0.0.1), иначе при сетевых сбоях упадет весь локальный стек.

Частые вопросы (FAQ)

Чем отличается CMD от CMD-SHELL в директиве test?

CMD вызывает бинарник напрямую без шелла: ['CMD', 'curl', 'localhost']. CMD-SHELL оборачивает команду в shell: ['CMD-SHELL', 'curl localhost || exit 1'].

Можно ли использовать depends_on без healthcheck?

Да, но без condition: service_healthy Docker Compose просто запустит контейнеры одновременно, не дожидаясь реальной готовности приложения внутри.

Как временно отключить healthcheck у наследуемого образа?

В блоке сервиса укажите: healthcheck: disable: true.

Какой код выхода считается успешным для Healthcheck?

Строго код 0. Код 1 означает unhealthy. Любые другие коды выхода зарезервированы и также переводят контейнер в unhealthy.