Jak fungují Docker health checks a proč jsou důležité?

Question

Accepted Answer

**Health check** (kontrola stavu) řekne Dockeru (nebo orchestrátoru), jak určit, zda aplikace v kontejneru skutečně **funguje**, ne jen běží. Proces kontejneru může běžet, zatímco aplikace je rozbitá (zamrzlá, neschopná dosáhnout své databáze) — health checks to detekují, aby platforma mohla reagovat.

## Definování health checku

```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 periodicky spustí příkaz health checku; stav kontejneru se stane `healthy` nebo `unhealthy` na základě výsledku (viditelné v `docker ps`).

## Běží vs zdravý (klíčové rozlišení)

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

## Proč health checks záleží operačně

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

## Proč to záleží

Porozumění Docker health checkům je důležité pro **spouštění spolehlivých kontejnerizovaných aplikací**, takže je to cenné operační知alství.

Klíčová myšlenka je rozdíl mezi **běží a je zdravý**: proces kontejneru může být **živý, zatímco aplikace je vlastně rozbitá** (zamrzlá, v deadlocku, neschopná dosáhnout své databáze) — a bez health checku platforma ví jen, že kontejner "běží" a bude **pokračovat v směrování provozu do rozbitého kontejneru**, což způsobuje chyby.

Health checks to řeší definováním, jak ověřit, že aplikace **skutečně funguje** (např. zavolání `/health` endpointu), takže stav kontejneru odráží skutečné zdraví, ne jen životaschopnost procesu.

To záleží **operačně**, protože orchestrátory a nástroje na to reagují: **restartují unhealthy kontejnery** (automatické zotavení z zamrznutí/deadlocků) a **směrují provoz pouze na zdravé** (vyhýbají se posílání požadavků na rozbitéinstance), a Compose `depends_on: condition: service_healthy` používá health checks k čekání na skutečnou připravenost (řeší startup races).

Porozumění souvisejícímu rozdílu **liveness vs readiness** (je naživu a měl by být restartován, vs je připraven přijímat provoz) je důležité, protože **Kubernetes používá liveness a readiness probes** postavené na stejném konceptu — takže porozumění Docker health checkům se přímo přenáší na orchestrované prostředí.

Proto, že spolehlivý provoz vyžaduje rozlišování "běží" od "skutečně funguje" a reagování na rozbitě-ale-běžící kontejnery (jejich restartování, zadržování provozu), a protože health checks jsou mechanismem umožňujícím to — používaným orchestrátory pro self-healing a routing provozu — porozumění Docker health checkům je cenné, prakticky důležité vědění pro spolehlivé spouštění kontejnerů, klíčová praxe pro produkční resilience, která zabraňuje běžnému problému rozbitých kontejnerů tiše pokračujících v přijímání provozu, a koncept základní pro to, jak orchestrátory udržují zdraví aplikace.