Docker health check'leri nasıl çalışır ve neden önemlidir?

Question

Accepted Answer

Bir **health check**, Docker'a (ya da bir orchestrator'a) bir container'ın uygulamasının aslında **çalışıp çalışmadığını** belirlemesini söyler; sadece running durumda olması değil. Bir container'ın process'i ayakta olabilir ancak uygulama bozuk olabilir (asılmış, veritabanına erişemeyen) — health check'ler bunu tespit eder, böylece platform tepki verebilir.

## Bir health check tanımlama

```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 periyodik olarak health-check komutunu çalıştırır; container'ın durumu sonuca göre `healthy` veya `unhealthy` olur (`docker ps` içinde görülebilir).

## Running vs healthy (temel ayrım)

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

## Neden önemli

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

## Neden önemli

Docker health check'lerini anlamak, **güvenilir containerize uygulamalar çalıştırmak** için önemlidir ve değerli operasyonel bilgidir.

Kritik fikir **running ve healthy arasındaki ayrımdır**: bir container'ın process'i **yaşarken uygulama aslında bozuk olabilir** (asılmış, deadlock'lanmış, veritabanına erişemeyen) — ve health check olmadan, platform yalnızca container'ın "çalışıyor" olduğunu bilir ve **bozuk bir container'a trafik yönlendirmeyi devam ettirir**, başarısızlıklara neden olur.

Health check'ler bunu uygulamanın **aslında çalışıp çalışmadığını** doğrulayarak çözer (örneğin bir `/health` endpoint'ine istek göndererek), böylece container'ın durumu sadece process canlılığı değil, gerçek sağlığını yansıtır.

Bu **operasyonel olarak** önemlidir çünkü orchestrator'lar ve araçlar bunu kullanır: **sağlıksız container'ları yeniden başlatırlar** (asılma/deadlock'dan otomatik kurtarma) ve **trafiği yalnızca sağlıklı container'lara yönlendirirler** (bozuk instance'lara istek gönderme), ve Compose'ın `depends_on: condition: service_healthy` health check'leri gerçek hazırlığı beklemek için kullanır (başlatma race'lerini çözer).

İlgili **liveness vs readiness** ayrımını anlamak (canlı mı ve yeniden başlatılmalı mı, vs trafik almaya hazır mı) önemlidir, çünkü **Kubernetes bu aynı konseptin üstüne inşa edilen liveness ve readiness probe'larını kullanır** — bu nedenle Docker health check'lerini anlamak doğrudan orchestrate ortamlarına aktarılır.

Güvenilir işlem "çalışıyor" ile "aslında çalışıyor" arasında ayırım yapmayı ve bozuk-ama-çalışan container'lara tepki vermeyi gerektirir (bunları yeniden başlatma, trafikten uzaklaştırma), ve health check'ler bu etkinleştirici mekanizma olduğundan — orchestrator'lar tarafından self-healing ve trafik yönlendirmesi için kullanılır — Docker health check'lerini anlamak, container'ları güvenilir bir şekilde çalıştırmak için değerli, pratik olarak önemli bilgidir, üretim esnekliği için temel bir uygulama, bozuk container'ların sessizce trafik almaya devam etmesi sorununu önler ve orchestrator'ların uygulama sağlığını nasıl sürdürdüğünün temeli olan bir konsepttir.