Docker health checks कसरी काम गर्छन् र तिनीहरू किन महत्त्वपूर्ण छन्?

Question

Accepted Answer

एक **health check** ले Docker (वा एक orchestrator) लाई यो निर्धारण गर्न बताउँछ कि कन्टेनरको एप्लिकेसन वास्तवमा **काम गरिरहेको छ** वा सिर्फ चलिरहेको छ। कन्टेनरको प्रक्रिया माथि हुन सक्छ जबकि एप (hung, अपनो 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 चलाउँछ; कन्टेनरको स्थिति परिणामको आधारमा `healthy` वा `unhealthy` हुन्छ (जो `docker ps` मा दृश्यमान छ)।

## चलिरहेको बनाम healthy (मुख्य भेद)

```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 किन सञ्चालनात्मक रूपमा महत्त्वपूर्ण छन्

```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 अनुप्रयोगहरू चलाउनको लागि** महत्त्वपूर्ण छ, त्यसैले यो मूल्यवान सञ्चालनात्मक ज्ञान हो।

मूल अन्तर्दृष्टि **चलिरहेको र healthy बीचको भेद** हो: कन्टेनरको प्रक्रिया **जीवित हुन सक्छ जबकि एप्लिकेसन वास्तवमा टुट्टिएको हुन सक्छ** (hung, deadlocked, अपनो database तक पहुँच गर्न सक्दैन) — र health check बिना, platform केवल जान्दछ कि कन्टेनर "चलिरहेको छ" र **टुट्टिएको कन्टेनरमा ट्राफिक रूट गरिरहनेछ**, जसले विफलताहरू निम्त्याउँछ।

Health checks यो समस्या समाधान गर्छ कि एप **वास्तवमा काम गर्छ भनेर कसरी प्रमाणित गर्ने** (उदाहरणको लागि `/health` endpoint मा हिट गर्दै), त्यसैले कन्टेनरको स्थिति सिर्फ प्रक्रिया जीवकलापको सट्टा वास्तविक स्वास्थ्य प्रतिबिम्बित गर्छ।

यो **सञ्चालनात्मक रूपमा** महत्त्वपूर्ण छ किनभने orchestrators र उपकरणहरू यसमा कार्य गर्छन्: तिनीहरू **unhealthy कन्टेनरहरू पुनरारम्भ गर्छन्** (hung/deadlock बाट स्वचालित पुनरुद्धार) र **केवल healthy कन्टेनरहरूमा ट्राफिक रूट गर्छन्** (टुट्टिएको अवस्थामा अनुरोधहरू पठाउन बचाउँछन्), र Compose को `depends_on: condition: service_healthy` health checks प्रयोग गर्छ वास्तविक तैयारीको लागि प्रतीक्षा गर्न (स्टार्टअप दौड समाधान गर्दै)।

सम्बन्धित **liveness बनाम readiness** भेद बुझ्न (के यो जीवित छ र पुनरारम्भ गरिनुपर्छ, बनाम के यो ट्राफिक प्राप्त गर्न तयार छ) महत्त्वपूर्ण छ, किनभने **Kubernetes लiveness र readiness probes प्रयोग गर्छ** यसै अवधारणामा निर्मित — त्यसैले Docker health checks बुझ्न सीधा orchestrated वातावरणहरूमा स्थानान्तरण गर्छ।

विश्वासयोग्य सञ्चालनको लागि "चलिरहेको" र "वास्तवमा काम गरिरहेको" बीच भेद गर्न र टुट्टिएको-तर-चलिरहेको कन्टेनरहरूमा प्रतिक्रिया गर्न (तिनीहरूलाई पुनरारम्भ गर्दै, ट्राफिक रोक्दै) आवश्यक छ, र किनभने health checks यो सक्षमता गर्न तंत्र हो — orchestrators द्वारा स्व-उपचार र ट्राफिक रूटिङको लागि प्रयोग गरिएको — Docker health checks बुझ्न कन्टेनरहरू विश्वासयोग्य रूपमा चलाउनको लागि मूल्यवान, व्यावहारिक-महत्त्वपूर्ण ज्ञान हो, उत्पादन स्थिति्यता को लागि एक मुख्य अनुशीलन जो टुट्टिएको कन्टेनरहरू मौन रूपमा ट्राफिक प्राप्त गरिरहने सामान्य समस्याको रोकथाम गर्छ, र orchestrators एप्लिकेसन स्वास्थ्य कसरी बनाए राखें भनेर अवधारणा आधारभूत हो।