Hoe werken Docker health checks en waarom zijn ze belangrijk?

Question

Accepted Answer

Een **health check** vertelt Docker (of een orchestrator) hoe bepaald kan worden of de applicatie in een container **daadwerkelijk werkt**, niet alleen maar actief is. Een containerproces kan actief zijn terwijl de app kapot is (hangt, kan de database niet bereiken) — health checks detecteren dit zodat het platform kan reageren.

## Definiëren van een 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 voert de health-check-opdracht periodiek uit; de status van de container wordt `healthy` of `unhealthy` op basis van het resultaat (zichtbaar in `docker ps`).

## Actief vs gezond (het belangrijkste onderscheid)

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

## Waarom health checks operationeel belangrijk zijn

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

## Waarom het belangrijk is

Het begrijpen van Docker health checks is belangrijk voor het **uitvoeren van betrouwbare gecontaineriseerde applicaties**, dus het is waardevolle operationele kennis.

De cruciale inzicht is het onderscheid tussen **actief en gezond**: een containerproces kan **levend zijn terwijl de applicatie daadwerkelijk kapot is** (hangt, deadlock, kan de database niet bereiken) — en zonder een health check weet het platform alleen dat de container "actief" is en zal **traffic blijven routeren naar een kapotte container**, wat storingen veroorzaakt.

Health checks lossen dit op door te definiëren hoe geverifieerd kan worden dat de applicatie **daadwerkelijk werkt** (bijvoorbeeld door een `/health`-endpoint aan te roepen), zodat de status van de container echte gezondheid weerspiegelt, niet alleen proceslevendigheid.

Dit is **operationeel** belangrijk omdat orchestrators en tools er naar handelen: zij **herstarten ongezonde containers** (automatisch herstel van hangs/deadlocks) en **routeren traffic alleen naar gezonde containers** (voorkomen dat verzoeken naar kapotte instanties worden gestuurd), en Compose's `depends_on: condition: service_healthy` gebruikt health checks om op echte gereedheid te wachten (het opgelost opstartracecondities).

Het begrijpen van het gerelateerde **liveness vs readiness**-onderscheid (is het levend en moet het opnieuw worden gestart, vs is het klaar om traffic te ontvangen) is belangrijk, aangezien **Kubernetes liveness en readiness probes gebruikt** gebouwd op hetzelfde concept — dus het begrijpen van Docker health checks draagt direct over naar georkesterde omgevingen.

Omdat betrouwbare werking het onderscheid "actief" van "daadwerkelijk werkend" en reageren op kapotte-maar-actieve containers (herstart, verkeer blokkeren) vereist, en omdat health checks het mechanisme zijn dat dit mogelijk maakt — gebruikt door orchestrators voor zelfherstellende en verkeersroutering — het begrijpen van Docker health checks is waardevolle, praktisch-belangrijke kennis voor het betrouwbaar draaien van containers, een sleutelpraktijk voor productieverzekerheid die het veelvoorkomende probleem voorkomt dat kapotte containers stilzwijgend traffic blijven ontvangen, en een concept dat fundamenteel is voor hoe orchestrators de gezondheid van applicaties handhaven.