Bài 11.3. Chuẩn hóa backend thành snippet dùng chung

1. Vấn đề với cách hiện tại

Hiện tại mỗi site có:

location / {
   proxy_pass http://10.10.10.66;  # QMS primary
}

Vấn đề:

• Backend IP bị hard-code trong hàng trăm file.

• Khi QMS lỗi:

  • Phải sửa nhiều file, hoặc

  • Phải search/replace dễ sai sót.

• Không đúng tinh thần “điểm chuyển mạch duy nhất”.

2. Chiến lược để chuyển backend chỉ bằng 1 thao tác

Phần này chỉ nói về proxy. Để chuẩn bị server backup realtime cho server chính nói ở phần khác,

Có 2 chiến lược, anh em có thể chọn theo phong cách vận hành.

2.1. Chiến lược A (khuyến nghị): các file “server backend”

Tạo các file đại diện backend - mỗi nhóm website sử dụng 1 file. Khi server phục vụ các nhóm website đó off --> đổi IP sang server backup tương ứng.

Do mình chỉ có 2 website backup nhau nên chỉ cần 1 file active.

Mình cũng dùng chiến lược này trong giai đoạn đầu để trực quan và hiểu hệ thống

2.1.1. Tạo file backend

File:
/etc/nginx/snippets/backend/backend-active.conf

# Primary backend: QMS
#proxy_pass http://10.10.10.66;
# Primary backend: AI
proxy_pass http://10.10.10.88;

2.1.2. Mọi site chỉ include file này

location / {
   include snippets/backend/backend-active.conf;
}

2.1.3. Khi cần chuyển sang QMS

Chỉ sửa 1 file /etc/nginx/snippets/backend/backend-active.conf

# Primary backend: QMS
proxy_pass http://10.10.10.66;
# Primary backend: AI
#proxy_pass http://10.10.10.88;

Sau đó:

👉 Không cần sửa bất kỳ site nào.

2.2. Chiến lược B: symlink backend (ít sửa file hơn)

Chiến lược này có lợi nếu dùng script tự động. Sau này sẽ dùng.

2.2.1. File backend cố định

Mỗi server có 1 file

# Server QMS
proxy_pass http://10.10.10.66;

# Server AI
proxy_pass http://10.10.10.88;

Khi chuyển sang AI:

Ưu điểm:

• Không cần sửa nội dung file.

• Chuyển backend cực nhanh.

3. Chuẩn hóa cách include backend trong site config

Thay thế trong mọi template

Thay vì:

Dùng:

4. Áp dụng vào template chuẩn (ví dụ Web App)

server {
   listen 443 ssl http2;
   server_name qlcl.example.com;
   ssl_certificate     /etc/letsencrypt/live/qlcl.example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/qlcl.example.com/privkey.pem;
   include snippets/ssl/ssl-common.conf;
   include snippets/ssl/ssl-params.conf;
   include snippets/headers/security-headers.conf;
   include snippets/proxy/proxy-common.conf;
   include snippets/proxy/proxy-webapp.conf;
   location / {
       include snippets/backend/backend-active.conf;
   }
}

5. Vì sao cách này phù hợp với hệ thống hiện tại

• Failover nhanh, ít rủi ro (1 file – 1 reload).

• Không cần HAProxy, Keepalived, VRRP.

• Phù hợp giai đoạn:

  • QMS là primary,

  • AI là standby,

  • Failover thủ công khi cần.

• Dễ nâng cấp sau này:

  • Có thể thay proxy_pass bằng upstream mà không sửa site.

6. Nâng cấp trong tương lai (không bắt buộc)

Sau này, nếu muốn:

• Load balancing

• Health check

• Active–active

Chỉ cần thay nội dung backend-active.conf thành:

và định nghĩa upstream backend_cluster ở nơi khác — toàn bộ site không phải sửa lại.

Kết luận (điểm mấu chốt)

Backend phải được xem là “biến cấu hình toàn cục”, không phải chi tiết của từng site.

Việc đưa proxy_pass vào snippet backend là quyết định kiến trúc đúng, giúp hệ thống:

• Dễ vận hành,

• Dễ chuyển đổi,

• Ít rủi ro khi sự cố xảy ra.