Traefik reverse proxy và load balancer đáng chú ý ngay cả khi không dùng container

 (j6b72.de)
3 điểm bởi GN⁺ 2024-05-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Traefik nổi tiếng trong môi trường container, nhưng vì có thể triển khai dưới dạng một file thực thi Go duy nhất, nên cũng có thể vận hành như reverse proxy mà không cần container engine
  • So với các họ nginx/caddy/apache2 trực tiếp phục vụ file, Traefik là proxy gần với HAProxy hơn, tập trung vào chuyển tiếp request, trả response và điều chỉnh header
  • Ngay cả khi không dùng label Docker, vẫn có thể cấu hình bằng file provider, tách cấu hình tĩnh và cấu hình động để quản lý router, service và middleware
  • Hỗ trợ TLS Passthrough và nhập/xuất PROXY protocol của HAProxy, nhưng dịch vụ đích cũng phải hỗ trợ PROXY protocol; apache2 và nginx có hỗ trợ
  • Tích hợp xác thực và chặn theo user agent/IP có thể chưa đủ nếu chỉ dùng tính năng mặc định, nên cần cân nhắc cả gánh nặng quản lý của ForwardAuth, oauth2-proxy và plugin bên thứ ba

Có thể dùng Traefik cả bên ngoài container

  • Trong vài năm gần đây, Traefik trở nên phổ biến trong mảng YouTube về home-lab và thường được giới thiệu cùng hạ tầng container như Docker hoặc Kubernetes
  • Về tính năng, Traefik gần với HAProxy hơn là nginx/caddy/apache2
    • Chuyển tiếp request đến service và trả response
    • Có thể sửa header và một số phần của request/response
    • Không hỗ trợ phục vụ file
  • Trong môi trường container, Traefik cũng có thể chạy dưới dạng container và mount Docker socket để tự động phát hiện các container khác
    • Hành vi proxy có thể được cấu hình bằng label Docker của container
    • Khi phát hiện container mới, Traefik có thể tự động yêu cầu chứng chỉ TLS Let’s Encrypt và public service

Triển khai bằng binary đơn lẻ và systemd

  • Traefik được viết bằng Go và được biên dịch thành một file thực thi duy nhất
  • Có thể tải bản phân phối binary từ tài liệu cài đặt Traefik
  • Có thể chạy cả chính Traefik lẫn các service đích mà không cần container engine
  • Ví dụ về unit service systemd có trong repository Traefik
  • Trong vận hành thực tế, ngoài file cấu hình, còn cần tạo user riêng và thiết lập quyền cho file cấu hình

Cấu hình dựa trên file cấu hình

  • Nếu không dùng container thì không thể dùng label Docker, nhưng Traefik có thể được cấu hình bằng file provider
  • Cấu hình được chia làm hai phần lớn
    • Cấu hình tĩnh: đặt certificate provider như Let’s Encrypt và entrypoint, tức các cổng mà Traefik lắng nghe
    • Cấu hình động: đặt router, service và middleware
  • Traefik có thể phát hiện sự kiện trên hệ thống file để hot reload cấu hình động
  • Tài liệu cung cấp các khái niệm cốt lõi và ví dụ cấu hình phù hợp với từng cách dùng
  • Có thể tra nhanh các thuật ngữ như certificate provider, entrypoint, router, service, middleware trong tài liệu Traefik

Hoạt động sau cấu hình và debug

  • Khi cấu hình không đúng, Traefik hiển thị cảnh báo
  • Log mặc định không quá nhiều, nhưng khá dễ hiểu request đi theo đường nào
  • Có trải nghiệm người dùng cho biết cấu hình ban đầu hoàn tất nhanh và không gặp vấn đề bất thường nào

TLS Passthrough và PROXY protocol

  • Traefik hỗ trợ TLS Passthrough
    • Có thể chuyển tiếp traffic đến web service cung cấp chứng chỉ TLS riêng mà không kết thúc TLS tại proxy
    • Cũng có thể cấu hình để service đi qua Traefik và trực tiếp yêu cầu chứng chỉ Let’s Encrypt
    • Proxy không thể thấy nội dung được chuyển tiếp
  • Việc chọn virtual host thông thường được thực hiện bằng HTTP header Host, nhưng trong TLS Passthrough, header này nằm trong phần nội dung đã mã hóa nên không thể sử dụng
  • Đích host được chọn bằng SNI(Server Name Indication) của TLS; Traefik cùng nhiều web server/proxy sử dụng cách này
  • Cũng hỗ trợ nhập/xuất PROXY protocol của HAProxy
    • Đây là cách truyền cho service đích những thông tin bị mất khi người dùng trước tiên đi tới proxy
    • Được đánh giá là dễ xử lý về mặt bảo mật hơn so với các header X-Forwarded-... truyền thống
    • Service đích cũng phải hỗ trợ PROXY protocol
    • apache2 và nginx có hỗ trợ, và danh sách service hỗ trợ cũng đang tăng lên

Những điểm còn tiếc trong tích hợp xác thực

  • Với nginx, có thể dùng Vouch Proxy để bảo vệ một số service bằng Azure AD, hiện là Microsoft Entra authentication
  • Traefik hỗ trợ ForwardAuth, tương tự cách xác thực của nginx
  • Vouch Proxy hiện chưa hoạt động với Traefik và đã có issue liên quan được mở
  • Có thể tự vận hành một instance Keycloak, tích hợp với AAD rồi dùng cho ForwardAuth, nhưng gánh nặng thiết lập ban đầu, duy trì bảo mật và cập nhật là lớn
  • traefik-forward-auth thường được khuyến nghị, nhưng được đánh giá là khó dùng vì lần cập nhật cuối là tháng 6/2020 và cần cập nhật dependency
  • oauth2-proxy từng đem lại trải nghiệm không tốt, và nếu đặt thêm một proxy phía sau proxy, phải căn chỉnh HTTP/2·HTTP/3, timeout, kích thước body và cấu hình WebSocket ở từng proxy trung gian, làm tăng khả năng lỗi
  • Theo cập nhật ngày 2024-05-06, oauth2-proxy cũng có thể tích hợp qua HTTP API
    • Hỗ trợ auth_request của nginx
    • Hỗ trợ ForwardAuth của Traefik
    • Cách này có vẻ là lựa chọn gần với cấu hình mong muốn

User agent và chặn IP

  • Có tình huống không muốn các service nội bộ bị archive.org lưu trữ
  • robots.txt và các header tương tự không hiệu quả trong việc chặn Archive.org; cách chặn crawler là chặn user agent archive.org_bot hoặc chặn dải IP
  • Để chặn user agent hoặc địa chỉ IP trong Traefik, cần plugin bên thứ ba chứ không phải tính năng mặc định
    • Plugin chặn user agent
    • Plugin deny IP
  • Plugin bên thứ ba cần được chú ý khi cập nhật và có thể tạo ra lỗ hổng bảo mật, nên không được ưa chuộng
  • Có thể dùng middleware IPAllowList để cho phép mọi IP ngoại trừ các IP muốn chặn
    • Cũng có thể tính toán dải IP
    • Cách này không tệ hơn chặn trực tiếp, nhưng không thanh lịch vì chỉ nhìn các subnet còn lại thì khó biết dải nào đã bị chặn

Cấu trúc ví dụ cấu hình

  • Ví dụ được chia thành /etc/traefik/traefik.yml và /etc/traefik/dynamic.yml
  • Cấu hình tĩnh thiết lập các mục sau
    • Entry point :80 và :443
    • Redirect endpoint HTTP sang HTTPS không có ngoại lệ
    • Cấp chứng chỉ Let’s Encrypt bằng TLS challenge
    • Theo dõi file cấu hình động /etc/traefik/dynamic.yml
  • Cấu hình động bao gồm các thiết lập sau
    • TCP routing TLS Passthrough cho cloud.xx.xyz
    • Chuyển tiếp đến service 10.33.1.2:4433 của host khác
    • Bật PROXY protocol version 2
    • Với git.xx.xyz, kết thúc TLS rồi proxy đến local http://127.0.0.1:3000
    • Middleware redirect https://xx.xyz/redirmepls sang https://google.com
    • Middleware thêm header X-Robots-Tag: noindex, nofollow, nosnippet, noarchive

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-06
Các ý kiến trên Hacker News

  • Traefik khá ổn, nhưng gặp một vấn đề tệ hại giống như Ansible: có rất nhiều tài liệu và bài viết, nhưng lại không tìm được đúng thứ mình cần
    Dù đã dùng từ v1, tôi vẫn thường bị lạc trong tài liệu và cực kỳ bực bội. Với các dự án nhỏ, tôi thường dùng Caddy vì tài liệu của nó không tệ như Traefik
    Gửi tới những người viết tài liệu kỹ thuật: tài liệu lấy ví dụ làm trung tâm chỉ tốt cho người mới lướt qua. Với người đã quen sản phẩm, thứ họ cần là tài liệu tham chiếu và danh sách đầy đủ, chứ không phải phần mô tả field rải rác trong 10 trang hướng dẫn. Đừng chỉ tập trung vào quy trình onboarding; hãy viết cho cả những người dùng sản phẩm hằng ngày
    Đây là điểm gây khó chịu nhất, là lý do tôi ghét Ansible đến vậy, và Traefik cũng tương tự dù nhẹ hơn

    • Đồng ý. Tôi nghĩ nếu các framework tài liệu hóa như https://diataxis.fr được biết đến rộng rãi hơn thì sẽ có ích cho tất cả mọi người
    • Gần đây, thứ làm tôi khó chịu trong nhóm này là OpenTelemetry. Có hàng nghìn trang, nhưng gần như không có hướng dẫn nào chỉ cách thực sự hoàn thành các workflow cơ bản và phổ biến
    • Một trong những vấn đề của những thứ có thể gọi là họ ngôn ngữ trình diễn giải YAML là bản thân YAML cũng là một ngôn ngữ, nhưng tài liệu của trình diễn giải thường không ghi chép phần đó
      Chúng giả định bạn chỉ làm các tác vụ rất đơn giản trên cấu trúc dữ liệu rất phẳng, nhưng phần lớn thực tế không như vậy. Để dùng những ngôn ngữ này cho đúng, bạn phải hiểu toàn bộ các quy tắc ngầm về cách nên dùng YAML, nhưng tài liệu hầu như không đề cập đến điều đó
      Có tài liệu cấu hình riêng cho từng module, nhưng gần như không rõ cách dùng cấu hình chuẩn, cách xử lý dữ liệu trả về, hoặc kết hợp nó với những thứ chỉ hơi phức tạp hơn. Cảm giác như họ ném cho bạn cả chục ví dụ mỗi mục, mỗi ví dụ một đoạn văn, như một đống nguyên liệu rồi bảo bạn nướng bánh
      Tôi gần như luôn có cùng trải nghiệm với nhiều hệ thống trình diễn giải YAML đã dùng; phải đi qua hàng trăm nghìn dòng YAML mới làm được việc, nhưng tài liệu thì chẳng có mấy giá trị ngoài danh sách cấu hình
    • Ansible chắc chắn khiến bạn phải liên tục tra tài liệu
      Dù vậy, khi dùng ansible-doc, tôi đã tìm được một workflow khá ổn; các alias tôi hay dùng là alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'
      Trước hết dùng adls để nhanh chóng tìm lệnh liên quan, sau đó dùng ad để xem tài liệu, rồi hầu như luôn nhảy thẳng xuống cuối (G) để xem ví dụ. Thường câu trả lời cần tìm nằm ngay ở đó
      Viết script Ansible phụ thuộc rất nhiều vào tài liệu, nên tôi nghĩ ngay cả ở trạng thái mặc định, nó cũng nên hỗ trợ quy trình tra cứu này tốt hơn và cung cấp một giao diện giúp tìm nhanh mà không cần tự tạo cả đống alias
    • Với tôi, Pydantic cũng thuộc nhóm này. Maintainer cho rằng chỉ nên có một nguồn thông tin duy nhất và từ chối làm tài liệu tham chiếu API
      Tất nhiên đó là dự án của họ, nhưng mỗi khi cần tìm một method của object nào đó, tôi lại phải lục qua các trang văn xuôi dài. Đôi khi đọc thẳng source còn dễ hơn

  • Đã dùng Traefik trong production suốt 2 năm. Trước đây dùng NGINX, nhưng vì tích hợp tự động Let's Encrypt nên quyết định chuyển sang Traefik, và giờ hối hận về quyết định đó
    Tài liệu của Traefik không dễ hiểu với tôi và cả đội. Khó chịu, hành xử kỳ lạ mà không có log tử tế
    Ví dụ khi cố tạo lại chứng chỉ, nó thỉnh thoảng thất bại và làm production sập xuống trong tình trạng không biết bao giờ mới khôi phục. Đang quay lại NGINX

    • Ở khoản này NixOS thật sự hữu ích. Chỉ cần thêm vài dòng vào configuration.nix là cấu hình được, bên trong dùng lego(1) và letsencrypt
      security.acme = { acceptTerms = true; defaults.email = "admin-email@provider.net"; certs."mydomain.example.com" = { domain = "*.mydomain.example.com"; dnsProvider = "cloudflare"; environmentFile = "/path/to/cloudflare/password"; }; };
      services.caddy.enable = true;
      services.caddy.virtualHosts."subdomain1.mydomain.example.com" = { extraConfig = '' reverse_proxy 127.0.0.1:1234 ''; useACMEHost = "mydomain.example.com"; };
      Cấu hình bằng nginx chắc cũng khá tương tự. https://github.com/go-acme/lego
    • Tôi cũng chuyển từ NGINX sang Traefik vì hỗ trợ mặc định DNS challenge và chứng chỉ wildcard. Tôi đã mất vài giờ để áp dụng cho domain dùng ở công ty, và dù dùng đúng cùng một cấu hình vốn chạy hoàn hảo ở nhà, thực tế nó chẳng làm gì cả
      Cùng nhà đăng ký domain, cùng API, cùng cấu hình Docker, đã bật toàn bộ log, nhưng không có thông tin nào cho biết vì sao chứng chỉ không được tạo. Cứ như nó còn chẳng thử, chỉ quay về chứng chỉ mặc định được tạo sẵn
      Sau hai phiên xử lý sự cố và vài giờ tìm kiếm, tôi bỏ cuộc và buộc phải dùng file chứng chỉ tự ký. Việc hoàn toàn không có thông tin vì sao không chạy, rồi âm thầm thất bại và chuyển sang hành vi thay thế, thật sự rất bực
      Nhìn chung đây là vấn đề lớn nhất của Traefik. Khi chạy được thì rất tuyệt, nhưng khi không chạy thì việc xử lý sự cố hoặc tìm thông tin cần thiết trong tài liệu luôn khó khăn. Công ty dự định bắt đầu dùng Traefik trong production khoảng cuối năm, nên hy vọng trước đó tôi sẽ quen với Traefik hơn
    • Nếu cần API gateway thì tôi vẫn chỉ dùng reverse proxy tích hợp sẵn của Go. Có thể dễ dàng chỉnh theo dạng mình cần, và cũng dễ tìm thư viện cho các tác vụ phổ biến như CORS, rate limiting, retry
      Điểm hay nhất là không có ngôn ngữ cấu hình. Cứ dùng Go là được
    • Có thể bạn đã biết, hoặc có thể không phù hợp, nhưng có khá nhiều container phụ trợ Docker để tự động hóa chứng chỉ Let's Encrypt cho container Docker nginx
    • Khi mới dùng Traefik tôi cũng gặp nhiều vấn đề tương tự. Ví dụ dùng xác minh TLS-01 mà không thiết lập sẵn DNS record trước khi áp cấu hình thì rất căng thẳng. Việc lượng log quá ít cũng gây bực bội tương tự
      Sau này tôi mới biết rằng nếu DNS không được thiết lập đúng, sau khi nỗ lực xác minh thất bại N lần, Let's Encrypt sẽ từ chối xác minh TLS-01 lại trong một thời gian; vấn đề bạn gặp nghe cũng giống kiểu đó
      Sau khi chuyển sang xác minh DNS-01, trải nghiệm bỗng tốt hơn hẳn. Có thể tạo chứng chỉ cho cả dịch vụ không public ra ngoài, và cần ít orchestration hơn nhiều so với cách TLS-01
      Nếu nhà cung cấp DNS hoạt động ổn, khi có vấn đề bạn nhiều khả năng sẽ nhận lỗi API trước khi Let's Encrypt xác minh record, và trạng thái lỗi xảy ra sớm hơn rất nhiều so với cơ chế backoff sau lỗi kiểm tra của Let's Encrypt. Giờ tôi gần như đã quyết rằng dù dùng Traefik, Caddy, Nginx hay reverse proxy nào khác thì Let's Encrypt cũng chỉ dùng xác minh dựa trên DNS-01; nếu buộc phải dùng TLS-01 thì nhất định sẽ kiểm tra với Staging API để bảo đảm mọi thứ đúng ngay từ đầu
      Nhân tiện, nếu tạo chứng chỉ Let's Encrypt Staging trong Traefik thì không có cách hay để vô hiệu hóa chứng chỉ đó. Phải chỉnh ACME JSON để xóa chứng chỉ rồi khởi động lại Traefik để áp dụng thay đổi. Có thể SIGHUP cũng được, nhưng tôi chưa thử
      Nhìn chung có nhiều lỗi im lặng và hành vi kỳ lạ, nhưng nỗi đau lớn nhất là nó làm lỗi của dịch vụ phụ thuộc trở nên mù mờ

  • Tôi dùng Caddy thay vì Traefik. Với tôi, quản lý Caddyfile dễ hơn nhiều so với cấu hình YAML của Traefik, và tôi duy trì các Caddyfile riêng cho triển khai local, production và on-premises
    Cũng có nhiều plugin tuyệt vời; chúng tôi dùng plugin coraza WAF cho Caddy và nó chạy tốt

    • Trong cấu hình self-hosting, tôi đã chuyển từ Traefik sang Caddy và caddy-docker-proxy
      Có đủ mọi chức năng cần thiết mà đơn giản hơn nhiều
      https://github.com/lucaslorentz/caddy-docker-proxy
    • Tôi thích Caddy, nhưng cũng mong tài liệu triển khai production được cải thiện hơn. Đặc biệt có quá nhiều câu hỏi chưa có lời đáp về best practice cho quản lý storage và cấu hình
      Chẳng hạn như khi dùng storage bên ngoài thì nên xử lý storage cục bộ thế nào. Có nói là có thể coi nó là stateless, nhưng cũng có thể không phải vậy
      Cuối cùng chỉ còn cách cầu mong người tạo module mình cần thật sự hiểu rõ. Vì phía đó cũng không có chuẩn tài liệu. Maintainer cần kìm bớt những module ngẫu nhiên cung cấp chức năng cốt lõi nhưng tài liệu bằng 0, ví dụ backend storage S3
    • Nếu không cần mấy trò phức tạp như service discovery hay autoscaling, hoặc có thể tự xử lý bằng script, thì có thể vui vẻ bỏ qua Traefik, Docker Swarm, Kubernetes, v.v. và cứ dùng Caddy. Caddy thật sự làm được hầu hết mọi thứ và làm tốt

  • Nếu nhu cầu chỉ khiêm tốn ở mức vài máy chủ Docker và vài chục container, tôi tự hỏi có lý do gì để dùng Traefik thay vì nginx. Tôi đang dùng https://github.com/NginxProxyManager/nginx-proxy-manager, ở quy mô nhỏ như thế này Traefik có đem lại lợi thế gì không?

    • Ở đây tôi nghĩ https://github.com/caddyserver là lựa chọn tốt nhất. Nó tự động xử lý chứng chỉ SSL, rất nhẹ, và cú pháp cấu hình cực kỳ rõ ràng
    • Tôi thích hot reload của Traefik. Nếu muốn ẩn một dịch vụ, tức ứng dụng đang được proxy, hoặc thêm route mới, theo thuật ngữ của Traefik là router, hoặc thêm middleware như xác thực cơ bản, chuyển hướng HTTPS, thao tác header, chỉ cần thả file vào là tự động được áp dụng. Không cần reload Traefik hay virtual host của nó
      Thật ra cũng có phần vì tôi không thích cú pháp nginx và Traefik trông có vẻ bóng bẩy. Tôi bắt đầu dùng vì gia hạn Let's Encrypt và container, rồi tiếp tục dùng vì cách cấu hình
    • Nếu cấu hình bạn đang có đã chạy tốt thì tôi không nghĩ có lợi ích gì khi cố đổi
      Có lẽ tôi chỉ cân nhắc chuyển sang khi cần một tính năng Traefik có mà Nginx không có
    • Tôi cũng đang dùng NginxProxyManager và có 8 host, nhưng vẫn chưa thấy câu trả lời nào giải thích caddyserver hay traefik có lợi thế gì so với NPM
    • Đồng ý. Cấu hình Nginx dễ và một khi đã chỉnh xong thì có thể quên nó đi. Dù sao phần lớn trường hợp cũng chỉ copy-paste từ các cấu hình khác mình đã có
      Certbot có mặt khắp nơi và hỗ trợ nhiều kịch bản hơn, nên việc Let's Encrypt tự động được xem là điểm bán hàng cũng hơi lạ. Điểm bán hàng của Traefik và Caddy không phải là làm cho mọi thứ dễ hơn so với các lựa chọn thay thế vốn đã được hỗ trợ rộng rãi, nên với tôi nó không thật sự thuyết phục

  • Vài tuần trước tôi chọn reverse proxy và cuối cùng chọn Caddy vì sự đơn giản. Dù vậy, tự động phát hiện container của Traefik và cách tham chiếu bằng label khá hay, và Caddy cũng có plugin làm việc tương tự
    Tôi đã đọc bài viết nhưng vẫn chưa chắc Traefik có điểm nào tốt hơn Caddy đối với tôi hay không. Có thể với người khác thì có, nên tôi muốn nghe ý kiến

  • Cũng đáng chú ý là Traefik mặc định được cấu hình sẵn trong K3s. Nhờ vậy K3s trở thành cách nhanh nhất để dựng một cụm K8s dùng thử, và cũng cho phép đối xử với cụm như gia súc
    Chỉ cần thêm deployment và các service liên quan dưới dạng NodePort là có thể truy cập ứng dụng mà không phải lo về ingress controller
    Tôi dùng shell script để dựng cụm K3s và kiểm thử ứng dụng được chỉ định bằng positional argument khi cần. Khi đó tôi tận dụng registry container tạm thời của ttl.sh. Khi cùng script kết thúc thì cụm cũng bị xóa

  • Tôi đang cân nhắc chuyển reverse proxy tự host sang Traefik. Khác với tác giả, tôi đang chạy workload container hóa bằng Docker Compose, và hiện dùng Caddy cùng plugin caddy-docker-proxy rất tốt
    Những gì tôi đang có là reverse proxy cấu hình dựa trên Docker label, tự động phát hiện workload mới, chứng chỉ TLS, và thiết lập DNS tự động thông qua plugin caddy-dynamicdns. Ngay cả khi ISP cấp IP khác, tôi cũng không phải quá lo chuyện mất quyền truy cập
    Tuy nhiên mỗi khi thêm hoặc khởi động lại workload mới, toàn bộ Caddy sẽ restart và quyền truy cập bị gián đoạn tạm thời. Caddy không thể chuyển các kết nối hiện có sang instance mới
    Ngoài ra việc dùng chứng chỉ wildcard chưa đủ đơn giản. Tôi không muốn mọi workload bị lộ ra thế giới qua certificate transparency log nên dùng chứng chỉ wildcard, nhưng khi đó không thể dùng cú pháp Caddyfile đơn giản với chứng chỉ riêng cho từng hostname. Tôi biết Caddy đang làm phần này, nhưng hiện tại vẫn là vậy
    Dù sao tôi đã dùng Traefik trong môi trường k8s và thấy khá ổn, nên cũng định thử cho mục đích cá nhân. Mong là những lời này không khiến ai đó bỏ qua việc thử Caddy. Caddy thực sự cũng rất tốt

    • Với những thứ như host một mục đích thì tôi dùng Caddy, nhưng với vấn đề bạn mô tả tôi sẽ ném Traefik vào 100%. Thực tế tôi đang dùng nó cho ingress của cụm k8s, và trong môi trường phát triển thì chạy nó để dùng localtest.me cùng hostname
      Rất đáng thử một lần. Cả hai đều tuyệt vời ở những phạm vi khác nhau
    • Tôi dùng rootless Docker Compose + Traefik. Vì chứng chỉ wildcard làm được thật sự không đau đớn. Tuy nhiên tôi dùng DNS server riêng và dùng RFC2136 DDNS cho Let's Encrypt DNS challenge
      Thực ra không cần plugin. Tôi có một Ansible playbook để thiết lập toàn bộ thứ này trên VM và tạo cả template file compose, và một playbook khác để xóa mọi thứ trên server trừ dữ liệu và mount. Sao lưu thì dùng restic cùng script tùy chỉnh có thể sao lưu file, nhiều DB, v.v. tới nhiều vị trí
      Trước đây tôi triển khai k3s nhưng nhận ra nó quá thừa và phức tạp cho self-hosting. Tôi chỉ cần triển khai nhanh và không phải tự xử lý chứng chỉ
    • Tôi chưa dùng Caddy mà dùng Traefik, và dùng tính năng phát hiện Docker attribute cho cấu hình và tự động gia hạn chứng chỉ TLS. Dynamic DNS thì tôi không rõ và không dùng trong Traefik. Theo tôi nhớ thì thêm hoặc xóa container cũng không cần restart
    • Tôi đã dùng caddy-docker-proxy trong production, và khi load cấu hình mới Caddy không ngắt kết nối
      Tôi vừa kiểm tra cục bộ và nó hoạt động tốt
    • Đó là một hạn chế rất lớn. Tôi chưa từng nghe reverse proxy nào phải restart và ngắt kết nối để cập nhật cấu hình. Thường đó là phần đầu tiên, cơ bản nhất phải được lo trong thiết kế kiểu server như vậy

  • Tôi đã dùng Traefik khá nhiều, nhưng phát mệt vì phải xử lý label docker-compose, các tầng lớp và hàng đống dòng chỉ để dựng một reverse proxy đơn giản. Rồi tôi phát hiện Caddy và không ngoái lại nữa
    Có lẽ tôi không phải nhóm người dùng mục tiêu của Traefik. Thứ tôi cần chỉ là reverse proxy bật HTTPS hoặc một lớp xác thực cơ bản. Trong Caddy, cả hai đều chỉ cần một dòng, rất gọn, và cũng không có các tầng lớp mà đến giờ tôi vẫn chưa hiểu

  • Tôi đã dùng Traefik cho toàn bộ hệ thống self-host trong vài năm qua
    Tuy nhiên, tôi đã bỏ tính năng phát hiện động và nhãn Docker vì chúng quá rắc rối và debug rất khó chịu
    Thay vào đó, tôi dùng template engine để tạo tệp cấu hình tĩnh. Gần như mọi dịch vụ đều là tổ hợp host/target/port nên rất dễ tạo các phần liên quan, và ngoài xử lý TLS thì cũng không có middleware phức tạp nào. Có vẻ tác giả bài viết được liên kết cũng chọn hướng tương tự
    Cấu hình được tạo bằng script Ansible rồi sao chép sang máy đang chạy Traefik; Traefik theo dõi thư mục chứa tệp đó và tự động nạp lại khi có thay đổi. Cách này vẫn hoạt động rất tốt

  • Tôi đang dùng Traefik cùng container trong production, và điểm tôi thích nhất là cấu hình được đặt trong nhãn container. Vì vậy hầu như không cần chỉnh sửa chính cấu hình Traefik
    Nhược điểm lớn nhất là phải tìm xem nên phát âm cái tên này thế nào. Có vẻ cứ đọc như traffic thông thường, nhưng tôi cứ muốn gọi kiểu “trey-feek”

    • Tôi rất đồng ý với cách dùng nhãn. Lúc viết ban đầu thì hơi khó hơn vì phải escape và khá dài dòng, nhưng phạm vi cần theo dõi giảm đi rất nhiều
      Tôi xem kết hợp Traefik và Docker Compose là một điểm cân bằng tốt cho self-host quy mô nhỏ trước khi lớn đến mức phải chuyển sang k8s, đặc biệt khi số máy chủ còn ít hơn số máy chủ mà control plane high-availability của k8s sử dụng
    • Chúng tôi cũng đang dùng trong production. Có thể mọi người sẽ cười, nhưng việc đặt một cái tên trông ngầu và độc đáo trên giấy nhưng thực tế lại tệ hại là một nhược điểm lớn
      Lượng nhăn mặt và tiếng cười mà tôi nhận được từ đồng nghiệp là rất lớn, và nó cản trở việc đưa sản phẩm vào sử dụng cũng như quá trình sử dụng
      Chúng tôi gọi là “tray-feek” và như vậy còn tạm ổn, nhưng khi gọi với bộ phận hỗ trợ chính thức thì họ nói nó được phát âm y hệt “traffic” thông thường. Vì thế mỗi lần nói về proxy đó lại thành những câu kiểu “nhận traffic bằng load balancer công khai, rồi load balancing native của traffic gửi traffic đến pod của traffic”. Nghe ngu ngốc, và thực sự là ngu ngốc
    • Tôi cứ phát âm là “traffic”. Tôi không tham gia trò đấu trí chết tiệt của họ đâu
    • Tôi nghĩ nhược điểm lớn nhất là nếu container không tồn tại hoặc không chạy thì Traefik không biết gì về container hay nhãn đó
      Nếu không như vậy thì đã dễ làm những thứ hay ho hơn, như trang bảo trì hoặc khởi động container ở request đầu tiên sau khi không hoạt động
      Vì vậy tôi đang nghĩ đến việc tạo một plugin biết vị trí lưu các tệp compose và có thể đọc trực tiếp từ đó
    • ae gần với y hoặc hi nhất. Vì vậy tôi đoán là Tryfik, nếu không thì là Trayfik. Nếu fik theo kiểu châu Âu thì cũng có thể là feek