Kako funkcioniraju Docker health checkovi i zašto su važni?

Question

Accepted Answer

**Health check** govori Dockeru (ili orkestratoru) kako odrediti je li aplikacija u kontejneru zaista **radi**, ne samo da je pokrenuta. Proces kontejnera može biti aktivan dok je aplikacija neispravna (zaglavljena, ne može dosegnuti bazu podataka) — health checkovi to detektiraju kako bi platforma mogla reagirati.

## Definiranje health checka

```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 periodički pokreće health-check naredbu; status kontejnera postaje `healthy` ili `unhealthy` na temelju rezultata (vidljivo u `docker ps`).

## Pokrenuto vs zdravo (ključna razlika)

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

## Zašto su health checkovi operacionalno važni

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

## Zašto je to važno

Razumijevanje Docker health checkova je važno za **pokretanje pouzdanih kontejneriziranih aplikacija**, pa je to vrijedan operacijski知識.

Klučna je razlika između **pokrenuto i zdravo**: proces kontejnera može biti **živ dok je aplikacija zapravo neispravna** (zaglavljena, deadlock, ne može dosegnuti bazu podataka) — a bez health checka, platforma samo zna da je kontejner "pokrenut" i će **nastaviti usmjeravati promet do neispravljenog kontejnera**, što uzrokuje kvarove.

Health checkovi rješavaju ovo definiranjem kako provjeriti da aplikacija **zaista radi** (npr. pristup `/health` endpointu), tako da status kontejnera odražava stvarno zdravlje, a ne samo vitalnost procesa.

Ovo je operacionalno važno jer orkestratora i alati djeluju na temelju toga: oni **ponovno pokreću nezdrave kontejnere** (automatska oporavka od zaglavljenja/deadlockova) i **usmjeravaju promet samo do zdravih** (izbjegavajući slanje zahtjeva neispravljenim instancama), a Composev `depends_on: condition: service_healthy` koristi health checkove kako bi čekao pravo spremnost (rješavajući race conditionse pri pokretanju).

Razumijevanje povezane razlike **liveness vs readiness** (je li živo i trebalo bi ga ponovno pokrenuti, naspram je li spremno primiti promet) je važno, jer **Kubernetes koristi liveness i readiness probe-e** izgrađene na istom konceptu — pa se razumijevanje Docker health checkova direktno prenosi na orkestracijska okruženja.

Budući da pouzdano poslovanje zahtijeva razlikovanje "pokrenuto" od "zapravo radi" i reagiranje na neispravljene-ali-pokrenut kontejnere (ponovno ih pokretanje, odbijanje prometa), i budući da su health checkovi mehanizam koji to omogućava — korišten od strane orkestratora za samozacjeljivanje i usmjeravanje prometa — razumijevanje Docker health checkova je vrijedan, praktično-važan znanja za pouzdano pokretanje kontejnera, ključna praksa za rezilijanost produkcije koja sprječava čest problem da neispravljeni kontejneri tiho nastave primati promet, i koncept fundamentalan kako orkestratora održavaju zdravlje aplikacije.