oviro – Blog Hoc Tap

Cải tiến việc cấu hình các path prefix đang hard code trong file config của stack (yml), sử dụng File Provider để tiện mở rộng path khi phát triển, thay vì phải update trực tiếp các stack yml và phải update label của các server (hoặc phải update cả stack).

Bên dưới là kết quả trao đổi, đánh giá của việc trước khi migrate và các bước migrate cần thiết để đảm bảo an toàn cho hệ thống OVIRO.VN cài đặt trên server của khách hàng, sử dụng Docker swarm và môi trường On-premise.

1. Bối cảnh hiện tại

Hệ thống đang sử dụng Traefik + Docker Swarm, trong đó:

Routing được khai báo trực tiếp trong deploy.labels của từng service
Các PathPrefix ngày càng nhiều, dài và khó quản lý
Mỗi lần thêm/sửa route:
- Phải sửa file stack
- Phải redeploy service
- Dễ nhầm lẫn, khó review, khó audit

Vấn đề không nằm ở Traefik, mà ở việc routing logic đang bị trộn lẫn với deployment spec.

2. Mục tiêu cải tiến

Đề xuất này nhằm đạt các mục tiêu sau:

✅ Không thay đổi API path, controller, hay business logic
✅ Không thêm gateway, không thêm service
✅ Không can thiệp sâu vào Traefik core config
✅ Giảm độ phức tạp khi quản lý routing
✅ Cho phép chỉnh route mà không cần redeploy stack
✅ Phù hợp Docker Swarm, không ảnh hưởng performance

3. Nguyên tắc kỹ thuật được thống nhất

3.1. Về Traefik Router

Một router là một object nguyên khối
Không thể chia:
- rule ở provider này
- entrypoint / tls / service ở provider khác
Vì vậy:Nếu tách routing ra file → phải migrate toàn bộ router

3.2. Vì sao file provider cần `service`?

Trong Docker labels:
- Traefik tự suy ra service backend
Trong file provider:
- Không có ngữ cảnh Docker
- Router bắt buộc phải chỉ rõ backend

Giải pháp:

service: <stack>_<service>@docker

➡️ Không tạo service mới, chỉ là reference tới Docker service có sẵn.

4. Mô hình đề xuất sau cải tiến

4.1. Trước cải tiến (hiện tại)

stack-api-sale.yml
- image
- replicas
- volumes
- + toàn bộ Traefik labels (rule dài, entrypoint, tls, port, …)

Nhược điểm:

Stack file dài, khó đọc
Routing khó review
Mỗi thay đổi route → redeploy service

4.2. Sau cải tiến (đề xuất)

(A) Stack file (deployment only)

stack-api-sale.yml
- image
- replicas
- volumes
- network
- placement
❌ Không còn traefik.http.routers.*
Giữ lại label traefik.enable / port để nhận dạng được service

➡️ Stack chỉ còn deployment concern

(B) Routing file (Traefik File Provider)

Ví dụ:

/data/traefik/dynamic/sale/ws_order.yml

http:
  routers:
    ws_order:
      entryPoints:
        - https
      tls: true
      rule: >
        PathPrefix(`/v1/orders`)
        || PathPrefix(`/v1/orderdetails`)
        || PathPrefix(`/v1/orderhelpers`)
        || ...
      service: sale_ws_order@docker

Đặc điểm:

Chỉ chứa routing
Không ảnh hưởng container/service
Save file → Traefik reload runtime (không restart)

5. Phạm vi thay đổi (rõ ràng, có kiểm soát)

Không thay đổi

API path
Controller
Code backend
Network topology
Số lượng service
Cách scale

Chỉ thay đổi

Nơi khai báo routing
- Từ deploy.labels
- Sang file provider của Traefik

6. Lợi ích đạt được

Trước	Sau
Routing nằm trong stack	Routing tách riêng
Mỗi thay đổi route → redeploy	Đổi route không redeploy
Label dài, khó đọc	File routing dễ review
Khó audit path	Audit path rõ ràng
Dễ nhầm lẫn	Ít rủi ro

Quan trọng:
➡️ Không tăng latency, không giảm hiệu năng
➡️ File provider chỉ ảnh hưởng control-plane, không data-plane

7. Rủi ro & cách kiểm soát

Rủi ro

Cấu hình sai service: <stack>_<service>@docker
Sai network (Traefik không reach được backend)

Kiểm soát

Migrate từng service một
Chạy song song test
Rollback dễ (chỉ cần xoá file routing)

8. Đề xuất lộ trình triển khai

Chọn 1 service đại diện (ví dụ: ws_order)
Migrate router sang file provider
Theo dõi 1–2 ngày
Nếu ổn → migrate dần các service còn lại
Cuối cùng:
- Dọn sạch Traefik router labels khỏi stack

9. Kết luận

Đây là cải tiến:

Thuần cấu hình
Không ảnh hưởng nghiệp vụ
Giảm độ phức tạp vận hành
Phù hợp Docker Swarm + Traefik