Dockerfile HEALTHCHECK: без ложных unhealthy

Что важно понять до начала

Dockerfile поддерживает `HEALTHCHECK` с командой и временными параметрами. Код выхода команды определяет успешность проверки. Start period позволяет сервису прогреться до применения обычной логики failures. Проверка должна зависеть от реально необходимого компонента, но не превращаться в полноценный end-to-end тест всей инфраструктуры.

Совет: Практический ориентир: HEALTHCHECK только сообщает состояние. Политика перезапуска реагирует прежде всего на завершение процесса; конкретная оркестрация может отдельно использовать health status.

Пошаговый порядок действий

1. 1. Выберите один дешёвый сигнал здоровья: локальный HTTP endpoint, socket или короткую команду приложения.
2. 2. Сделайте команду явно возвращающей ненулевой код при проблеме.
3. 3. Задайте timeout короче interval, а retries — так, чтобы краткий всплеск не вызывал ложную тревогу.
4. 4. Добавьте start-period для миграций, прогрева cache или долгого старта JVM.
5. 5. Сломайте зависимость намеренно и проверьте переход healthy → unhealthy, затем восстановление.

Важно: Критично для этой задачи: Не используйте healthcheck, который всегда возвращает 0 после проверки «процесс существует».

Ошибки и пограничные случаи

Не используйте healthcheck, который всегда возвращает 0 после проверки «процесс существует». Это создаёт ложное чувство надёжности и не выявляет зависший сервис. Если endpoint здоровья обращается к внешним API, сбой чужого сервиса может пометить все ваши контейнеры unhealthy. Включайте во healthcheck только зависимости, без которых инстанс действительно не способен обслуживать запрос.

Предупреждение: Пограничный случай: Он даёт приложению время на штатный запуск до того, как ранние неуспешные проверки начнут считаться обычными failures.

Проверка перед завершением

• Выберите один дешёвый сигнал здоровья: локальный HTTP endpoint, socket или короткую команду приложения.
• Задайте timeout короче interval, а retries — так, чтобы краткий всплеск не вызывал ложную тревогу.
• Сломайте зависимость намеренно и проверьте переход healthy → unhealthy, затем восстановление.
• Проверено отдельно: HEALTHCHECK только сообщает состояние. Политика перезапуска реагирует прежде всего на завершение процесса; конкретная оркестрация может отдельно использовать health status.

Практический сценарий и контроль результата

Хороший healthcheck отвечает на один вопрос: способен ли этот экземпляр обслуживать свою основную функцию. Команда должна быть дешёвой и иметь понятный exit code; проверка внешней цепочки из нескольких сервисов создаёт ложные unhealthy при чужом сбое. Отдельно протестируйте негативный сценарий: временно сломайте локальный endpoint и убедитесь, что статус действительно меняется. Затем восстановите сервис и проверьте возврат в healthy. Тайминги start-period и retries должны отражать реальное время запуска, а не маскировать постоянную неисправность.

Дополнительные нюансы и проверка

Healthcheck должен завершаться быстрее, чем interval, иначе проверки могут наслаиваться и создавать лишнюю нагрузку. Команда также должна существовать в финальном образе: curl в build‑stage не поможет, если его нет в runtime. Если используете HTTP endpoint, проверяйте код ответа и таймаут, а не только факт открытия TCP‑порта. После изменения посмотрите health status через inspect и убедитесь, что history показывает ожидаемые успешные и неуспешные проверки, а не случайные timeouts.

Что учитывать

Dockerfile поддерживает `HEALTHCHECK` с командой и временными параметрами. Код выхода команды определяет успешность проверки. Start period позволяет сервису прогреться до применения обычной логики failures. Проверка должна зависеть от реально необходимого компонента, но не превращаться в полноценный end-to-end тест всей инфраструктуры.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Dockerfile HEALTHCHECK). Пример и формулировки — редакция N1RO на 2026-09-22.

• Dockerfile HEALTHCHECK