Jak działają kontrole kondycji Dockera i dlaczego są ważne?

Question

Accepted Answer

**Kontrola kondycji** mówi Dockerowi (lub orkiestratorowi), jak określić, czy aplikacja kontenera faktycznie **działa**, a nie tylko się uruchomiła. Proces kontenera może być aktywny, podczas gdy aplikacja jest uszkodzona (zawieszenie, brak dostępu do bazy danych) — kontrole kondycji to wykrywają, aby platforma mogła zareagować.

## Definiowanie kontroli kondycji

```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 okresowo uruchamia polecenie kontroli kondycji; status kontenera staje się `healthy` lub `unhealthy` na podstawie wyniku (widoczne w `docker ps`).

## Uruchomione a zdrowe (kluczowe rozróżnienie)

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

## Dlaczego to ważne

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

## Dlaczego to ważne

Zrozumienie kontroli kondycji Dockera jest ważne dla **uruchamiania niezawodnych aplikacji kontenerowych**, dlatego jest to cenne operacyjne know-how.

Kluczową ideą jest rozróżnienie między **uruchomionym a zdrowym**: proces kontenera może być **aktywny, podczas gdy aplikacja jest faktycznie uszkodzona** (zawieszenie, zakleszczenie, brak dostępu do bazy danych) — i bez kontroli kondycji platforma wie tylko, że kontener się "uruchomił" i będzie **dalej kierować ruch do uszkodzonego kontenera**, powodując błędy.

Kontrole kondycji rozwiązują ten problem, definiując sposób weryfikacji, że aplikacja **faktycznie działa** (np. wysyłając żądanie do punktu końcowego `/health`), dzięki czemu status kontenera odzwierciedla rzeczywistą kondycję, a nie tylko żywotność procesu.

To ma znaczenie **operacyjnie**, ponieważ orkiestratory i narzędzia na nim działają: **restartują niezdrowe kontenery** (automatyczne odzyskiwanie po zawieszeniach/zakleszczeniach) i **kierują ruch tylko do zdrowych** (unikając wysyłania żądań do uszkodzonych instancji), a `depends_on: condition: service_healthy` w Compose wykorzystuje kontrole kondycji do czekania na rzeczywistą gotowość (rozwiązując wyścigi startowe).

Zrozumienie powiązanego rozróżnienia **liveness vs readiness** (czy jest żywy i powinien być zrestartowany, czy jest gotowy do odbierania ruchu) jest ważne, ponieważ **Kubernetes wykorzystuje sondy liveness i readiness** zbudowane na tej samej koncepcji — dlatego zrozumienie kontroli kondycji Dockera przenosi się bezpośrednio do środowisk orkiestrowanych.

Ponieważ niezawodna operacja wymaga rozróżnienia między "uruchomionym" a "rzeczywiście działającym" i reagowania na kontenery uszkodzone-ale-uruchomione (ich restartowaniem, wstrzymywaniem ruchu), a ponieważ kontrole kondycji są mechanizmem umożliwiającym to — używanym przez orkiestratory do self-healingu i routingu ruchu — zrozumienie kontroli kondycji Dockera jest cenne, praktycznie ważne know-how dla niezawodnego uruchamiania kontenerów, kluczowa praktyka dla odporności produkcyjnej, która zapobiega powszechnemu problemowi uszkodzonych kontenerów cicho pozostających w obrocie, oraz koncepcja fundamentalna dla tego, jak orkiestratory utrzymują kondycję aplikacji.