Danh sách kiểm tra triển khai không gián đoạn với Docker và Nginx

Giới thiệu

Triển khai không gián đoạn đã trở thành một yêu cầu thiết yếu trong các dịch vụ hiện đại. Nếu bạn là một trưởng nhóm DevOps, có lẽ bạn đã chứng kiến sự hoảng loạn khi một bản phát hành mới làm cho API ngừng hoạt động trong vài giây. Tin tốt là gì? Với Docker và Nginx, bạn có thể tổ chức các bản phát hành một cách suôn sẻ, giữ cho lưu lượng truy cập không bị gián đoạn, người dùng hài lòng và các SLA vẫn được duy trì. Danh sách kiểm tra này sẽ hướng dẫn bạn qua các bước cụ thể để biến một "triển khai" thành một "chuyển giao liền mạch".

Các yêu cầu cần có

Trước khi bắt đầu kiểm tra từng mục, hãy đảm bảo bạn đã có những điều sau:

• Docker Engine 20.10+ trên tất cả các máy chủ.
• Docker Compose (hoặc một bộ điều phối Swarm/Kubernetes) để phối hợp nhiều dịch vụ.
• Nginx 1.21+ hoạt động như một reverse proxy phía trước các container của bạn.
• Một bộ CI xây dựng các hình ảnh không thay đổi và đẩy chúng lên một registry.
• Truy cập vào giám sát (Prometheus, Grafana) và ghi log (ELK, Loki).

Nếu bất kỳ điều gì trong số này còn thiếu, hãy dành thời gian để thiết lập trước – danh sách kiểm tra này giả định rằng chúng đã tồn tại.

Tổng quan danh sách kiểm tra

Dưới mỗi mục là một hướng dẫn ngắn mà bạn có thể sao chép-dán vào quy trình làm việc của mình.

1. Xây dựng các hình ảnh Docker không thay đổi, có tag phiên bản

Không bao giờ phụ thuộc vào latest. Gán tag cho mỗi bản xây dựng bằng Git SHA hoặc phiên bản ngữ nghĩa.

# Dockerfile
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

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

Xây dựng và đẩy:

VERSION=$(git rev-parse --short HEAD)
docker build -t registry.myco.com/webapp:$VERSION .
docker push registry.myco.com/webapp:$VERSION

Tag không thay đổi đảm bảo bạn có thể quay lại bằng cách tái triển khai cùng một hình ảnh.

2. Lưu trữ hình ảnh trong một registry cá nhân, không thay đổi

Cấu hình CI của bạn để xác thực với registry bằng cách sử dụng các token ngắn hạn. Ví dụ cho GitHub Actions:

- name: Đăng nhập vào Docker registry
  uses: docker/login-action@v2
  with:
    registry: registry.myco.com
    username: ${{ secrets.REGISTRY_USER }}
    password: ${{ secrets.REGISTRY_TOKEN }}

3. Định nghĩa các điểm kiểm tra sức khỏe

Các kiểm tra sức khỏe tích hợp sẵn trong Docker cho phép bộ điều phối biết khi nào một container đã sẵn sàng.

services:
  web:
    image: registry.myco.com/webapp:${VERSION}
    ports:
      - "3000:3000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
      timeout: 3s
      retries: 3

Phơi bày /health để trả về 200 chỉ khi ứng dụng có thể phục vụ lưu lượng truy cập và các kết nối DB của nó đang khỏe mạnh.

4. Sử dụng chiến lược cập nhật cuốn chiếu

Nếu bạn đang sử dụng Docker Swarm, khối update_config điều khiển kích thước lô và độ trễ.

services:
  web:
    deploy:
      replicas: 4
      update_config:
        parallelism: 1        # một container tại một thời điểm
        delay: 10s            # cho nó thời gian để vượt qua kiểm tra sức khỏe
        order: start-first    # bắt đầu mới, sau đó dừng cũ

Người dùng Kubernetes có thể đạt được điều tương tự với strategy.rollingUpdate.maxSurge và maxUnavailable.

5. Cấu hình Nginx cho định tuyến xanh-lục

Chạy hai nhóm upstream – green (hiện tại) và blue (mới). Chuyển đổi lưu lượng truy cập bằng cách thay đổi mục tiêu của proxy_pass.

upstream green {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

upstream blue {
    server 10.0.0.21:3000;
    server 10.0.0.22:3000;
}

server {
    listen 80;
    location / {
        # Ban đầu trỏ đến green
        proxy_pass http://green;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Khi các container mới vượt qua các kiểm tra sức khỏe, hãy chỉnh sửa dòng proxy_pass thành http://blue; và tải lại Nginx:

nginx -s reload

Vì Nginx chỉ chuyển đổi upstream sau khi tải lại cấu hình, sự thay đổi là nguyên tử từ quan điểm của khách hàng.

6. Xác thực các kiểm tra sức khỏe của Nginx trước khi chuyển đổi

Thêm một kiểm tra sức khỏe thụ động trong Nginx để tránh gửi lưu lượng truy cập đến một pod đang thất bại.

upstream blue {
    server 10.0.0.21:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.22:3000 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

Bạn cũng có thể sử dụng ngx_http_healthcheck_module (thương mại) để kiểm tra chủ động, nhưng cách tiếp cận thụ động hoạt động tốt cho hầu hết các khối lượng công việc SaaS.

7. Chạy các di chuyển cơ sở dữ liệu không gián đoạn riêng biệt

Không bao giờ kết hợp các thay đổi schema với việc phát hành ứng dụng. Sử dụng một công cụ như Flyway hoặc Prisma migrate để thực hiện các di chuyển theo cách tương thích với phía trước.

# Ví dụ với Prisma
npx prisma migrate deploy --preview-feature

Nếu một di chuyển cần một back-fill, hãy chạy nó trong một worker nền đọc từ một hàng đợi, đảm bảo API vẫn phản hồi.

8. Thiết lập các cảnh báo quan sát

Tạo các cảnh báo kích hoạt khi:

• Độ trễ phản hồi > 200 ms trong hơn 2 phút.
• Tỷ lệ lỗi > 1% trên upstream mới.
• Số lần khởi động lại container > 1 mỗi phút.

Trong Prometheus:

- alert: HighLatency
  expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="web"}[5m])) by (le)) > 0.2
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "Độ trễ phần trăm 95 cao"

Có những cảnh báo này cho phép bạn hủy bỏ một bản phát hành trước khi người dùng nhận thấy vấn đề.

9. Chuẩn bị một kế hoạch quay lại tự động

Nếu bất kỳ cảnh báo nào được kích hoạt, hãy kích hoạt một kế hoạch quay lại qua công cụ CI/CD của bạn. Đối với Docker Swarm, bạn có thể quay lại tag hình ảnh trước:

docker service update \
  --image registry.myco.com/webapp:${PREV_VERSION} \
  --rollback-delay 5s \
  web_service

Giữ tag trước đó được lưu trữ trong một biến (ví dụ, PREV_VERSION) như một phần của kịch bản triển khai.

10. Dọn dẹp các hình ảnh và container cũ

Sau một lần triển khai thành công, hãy loại bỏ các hình ảnh cũ để giải phóng không gian và giảm bề mặt tấn công.

# Xóa các hình ảnh không còn sử dụng
docker image prune -f
# Xóa các hình ảnh cũ hơn 30 ngày
docker images --filter "until=720h" -q | xargs -r docker rmi -f

Cũng hãy đình chỉ các máy chủ upstream cũ trong Nginx và cập nhật tệp inventory được sử dụng bởi lớp điều phối của bạn.

Kết luận

Triển khai không gián đoạn không phải là phép thuật; chúng là kết quả của việc quản lý phiên bản có kỷ luật, định tuyến theo sức khỏe và các vòng phản hồi dựa trên quan sát. Bằng cách làm theo danh sách kiểm tra này, bạn có thể giao hàng các tính năng vài lần một ngày mà không bao giờ làm gãy trải nghiệm của người dùng. Nếu bạn cần giúp đỡ trong việc triển khai này, đội ngũ tại RamerLabs có thể hỗ trợ bạn.