Swarm: Service, Scale và Rolling Update
Ở Bài 10 ta dựng cụm và nói về desired-state. Bài này hiện thực hóa nó: trên Swarm bạn không chạy container lẻ bằng docker run, mà khai báo service — và Swarm lo phần còn lại.
Service và task
Theo tài liệu Docker, "một service là định nghĩa các task để chạy trên các node", và "một task mang một container cùng lệnh chạy bên trong; nó là đơn vị lập lịch nguyên tử của swarm". Quan hệ:
Service "web" (desired: 3 replicas)
│ manager chia thành các task
├── task web.1 ──► container nginx (trên node X)
├── task web.2 ──► container nginx (trên node Y)
└── task web.3 ──► container nginx (trên node Z)
Bạn khai báo service "muốn 3 bản"; manager tạo 3 task; mỗi task chạy một container, có thể nằm trên các node khác nhau. Bạn quản lý ở mức service, không phải từng container.
Có hai chế độ service:
- replicated (mặc định): chạy đúng số bản bạn đặt, manager phân bổ chúng lên các node. Dùng cho phần lớn ứng dụng.
- global: chạy đúng một bản trên mỗi node trong cụm. Hợp cho agent giám sát/log cần có mặt ở mọi máy.
Tạo service
Tạo một service web 3 bản, publish cổng:
docker service create --name webv --replicas 3 -p 9090:80 nginx:alpine
verify: Service converged
"Converged" nghĩa là trạng thái thực tế đã khớp desired state (đủ 3 bản chạy). Xem service:
docker service ls
NAME MODE REPLICAS IMAGE
webv replicated 3/3 nginx:alpine
3/3 = 3 bản mong muốn, 3 bản đang chạy. Xem từng task và nó nằm ở đâu:
docker service ps webv
NAME CURRENT STATE
webv.1 Running
webv.2 Running
webv.3 Running
(Trên cụm nhiều node, cột node sẽ cho thấy task nằm rải trên các máy khác nhau.)
Lưu ý:
docker service ...chỉ chạy trên manager node. Worker không ra lệnh điều phối được (Bài 10). Và service khác vớidocker run:docker pschỉ thấy container trên node hiện tại, còndocker service psthấy task trên toàn cụm.
Scale: tăng giảm số bản
Đổi số replica chỉ bằng một lệnh:
docker service scale webv=5
verify: Service converged
Manager tạo thêm 2 task cho đủ 5, phân lên các node còn chỗ. Giảm xuống thì nó tắt bớt task. Cách khác tương đương:
docker service update --replicas 5 webv
Đây chính là desired-state trong thực tế: bạn nói con số, Swarm tự điều chỉnh.
Tự phục hồi
Vì Swarm luôn giữ thực tế khớp desired state, nếu một task chết (container crash, hoặc cả node hỏng), manager phát hiện "đang thiếu" và tự tạo task mới thay thế trên node khả dụng. Bạn không phải làm gì.
Trên cụm nhiều node, bạn có thể thử: tắt Docker ở một worker, rồi chạy docker service ps webv trên manager — sẽ thấy các task ở node đó chuyển sang Shutdown/Failed và task mới mọc lên ở node khác để bù lại. (Trên cụm một node thì không mô phỏng được vụ này — cần multi-node như gợi ý ở Bài 10.)
Rolling update: đổi phiên bản không gián đoạn
Khi cần cập nhật image (deploy phiên bản mới), Swarm thay từng phần thay vì tắt hết cùng lúc — gọi là rolling update. Nhờ vậy dịch vụ không bị gián đoạn.
docker service update --image nginx:1.27-alpine webv
verify: Service converged
Swarm lần lượt: dừng một task cũ, khởi động một task mới với image mới, đợi nó chạy ổn, rồi mới sang task tiếp theo. Kiểm tra image đã đổi:
docker service inspect webv --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}'
Điều khiển cách update bằng các cờ:
docker service update \
--image nginx:1.27-alpine \
--update-parallelism 2 \ # cập nhật 2 task mỗi lần
--update-delay 10s \ # chờ 10s giữa các đợt
webv
--update-parallelism quyết định bao nhiêu task được thay cùng lúc; --update-delay là khoảng nghỉ giữa các đợt để bản mới kịp ổn định trước khi đụng tới bản tiếp theo.
Rollback khi update hỏng
Nếu phiên bản mới có vấn đề, quay lại bản trước chỉ bằng:
docker service rollback webv
Swarm lưu cấu hình trước đó, nên rollback cũng diễn ra theo kiểu cuốn chiếu. Bạn còn có thể đặt sẵn chính sách tự rollback khi update thất bại bằng --update-failure-action rollback lúc tạo service.
🧹 Dọn dẹp
docker service rm webv
Xóa service sẽ dừng và xóa toàn bộ task/container của nó trên mọi node. (Ta vẫn giữ swarm cho Bài 12–13; phần rời swarm ở cuối Bài 13.)
Tổng kết
Trên Swarm, đơn vị làm việc là service — một khai báo "muốn N bản của image này". Manager chia thành task rải lên các node, và liên tục giữ cho đủ số bản (tự phục hồi). scale đổi số bản; rolling update thay image theo từng đợt nên không gián đoạn; rollback quay lại bản trước. Tất cả đều là desired-state: bạn khai báo, Swarm hội tụ về đó.
Service đã chạy nhiều bản trên nhiều node, nhưng chúng nói chuyện với nhau qua mạng nào, và làm sao một cổng publish lại tới được bản đang nằm ở node khác? Bài 12 trả lời: overlay network và routing mesh.