Hur fungerar Docker-hälsokontroller och varför är de viktiga?

Question

Accepted Answer

En **hälsokontroll** talar om för Docker (eller en orkestrator) hur man avgör om en containers applikation faktiskt **fungerar**, inte bara körs. En containers process kan vara igång medan appen är bruten (hängd, kan inte nå sin databas) — hälsokontroller detekterar detta så att plattformen kan reagera.

## Definiera en hälsokontroll

```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ör periodiskt hälsokontrollkommandot; containerens status blir `healthy` eller `unhealthy` baserat på resultatet (synlig i `docker ps`).

## Körs kontra frisk (huvudskillnaden)

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

## Varför hälsokontroller är viktiga operationellt

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

## Varför det är viktigt

Att förstå Docker-hälsokontroller är viktigt för **körning av pålitliga containeriserade applikationer**, så det är värdefull operativ kunskap.

Huvudinsikten är skillnaden mellan **körning och friskhet**: en containers process kan vara **igång medan applikationen faktiskt är bruten** (hängd, dödlås, kan inte nå sin databas) — och utan en hälsokontroll vet plattformen bara att containern "körs" och kommer att **fortsätta dirigera trafik till en bruten container**, vilket orsakar fel.

Hälsokontroller löser detta genom att definiera hur man verifierar att applikationen **faktiskt fungerar** (t.ex. genom att nå en `/health`-endpoint), så containerens status återspeglar verklig hälsa, inte bara processens liveness.

Detta är viktigt **operationellt** eftersom orkestratorer och verktyg agerar på det: de **startar om ohälsosamma containers** (automatisk återhämtning från hängningar/dödlås) och **dirigerar trafik endast till friska** (undviker att skicka förfrågningar till bruten instanser), och Composes `depends_on: condition: service_healthy` använder hälsokontroller för att vänta på verklig beredskap (löser startupkappkörningar).

Att förstå den relaterade **liveness kontra readiness**-skillnaden (är den igång och bör startas om, kontra är den redo att ta emot trafik) är viktigt, eftersom **Kubernetes använder liveness- och readiness-probes** byggda på samma koncept — så förståelse för Docker-hälsokontroller överförs direkt till orkestrerade miljöer.

Since pålitlig drift kräver att man skiljer "körs" från "fungerar faktiskt" och reagerar på bruten-men-körs-containers (startar om dem, håller inne trafik), och eftersom hälsokontroller är mekanismen som möjliggör detta — använd av orkestratorer för självreparation och trafikdirigerig — är förståelse för Docker-hälsokontroller värdefull, praktiskt-viktig kunskap för att köra containers på ett pålitligt sätt, en nyckelpraxis för produktionselasticitet som förhindrar det vanliga problemet med brutna containers som tyst fortsätter att ta emot trafik, och ett koncept som är grundläggande för hur orkestratorer upprätthåller programhälsa.