Docker health checks ทำงานอย่างไร และทำไมจึงสำคัญ?

Question

Accepted Answer

**health check** บอก Docker (หรือ orchestrator) ว่าจะระบุได้อย่างไรว่าแอปพลิเคชันใน container กำลัง **ทำงานได้จริง** ไม่ใช่แค่รันอยู่ process ของ container อาจทำงานอยู่ในขณะที่แอปพังไปแล้ว (ค้าง เชื่อมต่อ database ไม่ได้) — health check ตรวจจับสิ่งนี้เพื่อให้แพลตฟอร์มสามารถตอบสนองได้

## การกำหนด 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`)

## running กับ 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 check จึงสำคัญในเชิงปฏิบัติงาน

```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 เป็นเรื่องสำคัญสำหรับ **การรันแอปพลิเคชันแบบ container อย่างน่าเชื่อถือ** ดังนั้นจึงเป็นความรู้เชิงปฏิบัติงานที่มีคุณค่า

ข้อค้นพบสำคัญคือความแตกต่างระหว่าง **running กับ healthy**: process ของ container อาจ **ทำงานอยู่ในขณะที่แอปพลิเคชันพังไปแล้วจริง ๆ** (ค้าง deadlock เชื่อมต่อ database ไม่ได้) — และหากไม่มี health check แพลตฟอร์มจะรู้แค่ว่า container "กำลังรัน" และจะ **route traffic ไปยัง container ที่พังอยู่ต่อไป** ทำให้เกิดความล้มเหลว

health check แก้ปัญหานี้โดยกำหนดวิธีตรวจสอบว่าแอปพลิเคชัน **ทำงานได้จริง** (เช่น เรียก endpoint `/health`) เพื่อให้สถานะของ container สะท้อนสุขภาพที่แท้จริง ไม่ใช่แค่ความมีชีวิตของ process

เรื่องนี้สำคัญใน **เชิงปฏิบัติงาน** เพราะ orchestrator และเครื่องมือต่าง ๆ ทำงานตามสถานะนี้: พวกมัน **restart container ที่ unhealthy** (กู้คืนอัตโนมัติจากการค้าง/deadlock) และ **route traffic ไปยังตัวที่ healthy เท่านั้น** (หลีกเลี่ยงการส่ง request ไปยัง instance ที่พัง) และ `depends_on: condition: service_healthy` ของ Compose ใช้ health check เพื่อรอความพร้อมที่แท้จริง (แก้ปัญหา race ตอน startup)

การเข้าใจความแตกต่างที่เกี่ยวข้องอย่าง **liveness กับ readiness** (มันยังมีชีวิตและควร restart หรือไม่ เทียบกับ มันพร้อมรับ traffic หรือไม่) เป็นเรื่องสำคัญ เพราะ **Kubernetes ใช้ liveness และ readiness probes** ที่สร้างขึ้นบนแนวคิดเดียวกันนี้ — ดังนั้นการเข้าใจ Docker health checks จึงถ่ายโอนไปยังสภาพแวดล้อมแบบ orchestrated ได้โดยตรง

เนื่องจากการปฏิบัติงานที่น่าเชื่อถือต้องการการแยกแยะ "กำลังรัน" ออกจาก "ทำงานได้จริง" และการตอบสนองต่อ container ที่พังแต่ยังรันอยู่ (restart มัน ระงับ traffic) และเนื่องจาก health check คือกลไกที่ทำให้สิ่งนี้เป็นไปได้ — ใช้โดย orchestrator สำหรับ self-healing และการ route traffic — การเข้าใจ Docker health checks จึงเป็นความรู้ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการรัน container อย่างน่าเชื่อถือ เป็นแนวปฏิบัติสำคัญสำหรับความทนทานใน production ที่ป้องกันปัญหาที่พบบ่อยซึ่ง container ที่พังยังคงได้รับ traffic อย่างเงียบ ๆ และเป็นแนวคิดพื้นฐานของวิธีที่ orchestrator รักษาสุขภาพของแอปพลิเคชัน