Bài 8.1. Hướng dẫn tổ chức folder cấu hình Nginx khi có nhiều website và web application theo nhóm

1. Vấn đề thực tế khi số lượng website tăng lớn

Trong các hệ thống nhỏ, việc đặt toàn bộ file cấu hình website vào thư mục mặc định:

là hoàn toàn chấp nhận được. Tuy nhiên, khi hệ thống phát triển lên quy mô:

• Hàng trăm website chuyên ngành,

• Hàng trăm website cơ sở y tế,

• Hàng trăm web application phục vụ điều hành và quản trị,

cách tổ chức “tất cả trong một thư mục” sẽ nhanh chóng bộc lộ các vấn đề nghiêm trọng:

• Khó tìm kiếm và quản lý file cấu hình.

• Dễ chỉnh nhầm website khác khi thao tác.

• Không thể phân nhóm theo chức năng hoặc loại hình hệ thống.

• Việc audit, bàn giao, hoặc xử lý sự cố trở nên phức tạp.

• Rủi ro cao khi reload hoặc chỉnh sửa hàng loạt.

Vì vậy, việc tổ chức lại cấu trúc thư mục cấu hình Nginx là bắt buộc, không phải là tối ưu “có thì tốt”.

2. Nguyên tắc thiết kế cấu trúc folder cấu hình

Trước khi đi vào cấu trúc cụ thể, cần thống nhất các nguyên tắc sau:

1. Phân nhóm theo bản chất hệ thống, không chỉ theo domain.

2. Tách rõ website và web application (vì yêu cầu cấu hình rất khác nhau).

3. Không phá vỡ cơ chế chuẩn của Nginx (vẫn dùng sites-enabled để bật/tắt).

4. Cấu hình phải dễ đọc – dễ mở rộng – dễ rollback.

5. Không phụ thuộc vào tool bên ngoài (Ansible, Docker…) ở giai đoạn này.

3. Cấu trúc thư mục đề xuất cho hệ thống quy mô lớn

3.1. Cấu trúc tổng thể

Thay vì đặt toàn bộ file trực tiếp trong sites-available, ta tổ chức theo các thư mục con đại diện cho từng nhóm hệ thống:

Lưu ý:
sites-enabled không chứa thư mục, chỉ chứa symlink đến các file cần kích hoạt.

3.2. Nhóm Website cơ sở y tế (yte-co-so)

Dùng cho:

• Website bệnh viện,

• Trung tâm y tế,

• Phòng khám,

• Trạm y tế,

• Các đơn vị y tế tuyến dưới.

Ví dụ:

Đặc điểm cấu hình:

• Chủ yếu là website giới thiệu + CMS.

• Backend tương đối giống nhau.

• Ít cấu hình đặc thù (WebSocket, API phức tạp).

3.3. Nhóm Website chuyên ngành (chuyen-nganh)

Dùng cho:

• Website chuyên môn y tế,

• Website nghiệp vụ,

• Website truyền thông chuyên ngành.

Ví dụ:

Đặc điểm cấu hình:

• Có thể có API nội bộ.

• Có upload file, report.

• Yêu cầu timeout cao hơn website thông thường.

3.4. Nhóm Web Application (webapp)

Đây là nhóm quan trọng nhất, cần tách riêng rõ ràng.

Dùng cho:

• QLCL, KHTH, Nhân sự,

• Thiết bị y tế,

• Hạ tầng,

• Dashboard, API, hệ thống điều hành.

Ví dụ:

Đặc điểm cấu hình:

• Timeout dài.

• Upload lớn.

• Có thể dùng WebSocket.

• Reverse proxy tới backend nội bộ (10.10.10.x).

3.5. Nhóm backend / website ngoài Internet (external)

Dùng khi:

• Proxy đến server đặt ngoài hệ thống nội bộ.

• Proxy cho dịch vụ bên thứ ba.

Ví dụ:

3.6. Nhóm bảo trì / fallback (maintenance)

Dùng cho:

• Trang bảo trì toàn hệ thống.

• Trang thông báo khi QMS lỗi.

Ví dụ:

4. Cách kích hoạt website đúng chuẩn Nginx

Nguyên tắc:

• Chỉ symlink file cần dùng vào sites-enabled.

• Không symlink cả thư mục.

Ví dụ:

Kiểm tra trước khi reload:

5. Quy ước đặt tên file cấu hình

Để tránh nhầm lẫn khi số lượng lớn, khuyến nghị:

• Website:

  <domain>.conf

• Web application:

  <ten-he-thong>-app.conf

• Backend ngoài:

  <doi-tac>-external.conf

Ví dụ:

• qlcl-app.conf

• benhvienabc.conf

6. Lợi ích của cách tổ chức này trong vận hành thực tế

Cấu trúc theo nhóm mang lại các lợi ích rõ ràng:

• Dễ tìm – dễ quản lý – dễ bàn giao.

• Giảm rủi ro chỉnh nhầm cấu hình.

• Dễ audit theo từng nhóm hệ thống.

• Dễ cô lập sự cố (biết lỗi thuộc nhóm nào).

• Phù hợp cho hệ thống vận hành lâu dài, hàng trăm website.

7. Lưu ý quan trọng

• Không đặt logic phức tạp trong nginx.conf, chỉ include.

• Mỗi file .conf chỉ nên phục vụ một website hoặc một web app.

• Dùng snippets/ cho các cấu hình dùng chung (SSL, headers, proxy params).

Kết luận:
Với hệ thống quy mô lớn, tổ chức cấu trúc folder cấu hình Nginx là yêu cầu bắt buộc, không phải tùy chọn. Cách làm này giúp hệ thống ổn định – dễ vận hành – dễ mở rộng, phù hợp môi trường sản xuất lâu dài như bệnh viện và các hệ thống quản trị chuyên ngành.