Docker ਸਿਹਤ ਜांच ਕਿਵੇਂ ਕਾਮ ਕਰਦੀ ਹੈ ਅਤੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹਨ?

Question

Accepted Answer

ਇੱਕ **health check** Docker (ਜਾਂ ਇੱਕ orchestrator) ਨੂੰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ container ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ **ਕਾਮ ਕਰ ਰਹੀ ਹੈ**, ਸਿਰਫ ਚਲ ਰਹੀ ਹੈ। ਇੱਕ container ਦੀ ਪ੍ਰਕਿਰਿਆ ਚਾਲੂ ਹੋ ਸਕਦੀ ਹੈ ਜਦਕਿ ਐਪ ਟੁੱਟੀ ਹੋਈ ਹੈ (hung, ਆਪਣਾ database ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ) — health checks ਇਸ ਨੂੰ ਖੋਜ ਲੈਂਦੀਆਂ ਹਨ ਤਾਂਜੋ ਪਲੇਟਫਾਰਮ ਪ੍ਰਤਿਕ੍ਰਿਆ ਕਰ ਸਕੇ।

## 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 ਕਮਾਂਡ ਚਲਾਉਂਦਾ ਹੈ; container ਦੀ ਸਥਿਤੀ ਨਤੀਜੇ ਦੀ ਆਧਾਰ ਤੇ `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 ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ

```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 ਨੂੰ ਸਮਝਣਾ **reliable containerized applications ਚਲਾਉਣ** ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਸ ਲਈ ਇਹ ਮੁੱਲਵਾਨ ਓਪਰੇਸ਼ਨਲ ਗਿਆਨ ਹੈ।

ਮੁੱਖ ਸਮਝ ਹੈ **ਚਲ ਰਿਹਾ ਹੈ ਅਤੇ ਸਿਹਤਮੰਦ ਹੈ** ਵਿੱਚ ਫਰਕ: ਇੱਕ container ਦੀ ਪ੍ਰਕਿਰਿਆ **ਜੀਵਤ ਹੋ ਸਕਦੀ ਹੈ ਜਦਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਟੁੱਟੀ ਹੋਈ ਹੈ** (hung, deadlocked, ਆਪਣੇ database ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ) — ਅਤੇ ਬਿਨਾ health check ਦੇ, ਪਲੇਟਫਾਰਮ ਸਿਰਫ ਜਾਣਦਾ ਹੈ ਕਿ container "ਚਲ ਰਹਿ ਹੈ" ਅਤੇ ਇੱਕ ਟੁੱਟੀ ਹੋਈ container ਨੂੰ ਆਵਾਜਾਈ ਭੇਜਦਾ ਰਹੇਗਾ, ਨੁਕਸਾਨ ਕਾਰਨ ਬਣਾ ਦੇਵੇ।

Health checks ਇਸ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਕੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ **ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ** (ਜਿਵੇਂ `/health` endpoint ਨੂੰ ਹਿੱਟ ਕਰਨਾ), ਤਾਂਜੋ container ਦੀ ਸਥਿਤੀ ਸਿਰਫ ਪ੍ਰਕਿਰਿਆ liveness ਨਾ ਹੋ ਕੇ ਅਸਲ ਸਿਹਤ ਨੂੰ ਪ੍ਰਤੀਬਿੰਬਿਤ ਕਰੇ।

ਇਹ **ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ** ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ orchestrators ਅਤੇ ਟੂਲਸ ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ: ਉਹ **unhealthy containers ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ** (hangs/deadlocks ਤੋਂ ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ) ਅਤੇ **ਸਿਰਫ healthy ਵਿੱਚ ਆਵਾਜਾਈ ਭੇਜਦੇ ਹਨ** (ਟੁੱਟੀਆਂ instances ਨੂੰ requests ਭੇਜਣ ਤੋਂ ਬਚਦੇ ਹਨ), ਅਤੇ Compose ਦਾ `depends_on: condition: service_healthy` health checks ਨੂੰ ਵਰਤ ਕੇ genuine readiness ਲਈ ਉਡੀਕ ਕਰਦਾ ਹੈ (startup races ਹੱਲ ਕਰਦੇ ਹੋਏ)।

ਸੰਬੰਧਿਤ **liveness vs readiness** ਫਰਕ ਨੂੰ ਸਮਝਣਾ (ਕੀ ਇਹ ਜੀਵਤ ਹੈ ਅਤੇ restarted ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਬਨਾਮ ਕੀ ਇਹ traffic ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ) ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ **Kubernetes ਨੇ liveness ਅਤੇ readiness probes ਵਰਤੀਆਂ ਹਨ** ਇਸੇ ਧਾਰਣਾ ਦੀ ਆਧਾਰ 'ਤੇ — ਤਾਂਜੋ Docker health checks ਨੂੰ ਸਮਝਣਾ orchestrated environments ਵਿੱਚ ਸਿੱਧੇ ਟ੍ਰਾਂਸਫਰ ਹੁੰਦਾ ਹੈ।

Kyunkि reliable operation ਲਈ "ਚਲ ਰਿਹਾ ਹੈ" ਤੋਂ "ਅਸਲ ਵਿੱਚ ਕਾਮ ਕਰ ਰਹਿ ਹੈ" ਵਿੱਚ ਫਰਕ ਕਰਨਾ ਅਤੇ ਟੁੱਟੀਆਂ-ਪਰ-ਚਲ ਰਹੀਆਂ containers ਲਈ ਕਾਰਵਾਈ ਕਰਨੀ (ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ, traffic ਰੋਕਣਾ) ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ kise health checks ਇਸ ਨੂੰ enable ਕਰਨ ਵਾਲਾ ਮਨੋਚਿਕਤਸਾ ਹੈ — orchestrators ਦੁਆਰਾ self-healing ਅਤੇ traffic routing ਲਈ ਵਰਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ — Docker health checks ਨੂੰ ਸਮਝਣਾ ਮੁੱਲਵਾਨ, ਪ੍ਰੈਕਟੀਕਲ-ਮਹੱਤਵਪੂਰਨ ਗਿਆਨ ਹੈ containers ਨੂੰ reliably ਚਲਾਉਣ ਲਈ, production resilience ਲਈ ਮੁੱਖ ਪ੍ਰਯਾਸ ਜੋ ਆਮ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਦਾ ਹੈ ਟੁੱਟੀਆਂ containers ਦਾ ਸ਼ਾਂਤ ਨਾਲ traffic ਨਿਰੰਤਰ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਅਤੇ ਇੱਕ ਧਾਰਨਾ ਜੋ ਸਧਾਰਨ ਹੈ ਕਿ ਕਿਵੇਂ orchestrators application ਸਿਹਤ ਨੂੰ maintain ਕਰਦੇ ਹਨ।