Kamal Proxy, o proxy HTTP mínimo para deploy com zero downtime

Kamal Proxy - suporte a deploy sem interrupção com um proxy HTTP mínimo

Recursos

• Kamal Proxy é um proxy HTTP projetado para coordenar facilmente deploys sem downtime
• Ao executar uma aplicação web atrás do Kamal Proxy, é possível publicar mudanças sem interromper o tráfego em andamento
• Funciona sem exigir cooperação especial da aplicação
• Foi projetado como parte do Kamal, mas pode ser usado de forma independente ou com outras ferramentas de deploy

Visão geral rápida

• Para executar uma instância do proxy, use o comando kamal-proxy run
• Não há arquivo de configuração, mas é possível especificar opções se os padrões não forem adequados para a aplicação
• Por exemplo, para executar o proxy em uma porta diferente da porta padrão 80: kamal-proxy run --http-port 8080
• Para ver a lista completa de opções, execute kamal-proxy help run

Roteamento de tráfego

• Para rotear o tráfego para uma aplicação web por meio do proxy, faça o deploy de uma instância da aplicação no proxy
• Quando uma instância é implantada, ela fica disponível para uso pelo proxy e substitui a instância usada anteriormente
• Ao especificar uma instância, use o formato hostname:port
• Por exemplo: kamal-proxy deploy service1 --target web-1:3000
• O proxy registra web-1:3000 com o nome de serviço service1 e inicia imediatamente as verificações de saúde HTTP
• Se a instância não ficar saudável dentro de um determinado tempo, o comando deploy interrompe a implantação e retorna um código de saída de erro
• Cada deploy assume todo o tráfego da instância implantada anteriormente
• Quando a nova instância fica saudável, todo o novo tráfego é roteado para ela
• O comando deploy espera até que o tráfego da instância anterior seja totalmente drenado
• Portanto, quando deploy retorna com sucesso, a instância anterior pode ser removida sem interromper as requisições em andamento
• O tráfego não é roteado até que a nova instância fique saudável, e a instância anterior só é removida depois que todo o tráfego for totalmente drenado, tornando possível o deploy sem interrupção

Roteamento baseado em host

• O roteamento baseado em host permite executar várias aplicações no mesmo servidor
• Ao implantar uma instância, é possível especificar o host que atenderá o tráfego
• Por exemplo: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com
• Uma instância implantada dessa forma recebe tráfego apenas para o host especificado
• Ao implantar uma instância exclusiva para cada host, é possível executar várias aplicações no mesmo servidor sem conflito de portas
• Um host específico só pode rotear um serviço por vez
• Por exemplo: após executar kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com, executar kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com gera erro
• Após kamal-proxy remove service1, executar kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com terá sucesso

TLS automático

• Kamal Proxy pode obter e renovar automaticamente certificados TLS para aplicações
• Isso pode ser ativado adicionando a flag --tls ao implantar uma instância
• Por exemplo: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com --tls

Definindo opções de run com variáveis de ambiente

• Em ambientes como ao executar dentro de um contêiner Docker, pode ser conveniente usar variáveis de ambiente para definir opções de run
• Por exemplo, para definir a porta HTTP: kamal-proxy run --http-port 8080 ou HTTP_PORT=8080 kamal-proxy run
• Se houver conflito entre variáveis de ambiente e outras configurações, é possível diferenciá-las com o prefixo KAMAL_PROXY_
• Por exemplo: KAMAL_PROXY_HTTP_PORT=8080 kamal-proxy run

Build

• Se o ambiente Go estiver configurado, é possível compilar o Kamal Proxy localmente: make
• Ou compilá-lo com um contêiner Docker: make docker

Teste

• É possível experimentar os comandos do proxy verificando a configuração do Docker Compose na pasta de exemplos

Resumo do GN⁺

• Kamal Proxy é um proxy HTTP mínimo que oferece suporte a deploy sem interrupção e funciona sem exigir cooperação especial da aplicação
• Ele oferece roteamento baseado em host e TLS automático, permitindo executar várias aplicações no mesmo servidor
• As opções de run podem ser definidas com variáveis de ambiente, o que é útil em ambientes como Docker
• Para deploy sem interrupção, ele roteia o tráfego para a nova instância e espera até que o tráfego da instância anterior seja totalmente drenado
• Projetos com funcionalidade semelhante incluem NGINX e HAProxy

[GN⁺]

Comentários do Hacker News

• O uso do termo 'deploy' é confuso

  • Termos como 'bind', 'intercept' e 'proxy' parecem mais apropriados

• Construir um sistema inteiro para deploy sem downtime é um exagero

  • Também é possível fazer deploy sem downtime com um app + proxy web que suporte sockets Unix

• O proxy do Kamal existe para resolver problemas do Docker Swarm

  • No Cloud 66, usavam Caddy e Traefik

• Fica a dúvida sobre por que o Kamal escolheu o Swarm

  • Pode ter sido por simplicidade
  • A complexidade não pode ser escondida e, no fim, acabam criando o próprio proxy

• Não usei o proxy do Kamal, mas sou cético por causa das questões de suporte

  • É preciso suporte a WebSockets, SSE, HTTP/3, vários tipos de compressão e criptografia

• Parece o tipo de coisa que o HAProxy faz facilmente

  • Ele tem recurso de hitless reload

• Fica a dúvida se isso implementa o padrão de 'pausa temporária de tráfego'

  • Dá para pausar o tráfego por alguns segundos e fazer mudanças na infraestrutura

• Fica a dúvida sobre como o deploy sem downtime (ZDD) funciona

  • Duas versões do app rodam ao mesmo tempo, e o novo tráfego é roteado para a nova versão
  • Como será que lidam com o problema das migrações de banco de dados?

• O Kamal 2 vai suportar auto-SSL e facilitar a execução de vários apps em um único servidor

• Não ficou claro como usar

  • Pelo exemplo, ele inicia 4 réplicas do serviço 'web'
  • Para deploy sem downtime, seria preciso fazer deploy para um novo target
  • O comando docker compose up --build --force-recreate web invalida tudo isso
  • São necessárias instruções mais claras

• Fica a dúvida se existe alguma forma de configurar timeouts

• É síndrome de NIH (Not Invented Here)