Hvordan fungerer Docker-sundhedstjek, og hvorfor er de vigtige?

Question

Accepted Answer

Et **sundhedstjek** fortæller Docker (eller en orkestrator) hvordan man bestemmer, om en containers applikation faktisk **fungerer**, ikke bare køres. En containers proces kan være aktiv, mens appen er ødelagt (hængt, kan ikke nå sin database) — sundhedstjek registrerer dette, så platformen kan reagere.

## Definition af et sundhedstjek

```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 kører periodisk sundhedstjek-kommandoen; containerens status bliver `healthy` eller `unhealthy` baseret på resultatet (synligt i `docker ps`).

## Kørende vs sundhedsmæssigt (den vigtige skelnen)

```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 sundhedstjek betyder noget operationelt

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

At forstå Docker-sundhedstjek er vigtig for **at køre pålidelige containeriserede applikationer**, så det er værdifuld operationel viden.

Den afgørende indsigt er skelnen mellem **kørende og sundhedsmæssigt**: en containers proces kan være **aktiv mens applikationen faktisk er ødelagt** (hængt, deadlock, kan ikke nå sin database) — og uden et sundhedstjek ved platformen kun, at containeren "kører" og vil **fortsætte med at sende trafik til en ødelagt container**, hvilket forårsager fejl.

Sundhedstjek løser dette ved at definere, hvordan man verificerer applikationen **faktisk fungerer** (f.eks. ved at ramme et `/health` endpoint), så containerens status afspejler faktisk sundhed, ikke bare proces-livlighed.

Dette betyder noget **operationelt**, fordi orkestratorer og værktøjer handler på det: de **genstarter usunde containere** (automatisk genopretning fra hængninger/deadlocks) og **sender trafik kun til sundhedsmæssigt gode** (undgår at sende anmodninger til ødelagte instanser), og Composes `depends_on: condition: service_healthy` bruger sundhedstjek til at vente på ægte parathed (løser startup-konkurrencer).

At forstå den relaterede **liveness vs readiness**-skelnen (er den aktiv og bør genstarts, versus er den klar til at modtage trafik) er vigtig, da **Kubernetes bruger liveness- og readiness-prøver** bygget på dette samme koncept — så forståelse af Docker-sundhedstjek overfører direkte til orkestrerede miljøer.

Fordi pålidelig drift kræver at skelne "kørende" fra "faktisk fungerende" og reagere på ødelagte-men-kørende containere (genstarte dem, holde trafik tilbage), og fordi sundhedstjek er mekanismen, der muliggør dette — brugt af orkestratorer til selvhealing og trafikruting — er forståelse af Docker-sundhedstjek værdifuld, praktisk vigtig viden for pålidelig drift af containere, en nøglepraksis for produktionsstabilitet, der forhindrer det almindelige problem med ødelagte containere, der stiltiende fortsætter med at modtage trafik, og et koncept, der er grundlæggende for hvordan orkestratorer opretholder applikationssundhed.