Hogyan működnek a Docker health check-ek és miért fontosak?

Question

Accepted Answer

A **health check** azt mondja meg a Docker-nek (vagy egy orchestrator-nak), hogy hogyan lehet megállapítani, hogy egy container alkalmazása valóban **működik-e**, nem csak fut-e. Egy container folyamata futhat, miközben az alkalmazás összetört (lefagyott, nem lehet elérni az adatbázisát) — a health check-ek ezt felismerik, így a platform reagálni tud.

## Health check definiálása

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

A Docker periodikusan futtatja a health-check parancsot; a container állapota `healthy` vagy `unhealthy` lesz az eredmény alapján (látható a `docker ps` parancsban).

## Futás vs healthy (a kulcsfontosságú különbség)

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

## Miért fontosak a health check-ek operacionálisan

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

## Miért számít

A Docker health check-ek megértése fontos a **megbízható konténerizált alkalmazások futtatásához**, így értékes operációs ismeret.

A lényegi felismerés az **futás és healthy közötti különbség**: egy container folyamata **élhet, miközben az alkalmazás valójában összetört** (lefagyott, deadlock-olt, nem lehet elérni az adatbázisát) — és health check nélkül a platform csak azt tudja, hogy a container "fut", és **továbbra is forgalmat irányít egy összetört container-hez**, ami hibákat okoz.

A health check-ek ezt oldják meg azáltal, hogy meghatározzák, hogyan lehet ellenőrizni, hogy az alkalmazás **valóban működik-e** (pl. egy `/health` végpont meghívásával), így a container állapota a valós egészséget tükrözi, nem csak a folyamat élettartamát.

Ez **operacionálisan** azért fontos, mert az orchestrator-ok és eszközök alapján cselekednex: **újraindítanak unhealthy container-eket** (automatikus helyreállítás lefagyás/deadlock-ból) és **csak healthy container-ekre irányítanak forgalmat** (elkerülve a kéréseket összetört példányoknak), és a Compose `depends_on: condition: service_healthy` a health check-eket használja a valódi készültség megvárásához (induláskori verseny megoldása).

A kapcsolódó **liveness vs readiness** megkülönböztetés megértése (él-e és újra kell-e indítani, vagy kész-e forgalmat fogadni) fontos, mivel a **Kubernetes liveness és readiness probe-okat használ**, amelyek erre a koncepcióra épülnek — így a Docker health check-ek megértése közvetlenül átadható az orchestrált környezetekre.

Mivel a megbízható működéshez szükséges a "futás" és az "valóban működik" közötti megkülönböztetés, valamint az összetört-de-futó container-ekre való reagálás (újraindítás, forgalom visszatartása), és mivel a health check-ek az ezt lehetővé tevő mechanizmus — az orchestrator-ok által az öngyógyításhoz és forgalomirányításhoz használva — a Docker health check-ek megértése értékes, gyakorlatilag fontos tudás a container-ek megbízható futtatásához, a termelési rugalmasság kulcsfontosságú gyakorlata, amely megakadályozza az összetört container-ek csendesen folyamatos forgalomfogadásának gyakori problémáját, és az a koncepció, amely alapvető az orchestrator-ok alkalmazásegészségének fenntartásához.