Docker health checks কীভাবে কাজ করে এবং সেগুলি কেন গুরুত্বপূর্ণ?

Question

Accepted Answer

একটি **health check** Docker (বা একটি orchestrator) কে বলে দেয় যে কীভাবে নির্ধারণ করতে হবে একটি container এর application সত্যিই **কাজ করছে** কিনা, শুধু চলছে কিনা নয়। একটি container এর process চলমান থাকতে পারে যখন app ভাঙ্গা (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 চালায়; container এর status `healthy` বা `unhealthy` হয় ফলাফলের উপর ভিত্তি করে (`docker ps` এ দৃশ্যমান)।

## চলমান vs 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 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 জ্ঞান।

চূড়ান্ত insight হল **চলমান এবং healthy এর মধ্যে পার্থক্য**: একটি container এর process **জীবিত থাকতে পারে যখন application সত্যিই ভাঙ্গা** (hung, deadlocked, তার database এ পৌঁছাতে পারে না) — এবং health check ছাড়া, platform শুধু জানে container "চলছে" এবং **একটি ভাঙ্গা container এ traffic রুট করতে থাকবে**, failures সৃষ্টি করবে।

Health checks এটি সমাধান করে application সত্যিই **কাজ করে** এমনটি যাচাই করার পদ্ধতি সংজ্ঞায়িত করে (যেমন `/health` endpoint এ hit করা), তাই container এর status প্রকৃত health প্রতিফলিত করে, শুধু process liveness নয়।

এটি **operationally** গুরুত্বপূর্ণ কারণ orchestrators এবং tools এটিতে কাজ করে: তারা **unhealthy containers কে restart করে** (hangs/deadlocks থেকে স্বয়ংক্রিয় পুনরুদ্ধার) এবং **শুধুমাত্র healthy containers এ traffic রুট করে** (broken instances এ requests পাঠানো এড়িয়ে চলে), এবং Compose এর `depends_on: condition: service_healthy` health checks ব্যবহার করে খাঁটি readiness এর জন্য অপেক্ষা করতে (startup races সমাধান করে)।

সম্পর্কিত **liveness vs readiness** পার্থক্য বোঝা গুরুত্বপূর্ণ (এটি alive এবং restart করা উচিত কিনা, vs এটি traffic প্রাপ্ত করার জন্য প্রস্তুত কিনা) কারণ **Kubernetes liveness এবং readiness probes ব্যবহার করে** এই একই concept এর উপর নির্মিত — তাই Docker health checks বোঝা সরাসরি orchestrated পরিবেশগুলিতে স্থানান্তরিত হয়।

যেহেতু নির্ভরযোগ্য operation "চলছে" এবং "আসলে কাজ করছে" এর মধ্যে পার্থক্য এবং broken-but-running containers এ প্রতিক্রিয়া জানানো (তাদের restart করা, traffic withhold করা) প্রয়োজন, এবং যেহেতু health checks হল এটি সক্ষম করার mechanism — orchestrators দ্বারা self-healing এবং traffic routing এর জন্য ব্যবহৃত — Docker health checks বোঝা মূল্যবান, ব্যবহারিক-গুরুত্বপূর্ণ জ্ঞান containers নির্ভরযোগ্যভাবে চালানোর জন্য, production resilience এর জন্য একটি key practice যা broken containers নীরবে চলতে থাকার সাধারণ সমস্যা থেকে রক্ষা করে traffic প্রাপ্ত হতে থাকা, এবং একটি concept foundation যা কীভাবে orchestrators application health বজায় রাখে তার ভিত্তি।