컨테이너 없이도 주목할 만한 Traefik 리버스 프록시·로드 밸런서

 (j6b72.de)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Traefik은 컨테이너 환경에서 유명하지만, 단일 Go 실행 파일로 배포할 수 있어 컨테이너 엔진 없이도 리버스 프록시로 운용할 수 있음
  • 파일을 직접 서빙하는 nginx/caddy/apache2 계열보다 HAProxy에 가까운 프록시이며, 요청 전달·응답 반환·헤더 조정에 초점을 둠
  • Docker 라벨을 쓰지 않아도 설정 파일 provider로 구성할 수 있고, 정적 설정과 동적 설정을 나눠 라우터·서비스·미들웨어를 관리함
  • TLS Passthrough와 HAProxy의 PROXY protocol 입출력을 지원하지만, PROXY protocol은 대상 서비스도 지원해야 하며 apache2와 nginx는 지원함
  • 인증 통합과 사용자 에이전트·IP 차단은 기본 기능만으로 부족할 수 있어, ForwardAuth·oauth2-proxy·서드파티 플러그인의 관리 부담까지 함께 판단해야 함

컨테이너 밖에서도 쓸 수 있는 Traefik

  • Traefik은 최근 몇 년 동안 home-lab YouTube 영역에서 인기를 얻었고, 주로 Docker나 Kubernetes 같은 컨테이너 인프라와 함께 소개됨
  • 기능 성격은 nginx/caddy/apache2보다 HAProxy에 더 가까움
    • 요청을 서비스로 전달하고 응답을 반환함
    • 헤더와 요청·응답의 일부를 수정할 수 있음
    • 파일 서빙은 지원하지 않음
  • 컨테이너 환경에서는 Traefik도 컨테이너로 실행하고 Docker 소켓을 마운트해 다른 컨테이너를 자동 감지할 수 있음
    • 프록시 동작은 컨테이너의 Docker 라벨로 설정 가능함
    • 새 컨테이너를 감지하면 Let’s Encrypt TLS 인증서를 자동 요청하고 서비스를 공개할 수 있음

단일 바이너리와 systemd 배포

  • Traefik은 Go로 작성되어 단일 실행 파일로 컴파일됨
  • 바이너리 배포판은 Traefik 설치 문서에서 받을 수 있음
  • 컨테이너 엔진 없이 Traefik 자체와 대상 서비스를 모두 실행할 수 있음
  • systemd 서비스 유닛 예시는 Traefik 저장소에 있음
  • 실제 운영에서는 설정 파일 외에도 별도 사용자 생성과 설정 파일 권한 설정이 필요함

설정 파일 기반 구성

  • 컨테이너를 쓰지 않으면 Docker 라벨을 사용할 수 없지만, Traefik은 파일 provider로 설정 가능함
  • 설정은 크게 두 부분으로 나뉨
    • 정적 설정: Let’s Encrypt 같은 인증서 공급자와 Traefik이 수신하는 포트인 엔트리포인트를 둠
    • 동적 설정: 라우터, 서비스, 미들웨어를 둠
  • Traefik은 파일 시스템 이벤트를 감지해 동적 설정을 핫 리로드할 수 있음
  • 문서는 핵심 개념과 설정 예시를 각 방식에 맞춰 제공함
  • certificate provider, entrypoint, router, service, middleware 같은 용어는 Traefik 문서에서 빠르게 확인할 수 있음

설정 후 동작과 디버깅

  • 설정이 맞지 않을 때 Traefik은 경고를 표시함
  • 기본 로그는 많지 않은 편이지만, 요청이 어떤 경로를 타는지 이해하기 쉬움
  • 초기 구성은 빠르게 끝났고 임의의 문제도 겪지 않았다는 사용 경험이 있음

TLS Passthrough와 PROXY protocol

  • Traefik은 TLS Passthrough를 지원함
    • 프록시에서 TLS를 종료하지 않고, 자체 TLS 인증서를 제공하는 웹 서비스로 트래픽을 전달할 수 있음
    • 서비스가 Traefik을 통과해 Let’s Encrypt 인증서를 직접 요청하는 구성도 가능함
    • 프록시는 전달되는 내용을 볼 수 없음
  • 일반적인 가상 호스트 선택은 HTTP Host 헤더로 이뤄지지만, TLS Passthrough에서는 해당 헤더가 암호화된 본문 안에 있어 사용할 수 없음
  • TLS의 SNI(Server Name Indication) 로 대상 호스트를 선택하며, Traefik과 여러 웹 서버·프록시가 이 방식을 사용함
  • HAProxy의 PROXY protocol도 입출력을 지원함
    • 사용자가 먼저 프록시에 도달하면서 사라지는 정보를 대상 서비스에 전달하는 방식임
    • 기존 X-Forwarded-... 헤더보다 보안적으로 다루기 쉽다고 평가됨
    • 대상 서비스도 PROXY protocol을 지원해야 함
    • apache2와 nginx는 지원하며, 지원 서비스 목록도 늘고 있음

인증 통합에서 남는 아쉬움

  • nginx에서는 Vouch Proxy를 사용해 일부 서비스를 Azure AD, 현재 Microsoft Entra 인증으로 보호하는 구성이 가능함
  • Traefik은 nginx의 인증 방식과 비슷한 ForwardAuth를 지원함
  • Vouch Proxy는 아직 Traefik에서 동작하지 않으며 관련 이슈가 열려 있음
  • Keycloak 인스턴스를 직접 운영하고 AAD와 통합해 ForwardAuth에 사용할 수 있지만, 초기 설정과 보안 유지·업데이트 부담이 큼
  • traefik-forward-auth는 자주 추천되지만, 마지막 업데이트가 2020년 6월이고 의존성 업데이트가 필요해 사용하기 어렵다고 판단함
  • oauth2-proxy는 과거 경험이 좋지 않았고, 프록시 뒤에 또 프록시를 두면 HTTP/2·HTTP/3, 타임아웃, 본문 크기, WebSocket 설정을 중간 프록시마다 맞춰야 해 오류 가능성이 커짐
  • 2024-05-06 업데이트에 따르면 oauth2-proxy는 HTTP API로도 통합 가능함
    • nginx의 auth_request를 지원함
    • Traefik의 ForwardAuth를 지원함
    • 이 방식은 원하는 구성에 가까운 선택지로 보임

사용자 에이전트와 IP 차단

  • 내부 서비스가 archive.org에 아카이브되는 것을 원하지 않는 상황이 있음
  • robots.txt와 유사 헤더는 Archive.org 차단에 효과가 없으며, crawler 차단 방법은 archive.org_bot 사용자 에이전트 차단 또는 IP 범위 차단임
  • Traefik에서 사용자 에이전트나 IP 주소를 차단하려면 기본 기능이 아니라 서드파티 플러그인이 필요함
    • 사용자 에이전트 차단 플러그인
    • deny IP 플러그인
  • 서드파티 플러그인은 업데이트 때 신경 써야 하고 보안 취약점을 만들 수 있어 선호하지 않음
  • IPAllowList 미들웨어로 차단하려는 IP를 제외한 나머지를 허용하는 방식은 가능함
    • IP 범위 계산도 가능함
    • 직접 차단보다 나쁘지는 않지만, 남은 서브넷만 보고 어떤 범위가 차단됐는지 알기 어려워 우아하지 않음

설정 예시 구성

  • 예시는 /etc/traefik/traefik.yml과 /etc/traefik/dynamic.yml로 나뉨
  • 정적 설정은 다음을 구성함
    • :80과 :443 엔트리포인트
    • HTTP 엔드포인트를 예외 없이 HTTPS로 리다이렉트
    • TLS challenge를 사용하는 Let’s Encrypt 인증서 발급
    • 동적 설정 파일 /etc/traefik/dynamic.yml 감시
  • 동적 설정은 다음 구성을 포함함
    • cloud.xx.xyz에 대한 TLS Passthrough TCP 라우팅
    • 다른 호스트의 10.33.1.2:4433 서비스로 전달
    • PROXY protocol version 2 활성화
    • git.xx.xyz에 대해 로컬 http://127.0.0.1:3000으로 TLS 종료 후 프록시
    • https://xx.xyz/redirmepls를 https://google.com으로 리다이렉트하는 미들웨어
    • X-Robots-Tag: noindex, nofollow, nosnippet, noarchive 헤더를 추가하는 미들웨어

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Traefik은 꽤 괜찮지만 Ansible과 같은 끔찍한 문제를 겪음. 문서와 글은 많은데 정작 필요한 걸 찾을 수가 없음
    v1부터 써왔는데도 문서에서 자주 길을 잃고 크게 답답해짐. 작은 프로젝트에는 Caddy를 쓰는 편인데, 문서가 Traefik만큼 나쁘지는 않기 때문임
    기술 문서 작성자에게 말하자면, 예제 중심 문서는 훑어보는 초보자에게만 좋음. 제품에 익숙한 사람에게는 10개의 튜토리얼 페이지에 흩어진 필드 설명이 아니라 참조 문서와 빠짐없는 목록이 필요함. 온보딩 절차에만 집중하지 말고 매일 제품을 쓰는 사람에게 맞춰야 함
    이게 가장 거슬리는 부분이고, Ansible을 그렇게 싫어하게 된 이유이며 Traefik도 정도는 덜하지만 비슷함

    • 동의함. https://diataxis.fr 같은 문서화 프레임워크가 더 널리 알려지면 모두에게 도움이 될 것 같음
    • 이 범주에서 최근에 짜증났던 건 OpenTelemetry임. 수천 페이지가 있는데도 기본적이고 흔한 작업 흐름을 실제로 달성하는 방법은 거의 없음
    • YAML 해석기 계열 언어라고 부를 만한 것들의 문제 중 하나는 YAML 자체가 언어인데, 해석기 문서에서는 대체로 그 부분을 문서화하지 않는다는 점임
      아주 단순한 작업을 매우 평평한 자료 구조에서만 할 거라고 가정하는데, 대부분의 현실은 그렇지 않음. 이런 언어를 제대로 쓰려면 YAML을 어떻게 써야 하는지에 대한 암묵적 규칙 전체를 이해해야 하는데, 문서에서는 그걸 거의 짚어주지 않음
      각 모듈의 고유 설정 문서는 있지만 표준 설정을 어떻게 쓰는지, 반환된 데이터를 어떻게 다루거나 조금만 복잡한 것과 결합하는지는 거의 명확하지 않음. 항목마다 한 단락짜리 예제 십여 개를 재료 더미처럼 던져주고 케이크를 구우라고 하는 느낌임
      써본 여러 YAML 해석기 시스템에서 거의 항상 같은 경험을 했고, YAML 수십만 줄을 지나야 일을 처리할 수 있게 됐지만 문서는 설정 목록 이상의 가치는 별로 없었음
    • Ansible은 확실히 문서를 계속 찾아보게 만듦
      그래도 ansible-doc을 쓰면서 꽤 괜찮은 작업 흐름을 찾았고, 자주 쓰는 별칭은 alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'임
      먼저 adls로 관련 명령을 빠르게 검색하고, ad 로 문서를 확인한 뒤, 거의 항상 끝으로 바로 점프해서(G) 예제를 봄. 보통 거기에 필요한 답이 바로 있음
      Ansible 스크립트 작성은 문서 의존도가 매우 높으니, 기본 상태에서도 이런 조회 과정을 더 잘 지원하고 별칭을 잔뜩 만들지 않아도 빠르게 찾을 수 있는 인터페이스를 제공해야 한다고 봄
    • Pydantic도 나에겐 이 범주에 들어감. 관리자는 정보 출처가 하나여야 한다고 보고 API 참조 문서를 만들기를 거부함
      물론 자기 프로젝트이긴 하지만, 객체의 메서드 하나를 찾을 때마다 긴 산문 페이지를 뒤져야 함. 가끔은 그냥 소스를 읽는 게 더 쉬움

  • 프로덕션에서 Traefik을 2년 동안 써왔음. 예전에는 NGINX를 썼지만 자동 Let's Encrypt 연동 때문에 Traefik으로 옮기기로 했고, 그 결정을 후회함
    Traefik 문서는 나와 팀에게 말이 잘 안 됨. 까다롭고, 제대로 된 로그 없이 이상하게 동작함
    예를 들어 인증서를 다시 만들려고 하면 간헐적으로 실패하면서 프로덕션이 언제 복구될지 모르는 상태로 내려감. 다시 NGINX로 돌아가는 중임

    • 이런 부분에서는 NixOS가 정말 도움이 됐음. configuration.nix에 몇 줄만 추가하면 설정할 수 있고, 내부적으로는 lego(1)와 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"; };
      nginx로 설정하는 것도 꽤 비슷할 것 같음. https://github.com/go-acme/lego
    • 나도 DNS 챌린지와 와일드카드 인증서 기본 지원 때문에 NGINX에서 Traefik으로 옮겼음. 회사에서 쓰는 도메인에 적용하려고 몇 시간을 썼고, 집에서 완벽히 동작하는 동일한 설정을 썼는데도 실제로는 아무 일도 하지 않았음
      같은 도메인 등록기관, 같은 API, 같은 Docker 설정이었고 로그도 전부 켰지만 인증서가 왜 만들어지지 않는지 아무 정보도 없었음. 시도조차 안 한 것처럼 그냥 생성된 기본 인증서로 되돌아갔음
      두 번의 문제 해결 세션과 몇 시간의 검색 끝에 포기하고 자체 서명 인증서 파일을 쓸 수밖에 없었음. 왜 안 되는지 정보가 전혀 없고 조용히 실패한 뒤 대체 동작으로 넘어가는 게 정말 답답함
      전반적으로 Traefik의 가장 큰 문제는 이거였음. 동작할 때는 훌륭하지만, 안 될 때는 문제 해결하거나 문서에서 필요한 정보를 찾기가 항상 어려웠음. 회사에서는 연말쯤 프로덕션에서 Traefik을 쓰기 시작할 예정이라 그 전에 Traefik과 좀 더 친해지기를 바람
    • API 게이트웨이가 필요하면 그냥 Go 내장 역방향 프록시를 써왔음. 필요한 형태로 쉽게 바꿀 수 있고, CORS·요청 제한·재시도 같은 흔한 작업용 라이브러리도 쉽게 찾을 수 있음
      가장 좋은 점은 설정 언어가 없다는 것임. 그냥 Go를 쓰면 됨
    • 이미 알 수도 있고 맞지 않았을 수도 있지만, nginx Docker 컨테이너용 Let's Encrypt 인증서를 자동화하는 Docker 보조 컨테이너가 꽤 많음
    • Traefik을 처음 쓸 때 비슷한 문제를 많이 겪었음. 예를 들어 TLS-01 검증을 쓰는데 설정 적용 전에 DNS 레코드를 잡아두지 않으면 큰 스트레스를 유발했음. 로그 양이 부족해서 답답했던 것도 같음
      나중에 알게 된 건 DNS가 제대로 설정되지 않으면 검증 시도가 N번 실패한 뒤 Let's Encrypt가 한동안 TLS-01 검증을 다시 거부한다는 점이었고, 당신이 겪은 문제도 그런 종류처럼 들림
      DNS-01 검증으로 옮긴 뒤에는 경험이 갑자기 훨씬 좋아졌음. 공개적으로 노출되지 않은 서비스의 인증서도 만들 수 있고, TLS-01 방식보다 오케스트레이션도 훨씬 적게 필요함
      DNS 제공자가 정상이라면, 문제가 있을 때도 Let's Encrypt가 레코드를 검증하기 전에 API 오류를 받을 가능성이 높고, 실패 상태가 Let's Encrypt의 검사 실패 백오프보다 훨씬 앞에서 발생함. 이제 Traefik, Caddy, Nginx나 다른 역방향 프록시를 쓰든 Let's Encrypt는 DNS-01 기반 검증만 쓰겠다고 거의 마음먹었고, TLS-01을 써야 한다면 Staging API로 처음부터 제대로 맞췄는지 반드시 확인할 것임
      참고로 Traefik에서 Let's Encrypt Staging 인증서를 만들면 그 인증서를 무효화할 좋은 방법이 없음. ACME JSON을 손봐서 인증서를 제거하고 Traefik을 재시작해야 변경을 반영함. SIGHUP으로 될지도 모르지만 시도해보진 않았음
      전체적으로 이상한 침묵 실패와 동작이 많지만, 가장 큰 고통은 의존 서비스 오류를 불투명하게 만든다는 점임

  • Traefik보다는 Caddy를 씀. 내 기준으로는 Traefik의 YAML 설정보다 Caddyfile을 관리하는 게 훨씬 쉽고, 로컬·프로덕션·온프레미스 배포용 Caddyfile을 각각 유지함
    훌륭한 플러그인도 많고, 우리는 Caddy용 coraza WAF 플러그인을 쓰는데 잘 동작함

    • 셀프호스팅 구성에서 Traefik에서 Caddy와 caddy-docker-proxy로 옮겼음
      필요한 기능은 다 있으면서 훨씬 단순함
      https://github.com/lucaslorentz/caddy-docker-proxy
    • Caddy를 좋아하지만 프로덕션 배포 문서도 더 나아졌으면 함. 특히 스토리지와 설정 관리에 관한 모범 사례에 답이 없는 질문이 너무 많음
      외부 스토리지를 쓸 때 로컬 스토리지는 어떻게 다뤄야 하는지 같은 것들임. 상태 없는 것으로 취급할 수 있다고는 하지만 아닐 수도 있음
      결국 필요한 모듈을 만든 사람이 제대로 알고 있기를 기도해야 함. 그쪽도 문서 표준이 없기 때문임. 관리자는 핵심 기능을 제공하면서 문서가 0인 무작위 모듈, 예컨대 S3 스토리지 백엔드 같은 것에 제동을 걸 필요가 있음
    • 서비스 발견이나 자동 확장 같은 복잡한 장난이 필요 없거나 직접 스크립트로 감당할 수 있다면, Traefik·Docker Swarm·Kubernetes 등을 기쁘게 건너뛰고 그냥 Caddy를 쓰면 됨. Caddy는 정말 대부분을 할 수 있고 잘함

  • Docker 호스트 몇 대와 컨테이너 수십 개 정도의 소박한 필요라면 Traefik을 nginx보다 써야 할 이유가 뭘까 싶음. 나는 https://github.com/NginxProxyManager/nginx-proxy-manager를 쓰는데, 이 정도 작은 규모에서 Traefik이 이점을 줄까?

    • 여기서는 https://github.com/caddyserver가 최선이라고 봄. SSL 인증서를 자동으로 처리하고, 매우 가볍고, 설정 문법이 아주 명확함
    • Traefik의 핫 리로드가 마음에 듦. 서비스, 즉 프록시되는 앱을 숨기거나 새 라우트, Traefik 용어로는 router를 추가하거나, 기본 인증·HTTPS 리디렉션·헤더 조작 같은 미들웨어를 추가하고 싶으면 파일만 떨어뜨리면 자동으로 반영됨. Traefik이나 그 가상 호스트를 다시 불러올 필요가 없음
      사실 nginx 문법을 좋아하지 않고 Traefik이 반짝여 보였다는 것도 있음. Let's Encrypt 갱신과 컨테이너 때문에 들어갔고, 설정 방식 때문에 계속 쓰게 됨
    • 이미 가진 구성이 잘 동작한다면 굳이 바꿔서 얻을 이점은 없다고 봄
      Traefik이 제공하지만 Nginx에는 없는 기능이 필요해지는 순간에야 전환을 고려할 것 같음
    • 나도 NginxProxyManager를 쓰고 있고 호스트는 8개인데, caddyserver나 traefik이 NPM보다 어떤 이점을 주는지 설명하는 답은 아직 못 봤음
    • 동의함. Nginx 설정은 쉽고 한 번 맞춰두면 잊어버릴 수 있음. 어차피 대부분은 이미 가진 다른 설정에서 복사해 붙여넣는 경우가 많음
      Certbot이 어디에나 있고 더 많은 시나리오를 지원하는데 자동 Let's Encrypt가 판매 포인트라는 것도 좀 이상함. Traefik과 Caddy의 판매 포인트는 이미 널리 지원되는 대안보다 더 쉽게 만들어주는 게 아니라서 나에겐 잘 와닿지 않음

  • 몇 주 전 역방향 프록시를 고르다가 결국 단순성 때문에 Caddy로 정했음. 다만 Traefik의 컨테이너 자동 발견과 레이블 참조는 꽤 좋고, Caddy에도 같은 일을 하는 플러그인이 있음
    글을 읽었지만 내게 Traefik이 Caddy보다 나은 점이 있는지는 아직 확신이 안 섬. 다른 사람에게는 있을 수도 있으니 의견을 듣고 싶음

  • Traefik이 기본적으로 K3s에 설정되어 있다는 점도 주목할 만함. 덕분에 K3s는 테스트용 K8s 클러스터를 가장 빠르게 띄우는 방법이 됐고, 클러스터도 가축처럼 다룰 수 있게 해줌
    배포와 관련 서비스를 NodePort로 추가하기만 하면, 인그레스 컨트롤러를 걱정하지 않고 앱에 접근할 수 있음
    나는 셸 스크립트로 K3s 클러스터를 띄우고, 위치 인자로 지정한 앱을 필요할 때 테스트함. 이때 ttl.sh의 임시 컨테이너 레지스트리를 활용함. 같은 스크립트가 끝나면 클러스터도 제거함

  • 셀프호스팅용 역방향 프록시를 Traefik으로 옮길까 고민 중임. 글쓴이와 달리 나는 Docker Compose로 컨테이너화된 워크로드를 돌리고 있고, 지금은 훌륭한 caddy-docker-proxy 플러그인과 함께 Caddy를 쓰고 있음
    현재 얻고 있는 건 Docker 레이블 기반 설정의 역방향 프록시, 새 워크로드 자동 감지, TLS 인증서, caddy-dynamicdns 플러그인을 통한 자동 DNS 설정임. ISP가 다른 IP를 줘도 접근을 잃는 일을 크게 신경 쓰지 않아도 됨
    다만 새 워크로드가 추가되거나 재시작될 때마다 Caddy 전체가 재시작되어 일시적으로 접근이 끊김. Caddy는 기존 연결을 새 인스턴스로 넘겨주지 못함
    또 와일드카드 인증서 사용이 충분히 단순하지 않음. 모든 워크로드가 인증서 투명성 로그를 통해 세상에 드러나는 걸 원치 않아서 와일드카드 인증서를 쓰는데, 그러면 호스트명마다 인증서를 쓰는 간단한 Caddyfile 문법을 쓸 수 없음. Caddy에서 작업 중인 걸 알지만 아직은 그렇음
    어쨌든 k8s 환경에서 Traefik을 써봤고 꽤 괜찮았으니 개인용에도 한번 써볼 생각임. 이 말 때문에 Caddy를 시도하지 않는 일은 없었으면 함. Caddy도 실제로 정말 좋음

    • 단일 목적 호스트 같은 데는 Caddy를 쓰지만, 당신이 묘사한 문제에는 100% Traefik을 던질 것임. 실제로 내 k8s 클러스터 인입에 쓰고 있고, 개발 환경에서는 localtest.me를 호스트명과 함께 쓰기 위해 돌리고 있음
      한번 시험해볼 가치가 있음. 둘 다 서로 다른 영역에서 훌륭함
    • 나는 rootless Docker Compose + Traefik을 씀. 와일드카드 인증서가 정말 고통 없이 됐기 때문임. 다만 자체 DNS 서버를 쓰고 Let's Encrypt DNS 챌린지에는 RFC2136 DDNS를 씀
      플러그인은 사실 필요 없음. VM에 이 모든 걸 설정하고 compose 파일 템플릿까지 만드는 Ansible 플레이북 하나가 있고, 서버에서 데이터와 마운트를 제외하고 전부 제거하는 또 다른 플레이북이 있음. 백업은 파일과 여러 DB 등을 여러 위치로 백업할 수 있는 커스텀 스크립트와 restic을 씀
      예전에는 k3s를 배포했지만 셀프호스팅용으로는 너무 과하고 복잡하다는 걸 깨달았음. 나는 그냥 빠르게 배포하고 인증서를 직접 다루지 않으면 됨
    • Caddy는 써보지 않았고 Traefik을 쓰는데, 설정과 TLS 인증서 자동 갱신에 Docker 속성을 발견해서 사용함. 동적 DNS는 잘 모르겠고 Traefik에서 쓰지 않음. 기억하기로는 컨테이너를 추가하거나 제거해도 재시작이 필요 없었음
    • 프로덕션에서 caddy-docker-proxy를 써봤는데, 새 설정을 로드할 때 Caddy가 연결을 끊지 않았음
      방금 로컬에서 확인해봤고 잘 동작함
    • 그건 엄청난 제약임. 설정을 갱신하려고 재시작하면서 연결을 끊어야 하는 역방향 프록시는 처음 들어봄. 보통 그런 서버 설계에서 가장 먼저, 가장 기본적으로 챙기는 부분임

  • Traefik을 많이 써봤지만, 단순히 역방향 프록시 하나 두려고 docker-compose 레이블과 계층, 수많은 줄을 다루는 데 지쳤음. 그러다 Caddy를 발견했고 다시 돌아보지 않음
    아마 나는 Traefik의 대상 사용자가 아니었던 것 같음. 필요한 건 HTTPS가 켜진 역방향 프록시나 기본 인증 계층 정도임. Caddy에서는 둘 다 한 줄이면 되고, 아주 간결하며, 아직도 이해 못 하는 계층도 없음

  • 몇 년 동안 셀프호스팅 전부에 Traefik을 써왔음
    다만 동적 발견과 Docker 레이블 기능은 너무 까다롭고 디버깅이 짜증나서 버렸음
    대신 템플릿 엔진으로 정적 설정 파일을 생성함. 거의 모든 서비스가 host/target/port 조합이라 관련 섹션을 만들기 매우 쉽고, TLS 처리 외에는 복잡한 미들웨어도 없음. 링크된 글의 작성자도 같은 길을 택한 것처럼 보임
    설정은 Ansible 스크립트로 생성한 뒤 Traefik이 실행 중인 머신에 복사하고, Traefik은 그 파일이 있는 디렉터리를 감시하다 변경 시 자동으로 다시 불러옴. 아주 잘 동작해왔음

  • 프로덕션에서 컨테이너와 함께 Traefik을 쓰고 있고, 가장 마음에 드는 점은 설정이 컨테이너 레이블로 실린다는 것임. 그래서 Traefik 설정 자체를 수정할 일이 거의 없음
    가장 큰 단점은 이름을 어떻게 발음해야 하는지 알아내는 것임. 그냥 일반적인 traffic처럼 읽는 것 같지만, 자꾸 “trey-feek” 같은 식으로 부르고 싶어짐

    • 레이블 방식에 크게 동의함. 처음 작성할 때는 이스케이프와 장황함 때문에 조금 더 어렵지만, 추적해야 할 범위가 엄청나게 줄어듦
      Traefik과 Docker Compose 조합은 소규모 셀프호스팅이 k8s로 갈 만큼 커지기 전, 특히 k8s 고가용성 제어 평면이 쓰는 서버 수보다 적은 서버를 가진 경우의 좋은 지점이라고 봄
    • 우리도 프로덕션에서 쓰고 있음. 사람들이 웃을 수도 있지만, 종이에선 멋지고 독특해 보여도 실제로는 끔찍한 이름을 붙이는 건 큰 단점임
      동료들에게 받은 찡그림과 웃음의 양이 엄청났고, 제품 도입과 사용에 방해가 됐음
      우리는 “tray-feek”라고 불렀고 그나마 괜찮았는데, 공식 지원과 통화했더니 일반 “traffic”과 똑같이 발음한다고 하더라. 그래서 그 프록시에 대해 이야기할 때마다 “공개 로드 밸런서로 traffic을 받고, traffic의 네이티브 로드 밸런싱이 traffic을 traffic의 pod로 보낸다” 같은 문장이 됨. 멍청하게 들리는데 실제로 멍청함
    • 그냥 “traffic”이라고 발음함. 저들의 빌어먹을 머리싸움에는 끼지 않겠음
    • 가장 큰 단점은 컨테이너가 존재하지 않거나 실행 중이 아니면 Traefik이 그 컨테이너나 레이블을 모른다는 점이라고 봄
      그렇지 않았다면 유지보수 페이지, 비활성 후 첫 요청에서 컨테이너 올리기 같은 멋진 일을 더 쉽게 할 수 있었을 것임
      그래서 compose 파일을 저장해둔 위치를 알고, 거기서 직접 읽을 수 있는 플러그인을 만들어볼까 생각 중임
    • ae는 y나 hi에 가장 가까움. 그래서 내 추측은 Tryfik이고, 아니면 Trayfik임. 유럽식 fik이면 feek일 수도 있음
답변달기