Docker Compose ปี 2026: แอปพลิเคชัน Multi-Container, Networking และคำถามสัมภาษณ์ DevOps

Docker Compose ยังคงเป็นเครื่องมือหลักสำหรับการกำหนดและรันแอปพลิเคชัน Docker แบบ multi-container ในปี 2026 ไม่ว่าจะเป็นการ orchestrate stack development ในเครื่องหรือเตรียมตัวสำหรับการสัมภาษณ์ DevOps การทำความเข้าใจเรื่อง Compose networking, service dependencies และ pattern ในระดับ production เป็นสิ่งที่แยก engineer ระดับ junior ออกจาก practitioner ระดับ senior

ทำความเข้าใจสถาปัตยกรรม Docker Compose

Docker Compose ทำงานบนหลักการง่ายๆ: กำหนด services ของแอปพลิเคชันในไฟล์ compose.yaml (การตั้งชื่อแบบใหม่แทนที่ docker-compose.yml) และ Compose จะจัดการการสร้าง container, networking และการจัดการ lifecycle

Docker Compose specification กำหนดแนวคิดหลักสามประการ:

• Services: การกำหนดค่า container รวมถึง image, build context, environment variables และ resource limits
• Networks: ช่องทางการสื่อสารที่แยกออกมาระหว่าง services
• Volumes: การจัดเก็บข้อมูลแบบ persistent ที่คงอยู่หลังจาก container restart

# compose.yaml
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
    depends_on:
      db:
        condition: service_healthy
    networks:
      - backend

  db:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=app
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - backend

networks:
  backend:
    driver: bridge

volumes:
  postgres_data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

การกำหนดค่านี้แสดงให้เห็น pattern ที่พร้อมสำหรับ production หลายประการ: health checks สำหรับการจัดลำดับ dependency, Docker secrets สำหรับข้อมูลที่ละเอียดอ่อน, named volumes สำหรับ persistence และการกำหนด network อย่างชัดเจน

เจาะลึก Docker Compose Networking

โดยค่าเริ่มต้น Compose จะสร้าง network หนึ่งเดียวสำหรับแอปพลิเคชัน services ทั้งหมดจะเข้าร่วม network นี้และสามารถเข้าถึงกันได้โดยใช้ชื่อ service เป็น hostname การทำความเข้าใจ networking model นี้เป็นพื้นฐานสำหรับการย้ายไป Kubernetes ในภายหลัง

# compose.yaml
services:
  frontend:
    build: ./frontend
    ports:
      - "80:80"
    networks:
      - frontend-net
      - backend-net

  api:
    build: ./api
    networks:
      - backend-net

  cache:
    image: redis:7-alpine
    networks:
      - backend-net

  db:
    image: postgres:16
    networks:
      - backend-net

networks:
  frontend-net:
    driver: bridge
  backend-net:
    driver: bridge
    internal: true

flag internal: true ป้องกันไม่ให้ backend network เข้าถึง internet ภายนอก service frontend เชื่อมต่อทั้งสอง networks ทำหน้าที่เป็นจุดเข้าเพียงจุดเดียว การแบ่ง network นี้สะท้อนแนวปฏิบัติด้านความปลอดภัยใน production

Multi-Stage Builds กับ Compose

image สำหรับ production ควรมีขนาดเล็กที่สุด Multi-stage builds รวมกับ Compose profiles ช่วยให้กำหนดค่าที่แตกต่างกันสำหรับ development และ production ได้

# api/Dockerfile
# Stage 1: Build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:22-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

# Stage 3: Development
FROM node:22-alpine AS development
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
USER node
CMD ["npm", "run", "dev"]

# compose.yaml
services:
  api:
    build:
      context: ./api
      target: ${BUILD_TARGET:-production}
    volumes:
      - ${API_VOLUMES:-./api/dist:/app/dist:ro}
    profiles:
      - ${COMPOSE_PROFILES:-prod}

การรัน BUILD_TARGET=development COMPOSE_PROFILES=dev docker compose up จะเริ่มการกำหนดค่า development พร้อม hot reload

Service Dependencies และ Health Checks

directive depends_on ควบคุมลำดับการ startup แต่การที่ container เริ่มต้นไม่ได้หมายความว่า service พร้อมใช้งาน Health checks แก้ปัญหา timing นี้ เป็น pattern ที่มักถูกถามในการสัมภาษณ์ DevOps

# compose.yaml
services:
  api:
    build: ./api
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
      migrations:
        condition: service_completed_successfully

  migrations:
    build: ./api
    command: npm run migrate
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 10s

  cache:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3

มีเงื่อนไข dependency สามแบบ:

• service_started: ค่าเริ่มต้น container ได้เริ่มต้นแล้ว
• service_healthy: health check ผ่าน
• service_completed_successfully: container ออกด้วย code 0 (สำหรับ init containers)

Docker Compose สำหรับ Development ในเครื่อง

สภาพแวดล้อม development ได้รับประโยชน์จาก bind mounts, environment overrides และ debugging tools ไฟล์ compose.override.yaml จะถูกรวมเข้ากับ compose.yaml โดยอัตโนมัติ

# compose.yaml (การกำหนดค่าพื้นฐาน)
services:
  api:
    build: ./api
    environment:
      - NODE_ENV=production

  db:
    image: postgres:16

# compose.override.yaml (override สำหรับ development)
services:
  api:
    build:
      target: development
    volumes:
      - ./api:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
      - DEBUG=app:*
    ports:
      - "9229:9229"

  db:
    ports:
      - "5432:5432"

Anonymous volume /app/node_modules ป้องกันไม่ให้ node_modules ของ host เขียนทับ dependencies ที่ติดตั้งใน container

Pattern การ Deploy สำหรับ Production

Docker Compose เหมาะสำหรับการ deploy production แบบ single-host สำหรับการ orchestrate แบบ multi-host Kubernetes กับ Helm ให้การ scaling ที่ดีกว่า แต่ Compose ยังคงเป็นทางเลือกที่ดีสำหรับแอปพลิเคชันขนาดเล็ก

# compose.prod.yaml
services:
  api:
    image: registry.example.com/api:${VERSION:-latest}
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - api

key deploy กำหนดค่า resource limits, จำนวน replicas และ restart policies การรัน docker compose -f compose.prod.yaml up -d จะเริ่มต้น stack production ในโหมด detached

Environment Variables และการจัดการ Secrets

การกำหนดค่าที่ละเอียดอ่อนต้องการการจัดการที่เหมาะสม Docker Compose รองรับหลายวิธี ตั้งแต่ไฟล์ .env จนถึง Docker secrets

# .env
POSTGRES_PASSWORD=dev_password_only
API_SECRET_KEY=local_dev_key

# compose.yaml
services:
  api:
    environment:
      - API_SECRET_KEY  # สืบทอดจาก shell หรือ .env
      - DATABASE_URL=postgres://user:${POSTGRES_PASSWORD}@db:5432/app
    env_file:
      - ./config/api.env

สำหรับ production Docker secrets ให้ความปลอดภัยที่ดีกว่าโดยการ mount ข้อมูลที่ละเอียดอ่อนเป็นไฟล์แทนที่จะเป็น environment variables:

# compose.prod.yaml
services:
  api:
    secrets:
      - api_key
      - db_password
    environment:
      - API_KEY_FILE=/run/secrets/api_key

secrets:
  api_key:
    external: true
  db_password:
    file: ./secrets/db_password.txt

คำถามสัมภาษณ์ DevOps ที่พบบ่อยเกี่ยวกับ Docker Compose

ผู้สัมภาษณ์จะทดสอบความเข้าใจเกี่ยวกับแนวคิด Compose ผ่านสถานการณ์จริง คำถามเหล่านี้มักปรากฏในการสัมภาษณ์ DevOps และ platform engineering

ถ: container ใน Compose network สื่อสารกันอย่างไร?

Docker สร้าง dedicated bridge network สำหรับแต่ละ Compose project services สื่อสารโดยใช้ชื่อ service เป็น hostname DNS server ที่ฝังอยู่จะ resolve ชื่อเหล่านี้เป็นที่อยู่ IP ของ container traffic จากภายนอกสามารถเข้าถึง services ได้เฉพาะผ่าน port ที่ publish ไว้อย่างชัดเจนเท่านั้น

ถ: เกิดอะไรขึ้นเมื่อรัน docker compose up กับ container ที่มีอยู่?

Compose เปรียบเทียบการกำหนดค่าปัจจุบันกับ container ที่กำลังทำงาน services ที่ไม่เปลี่ยนแปลงจะทำงานต่อไป services ที่ถูกแก้ไขจะถูกสร้างใหม่ด้วยการตั้งค่าใหม่ services ใหม่จะเริ่มต้นใหม่ services ที่ถูกลบจะถูกหยุดและลบทิ้ง

ถ: จะจัดการ database migrations ใน Compose ได้อย่างไร?

มีสอง pattern แรก ใช้ init container กับ dependency service_completed_successfully:

services:
  migrate:
    image: api:latest
    command: npm run migrate
    depends_on:
      db:
        condition: service_healthy

  api:
    depends_on:
      migrate:
        condition: service_completed_successfully

สอง รวม logic migration ไว้ใน startup script ของแอปพลิเคชัน ตรวจสอบและใช้ migrations ที่รอดำเนินการก่อนรับ traffic

ถ: volumes และ bind mounts แตกต่างกันอย่างไร?

Named volumes ถูกจัดการโดย Docker เก็บไว้ที่ /var/lib/docker/volumes และสามารถพกพาระหว่าง host ได้ Bind mounts map directory ของ host โดยตรงเข้าไปใน container มีประโยชน์สำหรับ development แต่ขึ้นอยู่กับสภาพแวดล้อม Volumes รองรับ drivers สำหรับ remote storage เช่น NFS หรือ cloud block storage

ถ: docker-compose และ docker compose แตกต่างกันอย่างไร?

docker-compose มีขีดกลางเป็น standalone tool V1 ที่ใช้ Python ปัจจุบันเลิกใช้แล้ว docker compose มีช่องว่างเป็น implementation V2 ที่ใช้ Go ซึ่งรวมอยู่ใน Docker CLI V2 เร็วกว่า รองรับ Compose Specification อย่างเต็มที่ และได้รับการพัฒนาอย่างต่อเนื่อง

การ Debug แอปพลิเคชัน Compose

การ troubleshoot แอปพลิเคชันที่ใช้ container ต้องการเทคนิคเฉพาะ คำสั่งเหล่านี้เผยให้เห็นสิ่งที่เกิดขึ้นภายใน stack Compose:

# ดู logs จากทุก services
docker compose logs -f

# Logs จาก service เฉพาะพร้อม timestamps
docker compose logs -f --timestamps api

# รัน command ใน container ที่กำลังทำงาน
docker compose exec api sh

# รัน command ครั้งเดียว (เริ่ม container ใหม่)
docker compose run --rm api npm test

# ดูการใช้ resource
docker compose top
docker stats

# ตรวจสอบการกำหนดค่า network
docker network inspect project_backend

# ตรวจสอบความถูกต้องของ compose file
docker compose config

คำสั่ง docker compose config รวม compose files ทั้งหมดและแสดงการกำหนดค่าสุดท้าย มีประโยชน์มากสำหรับการ debug ปัญหา variable interpolation

สรุป

• Docker Compose กำหนดแอปพลิเคชัน multi-container ในไฟล์ YAML เดียวพร้อม services, networks และ volumes
• Services สื่อสารผ่าน DNS โดยใช้ชื่อ service เป็น hostname ภายใน default bridge network
• Health checks ด้วยเงื่อนไข service_healthy ทำให้มั่นใจในลำดับการ startup ที่ถูกต้อง
• ใช้ compose.override.yaml สำหรับการตั้งค่าเฉพาะ development เช่น bind mounts และ debug ports
• การ deploy production ได้รับประโยชน์จาก resource limits, restart policies และ Docker secrets สำหรับข้อมูลที่ละเอียดอ่อน
• CLI docker compose (V2) แทนที่ docker-compose (V1) ที่เลิกใช้แล้วด้วยประสิทธิภาพและฟีเจอร์ที่ดีกว่า