Running ещё не значит готов

Представьте сервис, который принимает соединение, но на каждый запрос возвращает 500. Процесс существует, однако пользовательский сценарий сломан. Запишите отдельные утверждения: процесс запущен; HTTP-обработчик отвечает; ответ имеет нужную структуру; бизнес-операция выполняется. Один зелёный индикатор не доказывает сразу всё.

Для нашего приложения минимальная готовность — успешный GET-запрос к / на порту 8000. Функциональный тест дополнительно разбирает JSON и проверяет поле message. Разделение помогает понять сбой: сервер может быть доступен, но отдавать неверное сообщение.

HTTP 200
Content-Type: application/json

{"message": "Hello, Docker!"}

Перед следующей практикой придумайте контрпример: какая неисправность пройдёт проверку доступности, но не функциональный тест? Например, обработчик всегда возвращает пустой JSON. Такой пример показывает границу проверки лучше общего слова «работает».

HEALTHCHECK задаёт команду, результат которой Docker использует для дополнительного состояния здоровья: starting, healthy или unhealthy. В нашей команде успешный HTTP-запрос даёт код выхода 0, а ошибка Python — ненулевой код.

HEALTHCHECK --interval=5s --timeout=10s --start-period=10s --retries=2 CMD python -c "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/')"

Адрес 127.0.0.1 здесь правильный: проверка обращается к соседнему процессу внутри того же контейнера. Но сам сервер продолжает слушать 0.0.0.0, чтобы принимать и внешние обращения. Не переносите адрес из проверки в настройку сервера автоматически.

Интервал 5 секунд и таймаут 10 секунд оставляют запас на запуск команды в учебной среде. Пока успешной пробы ещё не было, в первые 10 секунд ошибки не учитываются. Успех может подтвердить готовность раньше и закончить эту отсрочку. После отсрочки две последовательные ошибки переводят контейнер в unhealthy. На реальном сервисе параметры выбирают под нагрузку и скорость запуска; сама проверка должна быть дешёвой.

Подробнее: HEALTHCHECK в документации Docker.

Если HTTP работает, но контейнер отмечен unhealthy, прочитайте результат самой команды проверки. Возможно, указан порт 8080 вместо 8000 или используется отсутствующий curl. Проверка — тоже программа, и её нужно отлаживать.

docker inspect --format '{{json .State.Health}}' qa-api
docker exec qa-api python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8000/').status)"

Не маскируйте ошибку командой exit 0 или || true: индикатор станет зелёным, а знания о сервисе исчезнут. В лаборатории ожидаются и состояние здоровья, и корректный внешний HTTP-ответ. Затем проверяющая среда временно приостанавливает HTTP-сервер: команда здоровья продолжает выполняться и должна заметить недоступность, переведя состояние в unhealthy. Постоянно успешная проба такой тест не пройдёт.

Само состояние unhealthy не означает, что обычный Docker автоматически перезапустит контейнер. Восстановление и управление трафиком требуют отдельной настройки платформы. В баг-репорте полезно разделить «проверка обнаружила проблему» и «система восстановилась».