Motivos para considerar o Traefik mesmo sem usar contêineres
O que se sabe sobre o Traefik
- O Traefik tem como objetivo ajudar no ecossistema de microsserviços
- Muitos YouTubers compartilham que possuem infraestrutura de contêineres como Docker ou Kubernetes
- O Traefik é executado em contêineres e, ao montar o socket do Docker no container do Traefik, consegue detectar automaticamente outros contêineres que devem ser expostos por meio dele
- É possível configurar o comportamento de proxy de contêineres específicos por meio de labels
- O Traefik solicita automaticamente certificados TLS do Let's Encrypt e torna os serviços disponíveis assim que detecta a presença de um novo contêiner
Traefik ainda é útil mesmo sem usar contêineres
Equívoco comum: não é necessário um container engine
- Traefik não precisa ser executado em um container engine, e os serviços também não precisam rodar em um container engine
- O Traefik é escrito em Go e compilado como um único executável
- Encontrar software escrito em Go e compilado em um único binário traz uma sensação realmente boa
- A implantação é simples e mantém controle total
Equívoco comum: há suporte a arquivos de configuração
- Em cenários sem contêineres, não dá para usar labels de contêiner, e essas labels costumam ser confusas e difíceis de ler
- O Traefik também pode ser configurado com arquivos de configuração
- O Traefik divide a configuração em partes "estática" (provedor de certificados, como Let's Encrypt, e entrypoints, ou seja, as portas onde o Traefik fica em escuta) e "dinâmica" (roteadores, serviços e middlewares)
- O Traefik recebe eventos do sistema de arquivos e pode fazer hot reload da parte dinâmica
A documentação é bem feita
- Ele explica claramente todos os conceitos que compõem a base do Traefik
- No início das páginas relacionadas há exemplos de configuração do método de configuração da instância escolhido
- A documentação cobre a maioria das necessidades
- A barra lateral ajuda bastante
O Traefik parece sólido e bem projetado
- O Traefik emite alertas quando a configuração não faz sentido e ainda não apresentou falhas aleatórias
- O Traefik parece não registrar muitos logs por padrão, mas torna fácil entender como as requisições são executadas e começar rapidamente sem frustração
Funcionalidades que realmente chamaram atenção
TLS passthrough e protocolo PROXY
- O Traefik suporta TLS passthrough e o protocolo PROXY do HAProxy (entrada e saída)
- TLS passthrough significa ser capaz de encaminhar tráfego para serviços web que oferecem seus próprios certificados TLS
- É possível solicitar certificados diretamente do Let's Encrypt no próprio serviço sem encerrar o TLS no proxy
- O protocolo PROXY é uma forma mais segura de transmitir informações que podem se perder quando o usuário chega ao proxy primeiro
- O protocolo PROXY também precisa ser suportado pelo serviço de destino; no caso do Apache2 e do Nginx (e, portanto, do PHP), isso já ocorre, e a lista de serviços compatíveis com o protocolo está crescendo
Pontos que ficaram aquém no Traefik
Autenticação
- No NGINX, protegi serviços específicos com Azure AD usando o Vouch Proxy
- O Traefik suporta o ForwardAuth, semelhante à autenticação do NGINX, mas o Vouch Proxy ainda não funciona no Traefik
- É possível implantar uma instância do Keycloak e integrá-la ao AAD antes de usá-la no ForwardAuth, mas essa instância de Keycloak precisa ser configurada antes e mantida segura e atualizada
- O traefik-forward-auth é frequentemente recomendado, mas teve a última atualização em junho de 2020, o desenvolvedor sumiu no GitHub e as dependências precisam ser atualizadas
- No passado, tive uma experiência ruim com o oauth2-proxy
- HTTP/2/3, timeouts, tamanho de corpo e WebSocket exigem configuração em todos os proxies entre usuário e serviço, então fazer proxy para tudo no proxy é muito propenso a erros
- O Traefik ForwardAuth parece simples, então faz sentido desenvolver uma ferramenta simples para integrar com o AAD ou fazer fork do traefik-forward-auth, auditá-lo e depois atualizar dependências
Bloqueio de user agent e endereço IP
- Eu não quero que o archive.org arquive serviços internos
- Como robots.txt e cabeçalhos similares não têm efeito contra o bloqueio do archive.org, a única forma de bloquear crawlers é bloquear o user agent "archive.org_bot" ou bloquear faixas de IP
- No Traefik, é possível bloquear user agents ou endereços IP apenas via plugins de terceiros
- Plugins de terceiros não são preferíveis, pois exigem atenção a atualizações e podem introduzir vulnerabilidades de segurança
- É possível bloquear IPs usando o middleware IPAllowList e permitir tudo, exceto os IPs que você quer bloquear
- É possível calcular faixas de IP e isso não é pior do que bloquear manualmente, mas não permite ver com precisão qual subnet está bloqueada ao olhar apenas o restante, então não parece nada elegante
Opinião do GN+
- O Traefik parece uma solução de proxy reverso interessante, independentemente do uso de contêineres. Em especial, ser escrito em Go e compilado como um único binário torna a implantação e o gerenciamento mais fáceis.
- A documentação também parece boa e deve ajudar bastante a entender os conceitos do Traefik e a encontrar exemplos de configuração.
- Recursos avançados como suporte a TLS passthrough e ao protocolo PROXY também parecem estar bem implementados.
- Na parte de autenticação, porém, ainda não parece haver uma solução satisfatória; parece ser necessário desenvolver um servidor de autenticação próprio ou melhorar um projeto existente.
- Um bloqueio nativo de user agent ou IP seria ideal, mas fora de usar plugins de terceiros não parece haver uma forma elegante.
- O Traefik parece valer a pena ser considerado como alternativa ao NGINX, especialmente para quem acha a configuração do NGINX complexa; para esse perfil, a simplicidade do Traefik pode ser bastante atraente.
1 comentários
Comentários do Hacker News