Come funzionano i health check di Docker e perché sono importanti?

Question

Accepted Answer

Un **health check** dice a Docker (o a un orchestrator) come determinare se l'applicazione del container sta effettivamente **funzionando**, non solo in esecuzione. Il processo di un container può essere attivo mentre l'app è rotta (bloccata, non riesce a raggiungere il database) — gli health check rilevano questo in modo che la piattaforma possa reagire.

## Definire un health check

```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 esegue periodicamente il comando dell'health check; lo stato del container diventa `healthy` o `unhealthy` in base al risultato (visibile in `docker ps`).

## Esecuzione vs salute (la distinzione fondamentale)

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

## Perché gli health check sono importanti operativamente

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

## Perché è importante

Comprendere gli health check di Docker è importante per **eseguire applicazioni containerizzate affidabili**, quindi è una conoscenza operativa preziosa.

L'insight cruciale è la distinzione tra **in esecuzione e salutare**: il processo di un container può essere **attivo mentre l'applicazione è effettivamente rotta** (bloccata, in deadlock, non riesce a raggiungere il database) — e senza un health check, la piattaforma sa solo che il container è "in esecuzione" e continuerà a **instradare il traffico a un container rotto**, causando errori.

Gli health check risolvono questo definendo come verificare che l'applicazione **effettivamente funzioni** (ad es. accedendo a un endpoint `/health`), in modo che lo stato del container rispecchi la vera salute, non solo la liveness del processo.

Questo è importante **operativamente** perché gli orchestrator e gli strumenti agiscono su di esso: **riavviano i container non salutari** (ripresa automatica da blocchi/deadlock) e **instradano il traffico solo a quelli salutari** (evitando di inviare richieste a istanze rotte), e la condizione `depends_on: condition: service_healthy` di Compose usa gli health check per attendere la vera prontezza (risolvendo le corse di avvio).

Comprendere la distinzione correlata **liveness vs readiness** (è vivo e deve essere riavviato, vs è pronto a ricevere traffico) è importante, poiché **Kubernetes usa sonde di liveness e readiness** costruite su questo stesso concetto — quindi la comprensione degli health check di Docker si trasferisce direttamente a ambienti orchestrati.

Poiché l'operazione affidabile richiede di distinguere "in esecuzione" da "effettivamente funzionante" e di reagire ai container rotti ma in esecuzione (riavviarli, trattenere il traffico), e poiché gli health check sono il meccanismo che consente questo — utilizzato dagli orchestrator per self-healing e routing del traffico — comprendere gli health check di Docker è una conoscenza preziosa e praticamente importante per eseguire container in modo affidabile, una pratica chiave per la resilienza in produzione che previene il problema comune di container rotti che continuano silenziosamente a ricevere traffico, e un concetto fondamentale per il modo in cui gli orchestrator mantengono la salute dell'applicazione.