Что проверяет HEALTHCHECK
Инструкция HEALTHCHECK определяет команду, которую Docker запускает внутри контейнера через заданные интервалы. Если команда регулярно завершается с ненулевым кодом, контейнер получает статус unhealthy.
Пример HTTP health check
FROM python:3.12-slim
WORKDIR /app
COPY . .
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 CMD python -c "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')" || exit 1
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]
Параметры
--interval — как часто запускать проверку;
--timeout — максимальное время выполнения команды;
--start-period — период запуска, когда ранние ошибки не учитываются как обычные сбои;
--retries — число неуспешных проверок перед статусом unhealthy.
Healthcheck в Compose
services:
web:
image: my-app:latest
healthcheck:
test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')"]
interval: 30s
timeout: 5s
retries: 3
start_period: 20s
Что проверять
Liveness check отвечает на вопрос, жив ли процесс. Readiness check отвечает, готово ли приложение принимать трафик: например, завершилась ли инициализация и доступны ли критичные зависимости. Не стоит делать health endpoint слишком тяжёлым: он не должен запускать сложные запросы или создавать нагрузку на внешние сервисы.
Важное ограничение
Docker фиксирует health status, но restart policy не перезапускает контейнер только потому, что он стал unhealthy. В Kubernetes и других оркестраторах liveness/readiness probes могут влиять на перезапуск и маршрутизацию трафика.
Как ответить на собеседовании
Через HEALTHCHECK я задаю команду, которая регулярно проверяет состояние приложения и формирует статус healthy или unhealthy. Обычно это лёгкий endpoint /health. Важно понимать, что Docker сам не перезапускает unhealthy-контейнер, поэтому для автоматической реакции нужен оркестратор или внешний механизм мониторинга.