Текст и данные · Инструкция
Docker HEALTHCHECK exit code 0, 1 и 2: как интерпретировать
Docker HEALTHCHECK exit code 0, 1 и 2 имеет фиксированную семантику. Код 0 означает успешную проверку и healthy, код 1 — unhealthy, а 2 зарезервирован Docker и не должен использоваться как третье пользовательское состояние. Stdout/stderr проверки сохраняется в health status и доступен через docker inspect.
Короткий ответ
В Docker HEALTHCHECK код 0 означает healthy, код 1 — unhealthy, а код 2 зарезервирован и не должен использоваться как собственное состояние. Диагностику смотрят в health status через docker inspect.
Docker healthcheck exit code: ключевой принцип
Docker определяет exit code 0 как успешную проверку здоровья контейнера. Exit code 1 означает, что проверка считает контейнер unhealthy после применения настроек retries и интервалов. Код 2 зарезервирован; документация не рекомендует использовать его как третье пользовательское состояние.
Совет: Docker определяет exit code 0 как успешную проверку здоровья контейнера.
Контроль перед завершением
- Probe возвращает 0 только при успехе.
- Для ошибки используется 1, а не зарезервированный 2.
- В State.Health виден полезный короткий Output.
Что делать на практике
- Запустите docker inspect <container> и найдите секцию State.Health.
- Проверьте Status, FailingStreak и последние записи Log.
- Скопируйте healthcheck-команду и выполните её вручную внутри контейнера для диагностики.
- Исправьте команду так, чтобы успех возвращал 0, а реальная неисправность — 1.
- Не используйте 2 как собственный «warning»; для дополнительных состояний применяйте метрики или логи приложения.
Совет: Запустите docker inspect <container> и найдите секцию State.Health.
Healthy unhealthy docker: ограничения и ошибки
Сам процесс контейнера может продолжать работать при unhealthy: health status и running status — разные сигналы. Docker сохраняет ограниченный фрагмент stdout/stderr healthcheck-команды в health status, что помогает увидеть причину сбоя. Сложный healthcheck должен проверять готовность сервиса, а не только существование процесса, иначе статус может быть ложноположительным. В связанных материалах и настройках встречаются также термины: docker inspect health, health status container.
Предупреждение: Сложный healthcheck должен проверять готовность сервиса, а не только существование процесса, иначе статус может быть ложноположительным.
Практический нюанс
Docker хранит только ограниченный объём текста probe-вывода, поэтому healthcheck должен печатать короткую диагностическую причину. Большие логи приложения оставляйте в основном logging-механизме контейнера.
Что проверить в реальном сценарии
Healthcheck должен проверять готовность сервиса, а не просто наличие процесса. Например, HTTP-probe должен вернуть `0` только при ожидаемом ответе приложения; короткий текст ошибки попадёт в `Health.Log` и поможет понять причину `unhealthy`.
Как убедиться, что задача решена
Диагностику начинайте с docker inspect: в State.Health видны текущий Status и история последних probe с ExitCode и Output. Используйте 0 только для успеха и 1 для любой проверяемой неисправности; код 2 оставьте Docker. Если healthcheck постоянно падает, запускайте ту же команду вручную внутри контейнера и проверяйте зависимости, таймаут и start period, а не маскируйте ошибку нестандартным exit code.
Важно: Retries не скрывают хроническую ошибку
Что учитывать
Сам процесс контейнера может продолжать работать при unhealthy: health status и running status — разные сигналы. Docker сохраняет ограниченный фрагмент stdout/stderr healthcheck-команды в health status, что помогает увидеть причину сбоя. Сложный healthcheck должен проверять готовность сервиса, а не только существование процесса, иначе статус может быть ложноположительным. В связанных материалах и настройках встречаются также термины: docker inspect health, health status container.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Dockerfile reference — HEALTHCHECK). Пример и формулировки — редакция N1RO на 2026-09-23.