Docker health checks کیسے کام کرتے ہیں اور وہ کیوں اہم ہیں؟

Question

Accepted Answer

ایک **health check** Docker (یا orchestrator) کو بتاتا ہے کہ یہ کیسے معلوم کریں کہ container کی application دراصل **کام کر رہی ہے** یا نہیں، صرف چل رہی ہے۔ Container کا process چل رہا ہو سکتا ہے جبکہ app ٹوٹا ہوا ہو (hang، اپنے database تک نہیں پہنچ سکتا) — health checks یہ شناخت کرتے ہیں تاکہ platform رد عمل دے سکے۔

## Health check کی تعریف

```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 وقتاً فوقتاً health-check command چلاتا ہے؛ container کی status نتیجہ کی بنیاد پر `healthy` یا `unhealthy` بن جاتی ہے (جو `docker ps` میں نظر آتی ہے)۔

## چل رہا ہے بمقابلہ صحت مند (اہم فرق)

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

## Health checks کیوں operationally اہم ہیں

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

## یہ کیوں اہم ہے

Docker health checks کو سمجھنا **قابل اعتماد containerized applications چلانے** کے لیے اہم ہے، اس لیے یہ قیمتی operational knowledge ہے۔

اہم نقطہ **چل رہے اور صحت مند** میں فرق ہے: container کا process **زندہ ہو سکتا ہے جبکہ application دراصل ٹوٹی ہوئی ہو** (hung، deadlocked، اپنے database تک نہیں پہنچ سکتی) — اور بغیر health check کے، platform صرف یہ جانتا ہے کہ container "چل رہا ہے" اور **ٹوٹے ہوئے container کو traffic روٹ کرتے رہے گا**، جس سے failures ہوتی ہیں۔

Health checks یہ حل کرتے ہیں کہ یہ بتایا جائے کہ application **دراصل کیسے کام کرتی ہے** (مثال کے طور پر `/health` endpoint سے ٹکرانا)، تاکہ container کی status حقیقی صحت کو ظاہر کرے، نہ کہ صرف process liveness کو۔

یہ **operationally** اہم ہے کیونکہ orchestrators اور tools اس پر عمل کرتے ہیں: وہ **unhealthy containers کو restart کرتے ہیں** (hangs/deadlocks سے خود بخود recovery)، **صرف صحت مند containers کو traffic روٹ کرتے ہیں** (ٹوٹی ہوئی instances کو requests نہیں بھیجتے)، اور Compose کی `depends_on: condition: service_healthy` health checks استعمال کرتے ہوئے حقیقی readiness کا انتظار کرتی ہے (startup races حل کرتے ہوئے)۔

متعلقہ **liveness بمقابلہ readiness** فرق کو سمجھنا اہم ہے (کیا یہ زندہ ہے اور restart ہونا چاہیے، بمقابلہ کیا یہ traffic موصول کرنے کے لیے تیار ہے)، جیسا کہ **Kubernetes liveness اور readiness probes استعمال کرتا ہے** اسی concept کی بنیاد پر — اس لیے Docker health checks کو سمجھنا براہ راست orchestrated environments میں منتقل ہوتا ہے۔

چونکہ قابل اعتماد operation کے لیے "چل رہے" اور "دراصل کام کرنے" میں فرق کرنا ضروری ہے اور ٹوٹے ہوئے لیکن چل رہے containers پر رد عمل دینا (انہیں restart کرنا، traffic روکنا)، اور چونکہ health checks یہ میکانزم ہیں جو اسے ممکن بناتے ہیں — orchestrators میں self-healing اور traffic routing کے لیے استعمال ہوتے ہیں — Docker health checks کو سمجھنا containers کو قابل اعتماد طریقے سے چلانے کے لیے قیمتی، عملی طور پر اہم knowledge ہے، production resilience کے لیے کلیدی عمل جو ٹوٹے ہوئے containers کے خاموشی سے traffic موصول کرتے رہنے کے عام مسئلہ سے روکتا ہے، اور orchestrators کے کام کرنے کے لیے ایک بنیادی concept جو application health کو برقرار رکھتے ہیں۔