Cum funcționează verificările de sănătate în Docker și de ce sunt importante?

Question

Accepted Answer

O **verificare de sănătate** (health check) spune Docker-ului (sau unui orchestrator) cum să determine dacă aplicația unui container funcționează de fapt **corect**, nu doar că rulează. Procesul unui container poate fi activ în timp ce aplicația este blocată (hung, nu poate accesa baza de date) — verificările de sănătate detectează asta pentru ca platforma să poată reacționa.

## Definirea unei verificări de sănătate

```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 rulează periodic comanda de verificare a sănătății; statusul containerului devine `healthy` (sănătos) sau `unhealthy` (nesănătos) pe baza rezultatului (vizibil în `docker ps`).

## Rulând vs sănătos (distincția cheie)

```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.
```

## De ce verificările de sănătate sunt importante din punct de vedere operațional

```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
```

## De ce contează

Înțelegerea verificărilor de sănătate în Docker este importantă pentru **rularea aplicațiilor containerizate fiabile**, deci este o cunoaștere operațională valoroasă.

Insight-ul crucial este distincția dintre **rulând și sănătos**: procesul unui container poate fi **viu în timp ce aplicația este de fapt ruptă** (hung, deadlock, nu poate accesa baza de date) — și fără o verificare de sănătate, platforma doar știe că containerul "rulează" și va **continua să ruteze trafic către un container rupt**, cauzând defecțiuni.

Verificările de sănătate rezolvă asta definind cum să verific că aplicația **de fapt funcționează** (ex. apelând un endpoint `/health`), deci statusul containerului reflectă sănătatea reală, nu doar activitatea procesului.

Aceasta contează **operațional** deoarece orchestratorii și uneltele acționează pe baza ei: ei **restartează containerele nesănătoase** (recuperare automată din hangs/deadlocks) și **rutează trafic doar spre cele sănătoase** (evitând trimiterea cererilor la instanțe rupte), și `depends_on: condition: service_healthy` din Compose folosește verificări de sănătate pentru a aștepta pregătirea genuină (rezolvând curse de inițializare).

Înțelegerea distincției asociate **liveness vs readiness** (este viu și ar trebui restartat, vs este gata să primească trafic) este importantă, deoarece **Kubernetes folosește liveness și readiness probe** construite pe același concept — deci înțelegerea verificărilor de sănătate din Docker se transferă direct în medii orchestrate.

Cum operarea fiabilă necesită distincția dintre "rulând" și "de fapt funcționând" și reacția la containerele rupte-dar-rulând (reînceperea lor, reținerea traficului), și cum verificările de sănătate sunt mecanismul care permite asta — utilizat de orchestratori pentru self-healing și rutarea traficului — înțelegerea verificărilor de sănătate din Docker este cunoaștere valoroasă și practic importantă pentru rularea containerelor cu fiabilitate, o practică cheie pentru reziliență în producție care previne problema comună a containerelor rupte care continuă tăcut să primească trafic, și un concept fundamental în cum orchestratorii mențin sănătatea aplicației.