Docker Swarm: Công cụ điều phối thực dụng cho các dự án vừa và nhỏ

Tại sao Docker Swarm vẫn là lựa chọn hàng đầu cho các đội ngũ nhỏ

Kubernetes là nhà vô địch hạng nặng không thể bàn cãi trong việc điều phối container, nhưng nó thường là “quá mức cần thiết” (overkill). Một control plane K8s cơ bản có thể dễ dàng ngốn 2GB RAM ngay cả trước khi bạn triển khai ứng dụng đầu tiên. Với nhiều dự án, việc quản lý một cluster Kubernetes giống như thuê một thợ máy toàn thời gian chỉ để lái một chiếc xe máy. Đây chính là nơi Docker Swarm tỏa sáng. Nó được tích hợp trực tiếp vào Docker engine, sử dụng cú pháp Compose quen thuộc và chạy mượt mà trên một VPS 1GB rẻ tiền.

Tôi đã quản lý các hệ thống thực tế trên Swarm hơn ba năm với thời gian downtime tối thiểu. Nó cho phép một lập trình viên duy nhất xử lý hàng chục container trên nhiều máy chủ mà không cần một đội DevOps chuyên trách. Nếu bạn có thể viết một file docker-compose.yml, bạn đã nắm giữ 90% kỹ năng cần thiết để vận hành một Swarm cluster.

Khởi đầu nhanh: Thiết lập Cluster trong chưa đầy 5 phút

Để thực hiện theo, hãy chuẩn bị hai máy chủ Linux—ngay cả những gói khởi điểm 5 USD/tháng cũng hoạt động tốt. Hãy đặt tên cho chúng là manager-node và worker-node.

1. Khởi tạo Manager

Đăng nhập vào máy chủ chính của bạn. Chạy lệnh này để nâng cấp nó thành node điều hành (leader) của cluster:

docker swarm init --advertise-addr <IP-CUA-MANAGER>

Docker sẽ tạo ra một lệnh join cụ thể. Nó trông giống như docker swarm join --token <TOKEN> <IP>:2377. Hãy sao chép toàn bộ chuỗi đó.

2. Gia nhập Worker

SSH vào máy chủ thứ hai và dán lệnh bạn vừa sao chép:

docker swarm join --token SWMTKN-1-xyz... 192.168.1.10:2377

3. Xác minh Cluster

Quay lại manager-node và kiểm tra tiến độ của bạn:

docker node ls

Bạn sẽ thấy cả hai node được liệt kê với trạng thái “Ready”. Giờ đây bạn đã có một cluster điều phối đang hoạt động.

Kiến trúc và các khái niệm cốt lõi

Swarm xử lý lưu lượng truy cập và vòng đời container khác với Docker độc lập. Chúng ta ngừng nghĩ về các container riêng lẻ và bắt đầu nghĩ về Services (Dịch vụ) và Stacks.

Managers vs. Workers

Managers là bộ não. Chúng xử lý trạng thái cluster, quản lý chứng chỉ và lập lịch cho các dịch vụ. Workers là cơ bắp; chúng chỉ đơn giản là thực thi các tác vụ được giao. Mặc dù Manager cũng có thể chạy container, nhưng việc tách biệt chúng trong các môi trường lớn hơn sẽ giúp ngăn chặn gánh nặng quản lý làm chậm ứng dụng của bạn.

Routing Mesh

Ingress routing mesh là vũ khí bí mật của Swarm. Khi bạn publish một port, Docker sẽ mở port đó trên mọi node trong cluster. Nếu người dùng truy cập vào Node A, nhưng container thực tế đang chạy trên Node C, mesh sẽ điều hướng lưu lượng một cách minh bạch. Điều này giúp việc cân bằng tải cơ bản trở nên cực kỳ đơn giản để triển khai.

Mạng Overlay

Swarm sử dụng Overlay Networks để cho phép các container trên các máy chủ vật lý khác nhau giao tiếp với nhau một cách an toàn. Nó tạo ra một đường ống ảo riêng tư xuyên suốt các máy chủ của bạn. Bạn không còn cần phải map port giữa các máy chủ một cách thủ công nữa. Thay vào đó, container API của bạn có thể kết nối với container Database chỉ bằng cách sử dụng tên db.

docker network create --driver overlay app-network

Triển khai với Stacks

Việc gõ các lệnh docker service create dài dằng dặc rất dễ dẫn đến sai sót. Trong môi trường production, chúng ta sử dụng Stacks. Một file Stack gần như giống hệt file Docker Compose tiêu chuẩn, nhưng nó bao gồm phần deploy để mở rộng và thiết lập các ràng buộc.

Ví dụ: Ứng dụng Web Nginx có khả năng mở rộng

Lưu file này với tên docker-stack.yml:

version: '3.8'
services:
  web:
    image: nginx:latest
    networks:
      - frontend
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
  
  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    networks:
      - frontend
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  frontend:
    driver: overlay

Triển khai stack chỉ với một lệnh:

docker stack deploy -c docker-stack.yml my-app

Swarm giờ đây đảm bảo ba bản sao (replica) Nginx luôn hoạt động. Nếu một node bị sập, Swarm sẽ phát hiện sự cố và tự động tạo lại các container bị thiếu trên các phần cứng khỏe mạnh còn lại.

Những bài học kinh nghiệm xương máu từ thực tế

Sau nhiều năm sử dụng Swarm, bốn kinh nghiệm sau đây đã giúp tôi tránh khỏi những rắc rối phổ biến nhất.

1. Sử dụng Secret có sẵn

Đừng đưa mật khẩu vào các biến môi trường nơi chúng có thể bị lộ dưới dạng văn bản thuần túy. Hãy sử dụng tính năng Secrets tích hợp sẵn của Swarm. Chúng được mã hóa trong quá trình truyền tải và chỉ được giải mã bên trong bộ nhớ của container tại đường dẫn /run/secrets/.

echo "mat-khau-sieu-bao-mat-123" | docker secret create db_password -

2. Cố định dịch vụ với Placement Constraints

Không phải tất cả các node đều giống nhau. Bạn có thể có một máy chủ với ổ cứng NVMe tốc độ cao dành riêng cho cơ sở dữ liệu. Hãy sử dụng nhãn (label) cho node để đảm bảo cơ sở dữ liệu luôn nằm ở nơi có lưu trữ nhanh nhất.

docker node update --label-add storage=nvme node-01

3. Cài đặt Portainer để dễ dàng quan sát

Swarm thiếu một bảng điều khiển (dashboard) mặc định. Portainer lấp đầy khoảng trống này một cách hoàn hảo. Nó cung cấp một giao diện web trực quan để xem log, khởi động lại dịch vụ và theo dõi việc sử dụng tài nguyên. Đây là một công cụ thiết yếu để xử lý sự cố khi bạn không muốn đào sâu vào CLI.

4. Health Check là bắt buộc

Một container có thể đang ở trạng thái “running” trong khi ứng dụng bên trong đã bị treo hoàn toàn. Luôn định nghĩa một healthcheck. Nếu một container ngừng phản hồi các kiểm tra này, Swarm sẽ hủy nó và khởi tạo một instance mới. Khả năng tự chữa lành (self-healing) này chính là lý do hàng đầu để chúng ta sử dụng công cụ điều phối.

Docker Swarm có thể không có hệ sinh thái khổng lồ như Kubernetes, nhưng nó là quá đủ cho 80% các ứng dụng web. Nó giúp hạ tầng của bạn gọn nhẹ và quy trình triển khai luôn nhanh chóng.