Hvordan fungerer Docker health checks og hvorfor er de viktige?

Question

Accepted Answer

En **health check** forteller Docker (eller en orchestrator) hvordan man kan bestemme om en containers applikasjon faktisk **fungerer**, ikke bare kjører. En containers prosess kan være oppe mens appen er ødelagt (hengt opp, kan ikke nå sin database) — health checks oppdager dette slik at plattformen kan reagere.

## Definer en 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 kjører health-check-kommandoen periodisk; containerens status blir `healthy` eller `unhealthy` basert på resultatet (synlig i `docker ps`).

## Kjører vs healthy (hovedskillet)

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

## Hvorfor health checks er viktige operasjonelt

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

## Hvorfor det betyr noe

Å forstå Docker health checks er viktig for **å kjøre pålitelige containeriserte applikasjoner**, så det er verdifull operasjonell kunnskap.

Den avgjørende innsikten er skillet mellom **kjører og healthy**: en containers prosess kan være **aktiv mens applikasjonen faktisk er ødelagt** (hengt opp, deadlocked, kan ikke nå sin database) — og uten en health check vet plattformen bare at containeren "kjører" og vil **fortsette å rute trafikk til en ødelagt container**, noe som forårsaker feil.

Health checks løser dette ved å definere hvordan man verifiserer at applikasjonen **faktisk fungerer** (f.eks. ved å slå på en `/health` endpoint), slik at containerens status gjenspeiler reell helse, ikke bare prosessliveness.

Dette betyr noe **operasjonelt** fordi orchestratorer og verktøy handler på det: de **starter uhealthy containere på nytt** (automatisk gjenoppretting fra henging/deadlocks) og **ruter trafikk bare til healthy containere** (unngår å sende forespørsler til ødelagte instanser), og Composes `depends_on: condition: service_healthy` bruker health checks for å vente på ekte beredskap (løser oppstartskappløp).

Å forstå det relaterte **liveness vs readiness** skillet (er det i live og bør det startes på nytt, versus er det klar til å motta trafikk) er viktig, da **Kubernetes bruker liveness og readiness probes** bygget på samme konsept — så å forstå Docker health checks overføres direkte til orkestrerte miljøer.

Siden pålitelig drift krever å skille mellom "kjører" og "faktisk fungerer" og reagere på ødelagte-men-kjørende containere (starte dem på nytt, holde tilbake trafikk), og siden health checks er mekanismen som muliggjør dette — brukt av orchestratorer for selv-healing og trafikkoversettelse — er det å forstå Docker health checks verdifull, praktisk-viktig kunnskap for å kjøre containere pålitelig, en nøkkelpraksis for produksjonsmotstandskraft som forhindrer det vanlige problemet med ødelagte containere som stille fortsetter å motta trafikk, og et konsept som er grunnleggende for hvordan orchestratorer opprettholder programhelse.