Traefik, um proxy reverso e balanceador de carga que vale atenção mesmo sem contêineres

• O Traefik é famoso em ambientes de contêineres, mas pode ser implantado como um único executável em Go, permitindo operá-lo como proxy reverso mesmo sem um mecanismo de contêineres
• Em vez de seguir a linha de nginx/caddy/apache2 voltada a servir arquivos, ele é um proxy mais próximo do HAProxy, com foco em encaminhar requisições, devolver respostas e ajustar cabeçalhos
• Mesmo sem usar labels do Docker, ele pode ser configurado com o provider de arquivo, separando configuração estática e dinâmica para gerenciar roteadores, serviços e middlewares
• Suporta TLS Passthrough e entrada/saída do PROXY protocol do HAProxy, mas o PROXY protocol também precisa ser suportado pelo serviço de destino; apache2 e nginx oferecem esse suporte
• Para integração de autenticação e bloqueio por user-agent ou IP, os recursos nativos podem não bastar; é preciso avaliar também a carga de gestão de ForwardAuth, oauth2-proxy e plugins de terceiros

---

Traefik também pode ser usado fora de contêineres

• Nos últimos anos, o Traefik ganhou popularidade no universo de vídeos de home lab no YouTube e costuma ser apresentado junto com infraestrutura de contêineres como Docker ou Kubernetes
• Em termos de funcionalidade, ele é mais próximo do HAProxy do que de nginx/caddy/apache2
  • Encaminha requisições para serviços e devolve as respostas
  • Pode modificar cabeçalhos e partes da requisição e da resposta
  • Não oferece suporte a servir arquivos
• Em ambientes de contêineres, o próprio Traefik também pode rodar em contêiner e montar o socket do Docker para detectar automaticamente outros contêineres
  • O comportamento do proxy pode ser configurado por meio de labels do Docker nos contêineres
  • Ao detectar um novo contêiner, ele pode solicitar automaticamente certificados TLS do Let’s Encrypt e expor o serviço

Binário único e implantação com systemd

• O Traefik é escrito em Go e compilado como um arquivo executável único
• A distribuição binária pode ser obtida na documentação de instalação do Traefik
• É possível executar tanto o próprio Traefik quanto os serviços de destino sem nenhum mecanismo de contêineres
• Há um exemplo de unit de serviço systemd no repositório do Traefik
• Em operação real, além do arquivo de configuração, também é necessário criar um usuário dedicado e ajustar as permissões do arquivo de configuração

Configuração baseada em arquivo

• Sem contêineres, não é possível usar labels do Docker, mas o Traefik pode ser configurado com o provider de arquivo
• A configuração se divide em duas grandes partes
  • Configuração estática: define provedores de certificado como Let’s Encrypt e os entrypoints, isto é, as portas em que o Traefik escuta
  • Configuração dinâmica: define roteadores, serviços e middlewares
• O Traefik consegue detectar eventos no sistema de arquivos e fazer hot reload da configuração dinâmica
• A documentação fornece os conceitos principais e exemplos de configuração para cada forma de uso
• Termos como certificate provider, entrypoint, router, service e middleware podem ser consultados rapidamente na documentação do Traefik

Comportamento após a configuração e depuração

• Quando a configuração está incorreta, o Traefik exibe avisos
• O log padrão não é muito verboso, mas facilita entender por qual caminho cada requisição passou
• Há relato de uso dizendo que a configuração inicial foi concluída rapidamente e que não houve problemas inesperados

TLS Passthrough e PROXY protocol

• O Traefik oferece suporte a TLS Passthrough
  • O proxy pode encaminhar o tráfego para um serviço web que fornece seu próprio certificado TLS, sem encerrar o TLS no próprio proxy
  • Também é possível montar uma configuração em que o serviço solicita diretamente um certificado do Let’s Encrypt mesmo passando pelo Traefik
  • O proxy não consegue ver o conteúdo que está sendo encaminhado
• Em hospedagem virtual comum, a escolha do host é feita pelo cabeçalho HTTP Host, mas no TLS Passthrough esse cabeçalho fica dentro do conteúdo criptografado e não pode ser usado
• O host de destino é escolhido pelo SNI (Server Name Indication) do TLS, abordagem usada pelo Traefik e por vários servidores web e proxies
• Também há suporte a entrada e saída do PROXY protocol do HAProxy
  • É uma forma de repassar ao serviço de destino informações que se perdem quando o usuário chega primeiro ao proxy
  • É considerado mais fácil de tratar com segurança do que os cabeçalhos X-Forwarded-... tradicionais
  • O serviço de destino também precisa suportar PROXY protocol
  • apache2 e nginx suportam esse recurso, e a lista de serviços compatíveis vem crescendo

Limitações que ainda incomodam na integração de autenticação

• No nginx, é possível usar o Vouch Proxy para proteger alguns serviços com Azure AD, hoje chamado de autenticação Microsoft Entra
• O Traefik suporta ForwardAuth, semelhante ao mecanismo de autenticação do nginx
• O Vouch Proxy ainda não funciona com o Traefik, e há uma issue aberta sobre isso
• É possível operar uma instância própria do Keycloak e integrá-la ao AAD para uso com ForwardAuth, mas a configuração inicial e a carga de manter segurança e atualizações são altas
• O traefik-forward-auth é frequentemente recomendado, mas a última atualização foi em junho de 2020 e seriam necessárias atualizações de dependências, o que levou à conclusão de que ele é difícil de adotar
• O oauth2-proxy deixou uma impressão ruim em experiências anteriores, e colocar mais um proxy atrás de outro aumenta a chance de erros, porque HTTP/2·HTTP/3, timeout, tamanho de corpo e configuração de WebSocket precisam ser ajustados em cada proxy intermediário
• Segundo a atualização de 2024-05-06, o oauth2-proxy também pode ser integrado por HTTP API
  • Suporta auth_request do nginx
  • Suporta ForwardAuth do Traefik
  • Essa abordagem parece mais próxima da configuração desejada

Bloqueio por user-agent e IP

• Há casos em que não se deseja que serviços internos sejam arquivados pelo archive.org
• robots.txt e cabeçalhos semelhantes não funcionam para bloquear o Archive.org; as formas de bloquear crawlers são barrar o user-agent archive.org_bot ou bloquear faixas de IP
• Para bloquear user-agent ou endereço IP no Traefik, é necessário usar plugins de terceiros, não recursos nativos
  • Plugin para bloquear user-agent
  • Plugin deny IP
• Plugins de terceiros exigem atenção a cada atualização e podem introduzir vulnerabilidades de segurança, por isso não são preferidos
• Também é possível usar o middleware IPAllowList para permitir tudo, exceto os IPs que se deseja bloquear
  • Também é possível calcular faixas de IP
  • Não é pior do que bloquear diretamente, mas não é elegante, porque ao olhar apenas para as sub-redes restantes fica difícil entender quais faixas foram bloqueadas

Exemplo de organização da configuração

• O exemplo divide a configuração entre /etc/traefik/traefik.yml e /etc/traefik/dynamic.yml
• A configuração estática define o seguinte
  • entrypoints :80 e :443
  • Redirecionamento de todo endpoint HTTP para HTTPS sem exceções
  • Emissão de certificados Let’s Encrypt usando TLS challenge
  • Monitoramento do arquivo de configuração dinâmica /etc/traefik/dynamic.yml
• A configuração dinâmica inclui o seguinte
  • Roteamento TCP com TLS Passthrough para cloud.xx.xyz
  • Encaminhamento para o serviço 10.33.1.2:4433 em outro host
  • Ativação do PROXY protocol version 2
  • Para git.xx.xyz, encerramento de TLS e proxy para http://127.0.0.1:3000
  • Middleware que redireciona https://xx.xyz/redirmepls para https://google.com
  • Middleware que adiciona o cabeçalho X-Robots-Tag: noindex, nofollow, nosnippet, noarchive

[GN⁺]

Comentários do Hacker News

• O Traefik é bem bom, mas sofre de um problema terrível parecido com o do Ansible. Tem muita documentação e muitos textos, mas você não consegue encontrar o que precisa
  Eu uso desde a v1 e, mesmo assim, frequentemente me perco na documentação e fico bem frustrado. Para projetos pequenos, acabo usando o Caddy, porque a documentação não é tão ruim quanto a do Traefik
  Falando com redatores de documentação técnica: documentação centrada em exemplos só é boa para iniciantes que estão dando uma olhada. Para quem já conhece o produto, o que se precisa é de documentação de referência e listas completas, não descrições de campos espalhadas por 10 páginas de tutorial. Não foquem só no processo de onboarding; é preciso pensar em quem usa o produto todos os dias
  Essa é a parte que mais me incomoda, o motivo de eu ter passado a detestar tanto o Ansible, e o Traefik é parecido, embora em menor grau

  • Concordo. Acho que frameworks de documentação como https://diataxis.fr serem mais conhecidos ajudaria todo mundo
  • Algo que me irritou recentemente nessa categoria foi o OpenTelemetry. Existem milhares de páginas, mas quase nada sobre como realmente alcançar fluxos de trabalho básicos e comuns
  • Um dos problemas desse tipo de coisa que dá para chamar de linguagem baseada em interpretador de YAML é que o próprio YAML é a linguagem, mas a documentação do interpretador em geral não documenta essa parte
    Parte-se da suposição de que você só vai fazer tarefas muito simples em estruturas de dados bem planas, mas a maior parte da realidade não é assim. Para usar esse tipo de linguagem direito, você precisa entender todo um conjunto de regras implícitas sobre como escrever YAML, mas a documentação quase nunca toca nisso
    Existe documentação da configuração específica de cada módulo, mas quase nunca fica claro como usar a configuração padrão, como lidar com os dados retornados ou combiná-los com algo minimamente mais complexo. A sensação é de jogarem uma dúzia de exemplos de um parágrafo para cada item como um monte de ingredientes e mandarem você assar um bolo
    Tive praticamente a mesma experiência em vários sistemas de interpretador de YAML que usei; só consegui fazer as coisas depois de passar por centenas de milhares de linhas de YAML, mas a documentação tinha pouco valor além de uma lista de configurações
  • O Ansible realmente faz você ficar consultando a documentação o tempo todo
    Ainda assim, encontrei um fluxo de trabalho bem razoável usando ansible-doc, e meus aliases mais usados são alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'
    Primeiro faço uma busca rápida por comandos relacionados com adls, depois consulto a documentação com ad e quase sempre pulo direto para o fim (G) para ver os exemplos. Normalmente a resposta de que preciso está ali
    Escrever scripts de Ansible depende muito da documentação, então acho que, no estado padrão, ele deveria dar mais suporte a esse processo de consulta e oferecer uma interface em que fosse rápido encontrar as coisas sem precisar criar um monte de aliases
  • Para mim, o Pydantic também entra nessa categoria. Os mantenedores acham que deve haver uma única fonte de informação e se recusam a criar documentação de referência da API
    Claro, o projeto é deles, mas ter que vasculhar páginas longas de prosa toda vez que se quer encontrar um método de um objeto é complicado. Às vezes, é mais fácil simplesmente ler o código-fonte

• Usei o Traefik em produção por 2 anos. Antes usava NGINX, mas decidi migrar para o Traefik por causa da integração automática com Let's Encrypt e me arrependo dessa decisão
  A documentação do Traefik não faz muito sentido para mim e para a minha equipe. É complicada e se comporta de forma estranha, sem logs decentes
  Por exemplo, quando tenta recriar certificados, falha de forma intermitente e a produção cai sem que se saiba quando vai se recuperar. Estou voltando para o NGINX

  • Nisso o NixOS ajudou muito. Dá para configurar adicionando só algumas linhas em configuration.nix, e por baixo ele usa lego(1) e letsencrypt
    security.acme = { acceptTerms = true; defaults.email = "[e-mail]"; 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"; };
    Configurar com nginx provavelmente seria bem parecido. https://github.com/go-acme/lego
  • Eu também migrei do NGINX para o Traefik por causa do suporte nativo a desafio DNS e certificados curinga. Passei horas tentando aplicar isso ao domínio usado na empresa e, mesmo usando a mesma configuração que funciona perfeitamente em casa, na prática não acontecia absolutamente nada
    Era o mesmo registrador de domínio, a mesma API, a mesma configuração de Docker, e eu também ativei todos os logs, mas não havia nenhuma informação sobre por que o certificado não estava sendo criado. Simplesmente voltava para o certificado padrão gerado, como se nem tivesse tentado
    Depois de duas sessões de troubleshooting e várias horas de busca, desisti e não tive opção além de usar um arquivo de certificado autoassinado. É muito frustrante não ter informação nenhuma sobre o motivo, falhar em silêncio e depois partir para um comportamento alternativo
    No geral, esse foi o maior problema do Traefik. Quando funciona, é excelente, mas quando não funciona, sempre foi difícil resolver o problema ou encontrar na documentação a informação necessária. A empresa deve começar a usar Traefik em produção no fim do ano, então espero me familiarizar mais com o Traefik antes disso
  • Quando preciso de um API gateway, simplesmente tenho usado o proxy reverso nativo do Go. Dá para adaptar facilmente ao formato necessário, e também é fácil encontrar bibliotecas para tarefas comuns como CORS, limitação de requisições e retries
    O melhor é que não existe linguagem de configuração. É só usar Go
  • Talvez você já saiba disso, e talvez não se encaixe no seu caso, mas há vários contêineres auxiliares de Docker para automatizar certificados Let's Encrypt para contêineres Docker do nginx
  • Tive muitos problemas parecidos quando comecei a usar o Traefik. Por exemplo, eu usava validação TLS-01, e se os registros DNS não estivessem preparados antes de aplicar a configuração, isso gerava um estresse enorme. Também me lembro de ter me frustrado com a falta de volume de logs
    Depois descobri que, se o DNS não estiver configurado corretamente, após N tentativas de validação fracassadas o Let's Encrypt passa a recusar novamente a validação TLS-01 por um tempo, e o problema que você enfrentou parece ser desse tipo
    Depois que migrei para a validação DNS-01, a experiência melhorou de repente e muito. Também dá para gerar certificados para serviços não expostos publicamente, e a orquestração necessária é bem menor do que com TLS-01
    Se o provedor de DNS for decente, mesmo quando há problema é mais provável receber um erro de API antes que o Let's Encrypt tente validar o registro, e o estado de falha acontece muito antes do recuo por falha de verificação do Let's Encrypt. Agora estou praticamente decidido a usar só validação baseada em DNS-01 com Let's Encrypt, seja com Traefik, Caddy, Nginx ou outro proxy reverso, e se eu tiver de usar TLS-01, vou sempre conferir desde o início com a API de Staging se está tudo ajustado corretamente
    Como observação, quando o Traefik cria um certificado de Staging do Let's Encrypt, não há uma boa forma de invalidar esse certificado. É preciso mexer no ACME JSON para remover o certificado e reiniciar o Traefik para refletir a mudança. Talvez dê com SIGHUP, mas nunca tentei
    No geral há muitas falhas silenciosas e comportamentos estranhos, mas a maior dor é tornar opacos os erros dos serviços dos quais ele depende

• Em vez de Traefik, uso Caddy. Para mim, é muito mais fácil gerenciar um Caddyfile do que a configuração em YAML do Traefik, e mantenho Caddyfiles separados para deploy local, produção e on-premises
  Também há muitos plugins excelentes, e usamos o plugin WAF coraza para Caddy, que funciona bem

  • Num setup self-hosted, migrei do Traefik para Caddy e caddy-docker-proxy
    Tem tudo de que eu precisava e é muito mais simples
    https://github.com/lucaslorentz/caddy-docker-proxy
  • Gosto do Caddy, mas gostaria que a documentação de deploy em produção também melhorasse. Especialmente em relação a armazenamento e gerenciamento de configuração, há perguntas demais sem resposta sobre boas práticas
    Coisas como como lidar com armazenamento local ao usar armazenamento externo. Dizem que pode ser tratado como stateless, mas talvez não seja
    No fim, você só pode torcer para que a pessoa que criou o módulo necessário saiba realmente o que está fazendo. Também não existe padrão de documentação por lá. Os mantenedores precisam impor limites a módulos aleatórios que oferecem funcionalidade central sem documentação nenhuma, como um backend de armazenamento S3
  • Se você não precisa de brincadeiras complexas como descoberta de serviço ou escalonamento automático, ou consegue lidar com isso por conta própria com scripts, pode pular felizmente Traefik, Docker Swarm, Kubernetes etc. e simplesmente usar Caddy. O Caddy realmente consegue fazer a maior parte das coisas, e faz bem

• Se a necessidade for modesta, como alguns hosts Docker e algumas dezenas de contêineres, fico me perguntando qual seria o motivo para usar Traefik em vez de nginx. Eu uso https://github.com/NginxProxyManager/nginx-proxy-manager; será que o Traefik traz alguma vantagem nessa escala pequena?

  • Aqui eu diria que https://github.com/caddyserver é a melhor opção. Ele cuida automaticamente dos certificados SSL, é muito leve e a sintaxe de configuração é extremamente clara
  • Gosto do hot reload do Traefik. Se você quiser ocultar um serviço, ou seja, o app que está sendo proxyado, adicionar uma nova rota — ou, na terminologia do Traefik, um router — ou incluir middlewares como autenticação básica, redirecionamento para HTTPS ou manipulação de headers, basta soltar um arquivo e tudo é aplicado automaticamente. Não precisa recarregar o Traefik nem seus hosts virtuais
    Também tem o fato de que eu não gosto da sintaxe do nginx e o Traefik me pareceu mais atraente. Entrei por causa da renovação do Let's Encrypt e dos contêineres, e continuei usando por causa da forma de configurar
  • Se a configuração que você já tem funciona bem, não vejo vantagem em trocar só por trocar
    Acho que eu só consideraria migrar no momento em que passasse a precisar de algum recurso que o Traefik oferece e o Nginx não
  • Eu também uso NginxProxyManager e tenho 8 hosts, mas ainda não vi uma resposta que explique quais vantagens caddyserver ou traefik trazem em relação ao NPM
  • Concordo. A configuração do Nginx é simples, e depois que você acerta uma vez pode simplesmente esquecer. No fim das contas, na maioria dos casos as pessoas só copiam e colam de outra configuração que já têm
    Também acho meio estranho que Let's Encrypt automático seja tratado como ponto de venda, já que o Certbot está em todo lugar e cobre mais cenários. Para mim, os pontos de venda do Traefik e do Caddy não convencem muito, porque eles não tornam isso mais fácil do que alternativas já amplamente suportadas

• Há algumas semanas eu estava escolhendo um proxy reverso e acabei optando pelo Caddy por causa da simplicidade. Ainda assim, a descoberta automática de contêineres e a referência a labels do Traefik são bem legais, e o Caddy também tem um plugin que faz a mesma coisa
  Li o artigo, mas ainda não estou convencido de que o Traefik seja melhor para mim do que o Caddy. Pode ser que seja para outras pessoas, então gostaria de ouvir opiniões

• Também vale destacar que o Traefik vem configurado por padrão no K3s. Graças a isso, o K3s virou a forma mais rápida de subir um cluster K8s para testes, e também permite tratar o cluster como gado
  Basta adicionar o deployment e os serviços relacionados como NodePort, e você consegue acessar o app sem se preocupar com o controlador de ingress
  Eu subo clusters K3s com um script de shell e testo, quando preciso, o app indicado como argumento posicional. Nisso eu aproveito o registro temporário de contêineres do ttl.sh. Quando o mesmo script termina, o cluster também é removido

• Estou pensando em migrar meu proxy reverso de self-hosting para o Traefik. Diferente do autor, eu rodo workloads conteinerizados com Docker Compose e hoje uso Caddy junto com o excelente plugin caddy-docker-proxy
  O que tenho hoje é um proxy reverso configurado por labels do Docker, detecção automática de novos workloads, certificados TLS e configuração automática de DNS por meio do plugin caddy-dynamicdns. Mesmo que o provedor me dê outro IP, não preciso me preocupar muito em perder acesso
  Só que, toda vez que um novo workload é adicionado ou reiniciado, o Caddy inteiro reinicia e o acesso cai temporariamente. O Caddy não consegue transferir as conexões existentes para a nova instância
  Além disso, usar certificados wildcard ainda não é simples o bastante. Eu uso wildcard porque não quero que todos os workloads fiquem expostos ao mundo pelos logs de transparência de certificados, mas aí não dá para usar a sintaxe simples do Caddyfile com um certificado por hostname. Sei que isso está sendo trabalhado no Caddy, mas por enquanto ainda é assim
  De qualquer forma, já usei Traefik em ambiente k8s e achei bem bom, então estou pensando em experimentar também no uso pessoal. Só não queria que isso desencorajasse alguém de testar o Caddy. O Caddy também é realmente muito bom

  • Eu uso Caddy em coisas como hosts de propósito único, mas para o problema que você descreveu eu colocaria Traefik sem pensar duas vezes. Na prática, eu o uso na entrada do meu cluster k8s e também no ambiente de desenvolvimento, para usar localtest.me junto com hostnames
    Vale a pena testar. Os dois são excelentes, cada um em uma área diferente
  • Eu uso Docker Compose rootless + Traefik. Foi porque os certificados wildcard ficaram realmente sem dor de cabeça. Só que eu uso meu próprio servidor DNS e, para o desafio DNS do Let's Encrypt, uso RFC2136 DDNS
    Na verdade, nem preciso de plugin. Tenho um playbook Ansible que configura tudo isso na VM e até cria os templates dos arquivos compose, e outro playbook que remove tudo do servidor, exceto os dados e os mounts. Para backup, uso scripts personalizados e restic para salvar arquivos, vários bancos de dados etc. em vários lugares
    Eu costumava implantar k3s, mas percebi que para self-hosting ele é exagerado e complexo demais. Eu só preciso implantar rápido e não lidar manualmente com certificados
  • Nunca usei Caddy; uso Traefik e descobri que ele aproveita propriedades do Docker para configuração e renovação automática de certificados TLS. Não sei muito sobre DNS dinâmico e não uso isso no Traefik. Pelo que me lembro, adicionar ou remover contêineres não exigia reinício
  • Já usei caddy-docker-proxy em produção, e o Caddy não derrubava conexões ao carregar uma nova configuração
    Acabei de verificar localmente e está funcionando bem
  • Isso é uma limitação enorme. É a primeira vez que ouço falar de um proxy reverso que precisa reiniciar e derrubar conexões para atualizar a configuração. Normalmente, esse é um dos primeiros e mais básicos pontos considerados nesse tipo de projeto de servidor

• Usei bastante Traefik, mas cansei de lidar com labels do docker-compose, camadas e um monte de linhas só para ter um único proxy reverso. Aí descobri o Caddy e nunca mais olhei para trás
  Acho que talvez eu não fosse o público-alvo do Traefik. Tudo o que preciso é de um proxy reverso com HTTPS ativado ou talvez uma camada de autenticação básica. No Caddy, os dois cabem em uma linha, ficam super concisos e não existem camadas que eu ainda não entendo

• Há anos uso o Traefik para tudo no meu self-hosting
  Mas abandonei a descoberta dinâmica e os recursos de labels do Docker porque eram complicados demais e um saco de depurar
  Em vez disso, gero arquivos de configuração estáticos com um mecanismo de templates. Quase todos os serviços seguem uma combinação de host/target/port, então é muito fácil criar as seções relacionadas, e fora o tratamento de TLS também não há middleware complexo. O autor do texto linkado parece ter seguido o mesmo caminho
  A configuração é gerada com scripts do Ansible, depois copiada para a máquina onde o Traefik roda, e o Traefik monitora o diretório onde esses arquivos ficam e recarrega automaticamente quando há mudanças. Tem funcionado muito bem

• Uso o Traefik em produção junto com contêineres, e o que eu mais gosto é que a configuração vai nas labels dos contêineres. Então quase nunca preciso mexer na configuração do próprio Traefik
  A maior desvantagem é descobrir como diabos pronunciar o nome. Parece que se lê como o traffic normal, mas eu fico querendo chamar de algo como “trey-feek”

  • Concordo muito com a abordagem de labels. Na hora de escrever pela primeira vez é um pouco mais difícil por causa do escape e da verbosidade, mas reduz absurdamente a área que você precisa rastrear
    Vejo a combinação de Traefik com Docker Compose como um ótimo ponto para self-hosting de pequeno porte antes de crescer o bastante para ir para k8s, especialmente quando você tem menos servidores do que a quantidade que um control plane de alta disponibilidade do k8s costuma usar
  • Nós também usamos em produção. As pessoas podem rir, mas dar um nome horrível na prática, mesmo que no papel pareça legal e único, é uma grande desvantagem
    A quantidade de caretas e risadas que recebi dos colegas foi enorme, e isso atrapalhou a adoção e o uso do produto
    Nós chamávamos de “tray-feek”, o que ainda era aceitável, mas quando ligamos para o suporte oficial disseram que a pronúncia é exatamente igual à de “traffic” normal. Aí toda vez que você fala desse proxy saem frases do tipo “o traffic entra pelo load balancer público, e o balanceamento nativo do traffic manda o traffic para os pods do traffic”. Soa idiota, porque é idiota mesmo
  • Eu simplesmente pronuncio “traffic”. Não vou entrar nessa briguinha idiota deles
  • Acho que a maior desvantagem é que, se o contêiner não existe ou não está rodando, o Traefik não sabe nada sobre aquele contêiner nem sobre as labels dele
    Se não fosse assim, seria mais fácil fazer coisas legais como página de manutenção ou subir o contêiner no primeiro request depois de ficar inativo
    Por isso estou pensando em criar um plugin que saiba onde os arquivos do compose ficam salvos e consiga ler direto dali
  • ae é o mais próximo de y ou hi. Então meu palpite é Tryfik, ou então Trayfik. Se o fik for europeu, talvez seja feek também