Danh Sách Kiểm Tra Triển Khai Không Gián Đoạn với Docker & Nginx

Tại Sao Triển Khai Không Gián Đoạn Là Quan Trọng

Mỗi phút dừng hoạt động đều dẫn đến doanh thu bị mất, người dùng thất vọng và uy tín thương hiệu bị tổn hại. Trong các môi trường SaaS có lưu lượng truy cập cao, ngay cả một sự cố ngắn cũng có thể dẫn đến một làn sóng yêu cầu hỗ trợ và khách hàng rời bỏ. Một chiến lược triển khai không gián đoạn được tổ chức tốt cho phép bạn đưa ra các tính năng mới, bản vá bảo mật hoặc điều chỉnh cấu hình mà không cần tắt dịch vụ.

Các Yêu Cầu Đầu Vào

Trước khi bạn bắt đầu kiểm tra danh sách, hãy đảm bảo bạn đã có các thành phần sau:

• Docker Engine (≥ 20.10) được cài đặt trên tất cả các máy chủ.
• Nginx hoạt động như một reverse-proxy và load-balancer.
• Một nền tảng CI/CD (GitHub Actions, GitLab CI hoặc tương tự) có quyền để đẩy hình ảnh vào registry của bạn.
• Một stack giám sát (Prometheus + Grafana, Loki, hoặc một giải pháp SaaS khác) có thể cảnh báo khi có lỗi kiểm tra sức khỏe.
• Quyền truy cập SSH hoặc một công cụ quản lý cấu hình (Ansible, Terraform) để cung cấp cơ sở hạ tầng.

Nếu thiếu bất kỳ thành phần nào trong số này, bạn sẽ gặp khó khăn trong quá trình triển khai.

Danh Sách Kiểm Tra

Dưới đây là danh sách kiểm tra thực tiễn, từng bước mà bạn có thể sao chép vào một tệp Markdown, trang Confluence hoặc sổ tay nội bộ của bạn. Xem mỗi mục hàng đầu như một điều cần làm trước khi bạn nhấn nút "Triển Khai".

1️⃣ Chuẩn Bị Hình Ảnh Docker Không Thay Đổi

• Dựa trên một hệ điều hành tối thiểu (ví dụ: alpine hoặc distroless) để giảm bề mặt tấn công và thời gian khởi động.
• Ghi rõ tất cả các phụ thuộc trong Dockerfile của bạn.
• Chạy một build đa giai đoạn để giữ cho hình ảnh cuối cùng gọn nhẹ.
• Gán nhãn hình ảnh với cả phiên bản ngữ nghĩa và git SHA để dễ dàng theo dõi.

# Dockerfile – ứng dụng Node.js đa giai đoạn
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci && npm run build

FROM node:18-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/index.js"]

2️⃣ Cấu Hình Nginx Cho Định Tuyến Blue-Green

• Định nghĩa hai khối upstream (upstream blue và upstream green).
• Tiết lộ một điểm kiểm tra sức khỏe (/healthz) trên mỗi container.
• Sử dụng chỉ thị proxy_next_upstream để tự động chuyển tiếp nếu một backend không khỏe.
• Giữ cho cấu hình không thay đổi để bạn có thể tải lại mà không làm gián đoạn kết nối.

# /etc/nginx/conf.d/app.conf
upstream blue {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
}
upstream green {
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    location / {
        proxy_pass http://$upstream; # $upstream được đặt bởi biến
    }
    location /healthz {
        proxy_pass http://$upstream/healthz;
    }
}

3️⃣ Tự Động Hóa Pipeline CI/CD

• Xây dựng, kiểm tra và đẩy hình ảnh trong một công việc duy nhất.
• Lưu trữ nhãn hình ảnh như một artifact cho các công việc tiếp theo.
• Kích hoạt một công việc triển khai cập nhật biến upstream của Nginx.
• Thêm một bước phê duyệt thủ công cho các bản phát hành sản xuất (tùy chọn nhưng được khuyến nghị).

# .github/workflows/deploy.yml (GitHub Actions)
name: Deploy
on:
  push:
    tags:
      - 'v*.*.*'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Thiết lập Docker Buildx
        uses: docker/setup-buildx-action@v2
      - name: Đăng nhập vào Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASS }}
      - name: Xây dựng & đẩy hình ảnh
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: myregistry.com/app:${{ github.ref_name }},myregistry.com/app:${{ github.sha }}
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: SSH vào máy chủ và tải lại Nginx
        run: |
          ssh -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} \
            "docker pull myregistry.com/app:${{ github.sha }} && \
             docker tag myregistry.com/app:${{ github.sha }} myapp:latest && \
             docker service update --image myapp:latest myservice && \
             sudo nginx -s reload"

4️⃣ Thực Hiện Chuyển Đổi Blue-Green

1. Triển khai phiên bản mới vào môi trường nhàn rỗi (ví dụ: green).
2. Chạy các kiểm tra sức khỏe chống lại green bằng cách sử dụng vòng lặp curl hoặc một probe giám sát.
3. Nếu tất cả các kiểm tra đều thành công, cập nhật biến $upstream trong Nginx để trỏ đến green.
4. Từ từ ngắt kết nối môi trường cũ (blue) bằng cách đặt max_fails=1 và chờ cho các kết nối hiện tại hoàn tất.
5. Đánh dấu môi trường cũ là nhàn rỗi và lặp lại chu trình trong bản phát hành tiếp theo.

# Vòng lặp kiểm tra sức khỏe đơn giản (chạy từ CI hoặc một máy chủ trung gian)
for i in {1..10}; do
  if curl -sSf http://10.0.1.11:8080/healthz; then
    echo "✅ Green là khỏe"
    break
  else
    echo "⏳ Đang chờ green…"
    sleep 5
  fi
done

5️⃣ Quan Sát, Ghi Nhận Và Cảnh Báo

• Bật ghi chép truy cập trong Nginx (log_format json cho dữ liệu có cấu trúc).
• Chuyển giao nhật ký đến Loki hoặc CloudWatch bằng một container bên cạnh.
• Thiết lập ứng dụng của bạn với các chỉ số Prometheus (process_start_time_seconds, độ trễ yêu cầu, tỷ lệ lỗi).
• Tạo cảnh báo cho:
  • Các kiểm tra sức khỏe thất bại > 2 lần liên tiếp.
  • Tăng đột biến đột ngột trong phản hồi 5xx sau khi chuyển đổi.
  • Các ngưỡng CPU hoặc bộ nhớ trên các container mới.

6️⃣ Kế Hoạch Rollback

Ngay cả với danh sách kiểm tra, mọi thứ có thể diễn ra không như mong đợi. Giữ một quy trình rollback ngắn gọn:

• Nếu các kiểm tra sức khỏe thất bại, quay lại $upstream về môi trường trước đó.
• Rollback hình ảnh Docker bằng cách triển khai nhãn đã biết cuối cùng.
• Thông báo cho đội ngũ trực qua Slack hoặc PagerDuty.
• Tài liệu sự cố trong mẫu hậu kỳ.

Kiểm Tra Sau Khi Triển Khai

Sau khi chuyển đổi, thực hiện một bài kiểm tra nhanh:

1. Kiểm tra khói một vài điểm API quan trọng.
2. Xác minh tính duy trì phiên (nếu bạn sử dụng phiên dính, đảm bảo các pod mới chia sẻ cùng một kho lưu trữ phiên).
3. Kiểm tra việc hủy bộ nhớ cache CDN nếu các tài sản tĩnh đã được cập nhật.
4. Xác nhận bảng điều khiển giám sát hiển thị các mẫu lưu lượng truy cập mong đợi.

Tóm Tắt Danh Sách Kiểm Tra

• ✅ Hình ảnh Docker không thay đổi với nhãn ngữ nghĩa
• ✅ Nginx được cấu hình cho upstream blue-green
• ✅ Pipeline CI/CD xây dựng, đẩy và tải lại
• ✅ Vòng lặp kiểm tra sức khỏe trước khi chuyển đổi lưu lượng
• ✅ Stack quan sát sẵn sàng cho cảnh báo
• ✅ Các bước rollback đã được tài liệu hóa

Bằng cách xem mỗi mục như một cánh cổng thay vì một suy nghĩ sau, bạn có thể đạt được những bản phát hành thực sự không gián đoạn, ngay cả dưới tải nặng.

Nếu bạn cần giúp đỡ trong việc triển khai này, đội ngũ tại https://ramerlabs.com có thể hỗ trợ bạn.