Как работают проверки здоровья Docker и почему они важны?

Question

Accepted Answer

**Проверка здоровья** (health check) сообщает Docker (или оркестратору), как определить, действительно ли **работает** приложение контейнера, а не просто **запущено**. Процесс контейнера может быть включен, а приложение неработоспособным (зависло, не может достичь базы данных) — проверки здоровья это обнаруживают, позволяя платформе принять меры.

## Определение проверки здоровья

```dockerfile
# in a Dockerfile
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1
# → Docker runs this command periodically; exit 0 = healthy, non-zero = unhealthy
```

```yaml
# in docker-compose.yml
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s
  timeout: 3s
  retries: 3
  start_period: 10s    # grace period on startup before failures count
```

Docker периодически запускает команду проверки здоровья; статус контейнера становится `healthy` или `unhealthy` на основе результата (видно в `docker ps`).

## Запущен или здоров (ключевое различие)

```text
RUNNING → the container's process is alive (but the APP might be hung/broken)
HEALTHY → the health check confirms the app actually WORKS (responds correctly)
→ A container can be RUNNING but NOT HEALTHY (e.g. the app deadlocked, lost its DB).
  Without a health check, the platform only knows "running" — and keeps sending traffic
  to a broken container.
```

## Почему проверки здоровья важны с точки зрения операционной деятельности

```text
✓ ORCHESTRATORS use them: restart unhealthy containers; route traffic only to healthy ones
✓ Compose depends_on: condition: service_healthy → wait for real readiness
✓ LIVENESS (is it alive? restart if not) vs READINESS (ready for traffic? hold traffic if not)
  → Kubernetes uses liveness + readiness probes (the same concept, more granular)
✓ Prevents serving requests from broken-but-running containers
```

## Почему это важно

Понимание проверок здоровья Docker важно для **запуска надежных контейнеризованных приложений**, поэтому это ценные операционные знания.

Ключевое понимание — различие между **запущено и здорово**: процесс контейнера может быть **живым, а приложение на самом деле сломано** (зависло, в дедлоке, не может достичь базы данных) — и без проверки здоровья платформа знает только, что контейнер "запущен", и будет **продолжать маршрутизировать трафик на сломанный контейнер**, вызывая сбои.

Проверки здоровья решают эту проблему, определяя, как проверить, что приложение **действительно работает** (например, обращение к эндпоинту `/health`), так что статус контейнера отражает реальное здоровье, а не только живость процесса.

Это важно **с точки зрения операционной деятельности**, потому что оркестраторы и инструменты действуют на основе этого: они **перезапускают нездоровые контейнеры** (автоматическое восстановление от зависаний/дедлоков) и **маршрутизируют трафик только к здоровым** (избегая отправки запросов на сломанные экземпляры), и `depends_on: condition: service_healthy` в Compose использует проверки здоровья для ожидания настоящей готовности (решая проблемы ребаланса при старте).

Понимание связанного различия **живость vs готовность** (живо ли оно и должно ли быть перезапущено, или оно готово получать трафик) важно, так как **Kubernetes использует liveness и readiness probes**, построенные на этой же концепции — поэтому понимание проверок здоровья Docker напрямую переносится на оркестрированные окружения.

Поскольку надежная операционная деятельность требует различения "запущено" от "действительно работает" и реакции на сломанные, но работающие контейнеры (перезапуск, отвод трафика), и поскольку проверки здоровья — это механизм, позволяющий это осуществлять — используемый оркестраторами для самоисцеления и маршрутизации трафика — понимание проверок здоровья Docker является ценными, практически важные знания для надежного запуска контейнеров, ключевой практикой для устойчивости в production, которая предотвращает распространенную проблему, когда сломанные контейнеры молча продолжают получать трафик, и концепцией, фундаментальной для того, как оркестраторы поддерживают здоровье приложений.