كيف تعمل فحوصات صحة Docker ولماذا تكون مهمة؟

Question

Accepted Answer

**فحص الصحة** يخبر Docker (أو منسق الأوركسترا) كيفية تحديد ما إذا كان تطبيق الحاوية **يعمل فعلاً**، وليس فقط قيد التشغيل. يمكن أن تكون عملية الحاوية نشطة بينما التطبيق معطوب (مُتعلق، غير قادر على الوصول إلى قاعدة البيانات الخاصة به) — فحوصات الصحة تكتشف هذا لكي تتمكن المنصة من التفاعل.

## تعريف فحص الصحة

```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 بتشغيل أمر فحص الصحة بشكل دوري؛ تصبح حالة الحاوية `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.
```

## لماذا تكون فحوصات الصحة مهمة تشغيلياً

```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`)، لذا تعكس حالة الحاوية الصحة الحقيقية، وليس فقط حيوية العملية.

هذا مهم **تشغيلياً** لأن منسقات الأوركسترا والأدوات تتصرف بناءً عليه: فهي **تعيد تشغيل الحاويات غير الصحية** (الاسترجاع التلقائي من الأعطال/الأقفال) و**توجه حركة المرور فقط إلى الحاويات الصحية** (تجنب إرسال الطلبات إلى الحالات المعطوبة)، و`depends_on: condition: service_healthy` في Compose يستخدم فحوصات الصحة للانتظار من أجل الجاهزية الحقيقية (حل مشاكل بدء التشغيل).

فهم التمييز **الحيوية مقابل الجاهزية** ذو الصلة (هل هي حية وجب إعادة تشغيلها، مقابل هل هي جاهزة لاستقبال حركة المرور) مهم، لأن **Kubernetes يستخدم مسابير الحيوية والجاهزية** المبنية على نفس المفهوم — لذا فهم فحوصات صحة Docker ينتقل مباشرة إلى بيئات مُنسقة.

بما أن التشغيل الموثوق يتطلب التمييز بين "التشغيل" و"العمل الفعلي" والتفاعل مع الحاويات المعطوبة ولكن التي تعمل (إعادة تشغيلها، حجب حركة المرور)، وبما أن فحوصات الصحة هي الآلية التي تمكن هذا — تُستخدم من قبل منسقات الأوركسترا للشفاء الذاتي وتوجيه حركة المرور — فإن فهم فحوصات صحة Docker معرفة قيمة وعملياً مهمة لتشغيل الحاويات بموثوقية، وممارسة أساسية لمرونة الإنتاج التي تمنع المشكلة الشائعة للحاويات المعطوبة التي تستمر بصمت في استقبال حركة المرور، ومفهوم أساسي لكيفية حفاظ منسقات الأوركسترا على صحة التطبيق.