เมื่อพูดถึง Docker คนส่วนใหญ่มักนึกถึงการสร้างและรัน Container แต่เมื่อระบบเริ่มใหญ่ขึ้น การมี Container เพียงไม่กี่ตัวบนเครื่องเดียวอาจไม่เพียงพอ
ลองจินตนาการว่าระบบหนึ่งมีทั้ง Web Application, API, Database, Redis, Kafka, Worker และ AI Service และแต่ละ Service ต้องทำงานบนหลายเครื่องเพื่อรองรับผู้ใช้งานจำนวนมาก
คำถามคือ
ใครจะเป็นคนจัดการ Container เหล่านี้?
นี่คือจุดที่แนวคิด Container Orchestration เข้ามามีบทบาท และหนึ่งในเครื่องมือที่มากับ Ecosystem ของ Docker ก็คือ Docker Swarm
Docker Swarm คืออะไร?
Docker Swarm คือระบบ Container Orchestration ของ Docker ที่ใช้สำหรับรวม Docker Host หลายเครื่องเข้าด้วยกันเป็น Cluster และบริหาร Container หรือ Service เหล่านั้นจากศูนย์กลาง
แทนที่จะคิดว่า
Server 1
└── Container
Server 2
└── Container
Server 3
└── Container
เราสามารถมองเป็น
Docker Swarm Cluster
│
┌──────────────┼──────────────┐
│ │ │
Node 1 Node 2 Node 3
│ │ │
Containers Containers Containers
ผู้ดูแลระบบสามารถสั่งงานผ่าน Swarm โดยไม่จำเป็นต้องบริหาร Container แต่ละตัวแบบแยกกัน
Docker กับ Docker Swarm ต่างกันอย่างไร?
Docker มีหน้าที่หลักในการสร้างและรัน Container
เช่น
docker run nginx
คำสั่งนี้บอก Docker ให้สร้างและรัน Container จาก Image ของ Nginx
แต่เมื่อมีหลายเครื่อง เช่น
Server 1
Server 2
Server 3
Server 4
Server 5
เราต้องการระบบที่สามารถจัดการ Container ทั้งหมดได้
Docker Swarm จึงเข้ามาทำหน้าที่ในระดับ Cluster
Docker
↓
Container Runtime
↓
Docker Swarm
↓
Cluster Management
↓
Multiple Docker Hosts
Docker Compose กับ Docker Swarm
อีกคำที่มักสับสนคือ Docker Compose
Docker Compose เหมาะกับการจัดการ Application ที่ประกอบด้วยหลาย Container เช่น
Web
API
PostgreSQL
Redis
Worker
ตัวอย่าง:
services:
api:
image: my-api
redis:
image: redis
postgres:
image: postgres
Compose ทำให้เราสามารถกำหนด Application Stack ในไฟล์เดียว
แต่ Compose โดยทั่วไปเหมาะกับการจัดการ Application บน Environment เดียวหรือเครื่องเดียวมากกว่า
ส่วน Swarm สามารถนำแนวคิด Service เหล่านี้ไปกระจายบนหลาย Node ได้
Docker Compose
│
▼
Multi-Container Application
Docker Swarm
│
▼
Multi-Node Container Cluster
สถาปัตยกรรม Docker Swarm
Swarm แบ่ง Node ออกเป็นบทบาทหลัก ๆ ได้แก่ Manager Node และ Worker Node
Swarm Cluster
┌───────────────┐
│ Manager Node │
│ Cluster State │
│ Scheduling │
└───────┬───────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Worker 1 Worker 2 Worker 3
│ │ │
Service Service Service
Container Container Container
Manager ทำหน้าที่บริหาร Cluster และตัดสินใจว่า Service ควรถูกวางบน Node ใด
Worker ทำหน้าที่รัน Task หรือ Container ที่ได้รับมอบหมาย
ใน Production สามารถมี Manager หลายตัวเพื่อเพิ่มความทนทานของระบบ
Service คืออะไร?
ใน Docker ปกติ เรามักคิดในระดับ Container
แต่ใน Swarm เราจะคิดในระดับ Service
ตัวอย่างเช่น
docker service create \
--name web \
--replicas 3 \
nginx
คำสั่งนี้บอก Swarm ว่า
ต้องการ Service ชื่อ web จำนวน 3 replicas
Swarm จะจัดการว่า Container แต่ละตัวควรไปอยู่ Node ใด
web service
│
┌──────────┼──────────┐
▼ ▼ ▼
Replica 1 Replica 2 Replica 3
│ │ │
Node 1 Node 2 Node 3
ถ้า Container ตัวหนึ่งหยุดทำงาน Swarm สามารถสร้าง Task ใหม่เพื่อรักษาจำนวน Replica ตามที่กำหนด
นี่คือแนวคิดสำคัญของ Desired State
Desired State คือหัวใจของ Orchestration
สมมติว่าเรากำหนดว่า
web replicas = 3
ระบบต้องการให้มี Web Service 3 ตัวทำงานอยู่เสมอ
หากเกิดเหตุการณ์
Replica 1 → Running
Replica 2 → Failed
Replica 3 → Running
Swarm จะตรวจพบว่าสถานะปัจจุบันไม่ตรงกับสถานะที่ต้องการ
Desired State = 3
Current State = 2
จากนั้นระบบจะพยายามสร้าง Replica ใหม่
Replica 1 → Running
Replica 2 → Failed
Replica 3 → Running
Replica 4 → New
จนกลับไปสู่
Desired State = 3
นี่คือแนวคิดพื้นฐานเดียวกับระบบ Orchestration สมัยใหม่จำนวนมาก
Scaling
ข้อดีอีกอย่างของ Swarm คือการ Scale Service
จาก
--replicas 3
สามารถเพิ่มเป็น
--replicas 10
ได้
Web Service
│
┌──────────┼──────────┐
▼ ▼ ▼
Node 1 Node 2 Node 3
│ │ │
Web ×3 Web ×3 Web ×4
เหมาะกับ Application ที่ต้องรองรับ Load เพิ่มขึ้น
Load Balancing
Swarm ยังมีระบบ Routing Mesh สำหรับช่วยกระจาย Traffic ไปยัง Service
ตัวอย่าง:
Client
│
▼
Swarm Network
│
┌────────────┼────────────┐
▼ ▼ ▼
Web #1 Web #2 Web #3
ผู้ใช้จึงไม่จำเป็นต้องรู้ว่า Container ตัวใดกำลังให้บริการอยู่
Self-Healing
สมมติว่าระบบกำหนด
API replicas = 5
แล้ว API Container หนึ่งตัวหยุดทำงาน
Swarm จะพยายามรักษา Desired State ให้กลับมาเป็น 5 replicas
แนวคิดคือ
Failure
↓
Detect
↓
Reschedule
↓
Create Replacement
↓
Back to Desired State
นี่เป็นหนึ่งในเหตุผลสำคัญที่ทำให้ Container Orchestration มีประโยชน์ใน Production
Rolling Update
Swarm สามารถอัปเดต Service แบบทยอยเปลี่ยน Container
ตัวอย่าง
Version 1
API × 5
ต้องการเปลี่ยนเป็น
Version 2
API × 5
แทนที่จะหยุดทั้งหมดพร้อมกัน ระบบสามารถทยอย Update
V1 V1 V1 V1 V1
↓
V2 V1 V1 V1 V1
↓
V2 V2 V1 V1 V1
↓
V2 V2 V2 V1 V1
↓
V2 V2 V2 V2 V2
ช่วยลด Downtime และทำให้การ Deploy มีความต่อเนื่องมากขึ้น
Docker Swarm กับ Data Engineering
Swarm สามารถใช้เป็น Infrastructure Layer สำหรับ Data Platform ขนาดเล็กถึงกลางได้
ตัวอย่าง Architecture:
Data Platform
│
Docker Swarm
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Airflow Kafka PostgreSQL
│ │ │
▼ ▼ ▼
ETL Streaming Storage
│
▼
dbt
│
▼
Data Warehouse
Service ที่สามารถนำมาจัดการได้ เช่น
- Airflow
- Kafka
- PostgreSQL
- Redis
- MinIO
- FastAPI
- dbt
- Spark
- Data Processing Workers
อย่างไรก็ตาม Data Platform ขนาดใหญ่จำเป็นต้องพิจารณาความเหมาะสมของแต่ละระบบ โดยเฉพาะ Stateful Workload เช่น Database และ Kafka ซึ่งมีข้อกำหนดด้าน Storage, Replication และ Recovery ที่ละเอียดกว่า Stateless API
Docker Swarm กับ AI Platform
สำหรับ AI Platform ก็สามารถใช้แนวคิดเดียวกันได้
AI Platform
│
Docker Swarm
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
AI API AI Agent RAG
│ │ │
▼ ▼ ▼
Model Server Workflow Vector DB
เช่น
FastAPI
AI Agent
RAG
Embedding Service
Vector Database
Redis
Worker
Monitoring
สามารถแยกเป็น Service และ Scale แต่ละส่วนตามความต้องการ
ตัวอย่างเช่น
AI API × 5
Agent Worker × 10
Embedding × 3
RAG Worker × 5
ทำให้ Architecture มีความยืดหยุ่นมากขึ้น
Docker Swarm กับ Kubernetes
เมื่อพูดถึง Container Orchestration ในปัจจุบัน มักต้องเปรียบเทียบ Swarm กับ Kubernetes
แนวคิดพื้นฐานเหมือนกัน คือ
Container
↓
Service
↓
Orchestration
↓
Cluster
แต่ Kubernetes มี Ecosystem และความสามารถด้าน Orchestration ที่กว้างกว่า โดยเฉพาะระบบ Production ขนาดใหญ่, Cloud Native, Service Discovery, Networking, Operators, Autoscaling และ Ecosystem ของเครื่องมือเสริม
ในขณะที่ Swarm มีแนวคิดที่เรียบง่ายและผูกกับ Docker โดยตรงมากกว่า
ดังนั้นการเลือกไม่ได้มีคำตอบเดียว แต่ควรพิจารณาจากขนาดระบบ ทีมงาน ความซับซ้อน และ Requirement ของ Infrastructure
แล้วควรเรียนอะไร?
ถ้าเริ่มจาก Docker และต้องการเข้าใจ Container Infrastructure ผมแนะนำลำดับ:
Docker
↓
Dockerfile
↓
Docker Compose
↓
Docker Network
↓
Docker Volume
↓
Docker Registry
↓
Docker Swarm
↓
Container Orchestration
↓
Kubernetes
↓
Cloud Native
เมื่อเข้าใจลำดับนี้แล้ว จะเห็นภาพว่า Docker ไม่ได้เป็นเพียงเครื่องมือสำหรับ “รัน Container”
แต่เป็นจุดเริ่มต้นของแนวคิด Containerized Infrastructure
สรุป
Docker Swarm คือระบบ Container Orchestration ของ Docker สำหรับจัดการ Docker Container และ Service บนหลายเครื่องให้ทำงานร่วมกันเป็น Cluster
ภาพรวมสามารถจำได้ง่าย ๆ ว่า
Docker
│
└── Container
Docker Compose
│
└── Multi-Container Application
Docker Swarm
│
└── Multi-Node Container Cluster
Kubernetes
│
└── Advanced Container Orchestration
สำหรับผู้ที่กำลังสร้างระบบ Data Engineering, AI Platform หรือ SaaS Docker Swarm เป็นอีกหนึ่งเทคโนโลยีที่ควรเข้าใจ เพราะช่วยให้เห็นภาพสำคัญของระบบ Distributed Application ตั้งแต่การ Deploy, Scaling, Service Discovery, Load Balancing, Self-Healing ไปจนถึง Rolling Update
และเมื่อพื้นฐานเหล่านี้เข้าใจแล้ว การก้าวไป Kubernetes จะง่ายขึ้นมาก เพราะแนวคิดสำคัญหลายอย่าง เช่น Cluster, Node, Service, Replica, Desired State และ Scheduling จะเริ่มคุ้นเคยตั้งแต่ระดับ Docker Swarm
ความคิดเห็น
แสดงความคิดเห็น