Lifecycle และการ Scale

คำสั่ง lifecycle หลัก

เมื่อมี compose.yaml แล้ว คำสั่งหกตัวนี้ครอบคลุมการทำงานประจำวัน

docker compose up

สตาร์ท service ทั้งหมดที่กำหนดใน compose.yaml กด Ctrl-C เพื่อหยุด

docker compose up

สตาร์ทในพื้นหลัง (detached mode):

docker compose up -d

Rebuild images ก่อนสตาร์ท (มีประโยชน์หลังเปลี่ยน Dockerfile):

docker compose up -d --build

docker compose down

หยุดและลบ containers และ default network Named volumes ถูกเก็บไว้

docker compose down

ลบ named volumes ด้วย:

docker compose down -v

docker compose logs

Stream logs จากทุก service:

docker compose logs -f

Stream logs จาก service เฉพาะ:

docker compose logs -f app

docker compose ps

แสดง containers ที่กำลังรันสำหรับโปรเจกต์ปัจจุบัน:

docker compose ps

docker compose build

Build หรือ rebuild images สำหรับ service ที่ใช้ build::

docker compose build

Build service เฉพาะ:

docker compose build app

docker compose exec

รันคำสั่งภายใน service container ที่กำลังรัน:

docker compose exec app sh

การ scale service

รัน replicas หลายตัวของ stateless service ด้วย --scale:

docker compose up -d --scale worker=3

นี่สตาร์ทสาม container สำหรับ service worker แต่ละ replica ได้ชื่อเฉพาะเช่น project-worker-1, project-worker-2, project-worker-3

ข้อจำกัดสำคัญของ service ที่ scale:

อย่าใช้ container_name: แบบตายตัว — Compose ไม่สามารถตั้งชื่อเดียวกันให้สาม container
อย่าใช้ host-port mappings บน service ที่ scale — ไม่สามารถ bind host port เดิมกับสาม container

นิยาม service ที่ scale ได้:

services:
  worker:
    image: myapp:latest
    # ไม่มี container_name — Compose ตั้งชื่อ replicas อัตโนมัติ
    # ไม่มี ports — ไม่ bind host-port บนเซอร์วิสที่ scale
    environment:
      - QUEUE_URL=amqp://rabbit

เข้าใจ down กับ down -v

docker compose down        หยุด containers + ลบ containers + ลบ networks
docker compose down -v     เหมือนด้านบน + ลบ named volumes

Named volumes เก็บข้อมูลฐานข้อมูล ไฟล์ที่อัปโหลด และ caches ส่ง -v เฉพาะเมื่อต้องการล้างข้อมูลนั้นจริงๆ — เช่น เมื่อ reset ฐานข้อมูล development ให้เริ่มต้นใหม่

Lifecycle ครบวงจรในทางปฏิบัติ

# Build images
docker compose build

# สตาร์ททุกอย่างแบบ detached
docker compose up -d

# ดู logs
docker compose logs -f

# ตรวจสอบสถานะ
docker compose ps

# Scale worker ขึ้น
docker compose up -d --scale worker=3

# ปิด (เก็บ volumes)
docker compose down

# Reset เต็มรูปแบบ — ทำลาย volumes ด้วย
docker compose down -v

ลองปฏิบัติจริง

# Create a compose.yaml with a scalable worker
cat > compose.yaml <<'EOF'
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"

  worker:
    image: alpine
    command: >
      sh -c "echo Worker $HOSTNAME started && sleep 20"
EOF

# Start in detached mode
docker compose up -d

# Show running containers
docker compose ps

# Scale workers to 3
docker compose up -d --scale worker=3

# Show all containers (1 web + 3 workers)
docker compose ps

# Stream logs from all workers
docker compose logs worker

# Tear down (containers + network, volumes kept)
docker compose down

echo "All containers removed. Named volumes (if any) are still intact."

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
`docker compose --scale`	scale service แนวนอนได้เร็ว ทดสอบ load บนเครื่อง dev เดียวได้ทันที	จำกัดที่ host เดียว ไม่มี auto-scaling หรือ self-healing ข้าม node
Kubernetes Deployment/HPA	scale ข้ามหลาย node อัตโนมัติตาม load พร้อม self-healing	ต้องตั้ง cluster, controller และเรียนรู้ operational model ที่ซับซ้อนกว่ามาก

ข้อผิดพลาดที่พบบ่อย

ใช้ depends_on: - db แล้วคิดว่า Compose รอจนกว่า database จะพร้อมรับ connection จริง ทั้งที่แค่รอให้ container สตาร์ทเท่านั้น — ต้องเพิ่ม healthcheck และ condition: service_healthy ถ้าต้องการรอความพร้อมจริง
รัน docker compose up -d --scale db=3 กับ service ที่เป็น stateful เช่นฐานข้อมูล ทั้งที่ image นั้นไม่ได้ออกแบบมาให้รันหลาย instance พร้อมกัน (data corruption หรือ port conflict ตามมา)
ลืมว่า docker compose down -v ลบ named volumes แบบไม่มี undo แล้วรันโดยไม่ตรวจสอบก่อนว่าเป็น environment ไหน

💡 ตัวอย่างจากของจริง

ทีม platform จำนวนมากใช้ docker compose up -d --scale worker=N เพื่อทดสอบ behavior การ scale ของ stateless worker บนเครื่อง dev ก่อน แล้วค่อยย้าย pattern เดียวกันไปเป็น Kubernetes replicas และ HorizontalPodAutoscaler ใน production ที่ต้อง scale ข้ามหลายเครื่องจริง