Estou tentando configurar o Traefik em um site de produção e estou enfrentando alguns problemas de alta disponibilidade. Acho que ainda precisamos de um proxy reverso na frente do cluster Traefik. Aqui estão as configurações potenciais que considerei e por que o proxy reverso parece ser necessário:
Configure os registros DNS A para apontar para cada um dos nós do Traefik para balanceamento de carga e failover.
Esta prática é desencorajada de acordo com vários sites, incluindo esta pergunta SO e esta pergunta SF .
Mesmo o uso de um serviço como DNSMadeEasy parece ser desencorajado devido a problemas de cache de DNS e TTL.
Aponte um registro DNS para um dos nós que executam o Traefik.
Esse nó se torna um SPOF. Meus nós estão sendo executados no CoreOS, que reinicia após cada atualização, então teríamos alguns minutos de inatividade por semana.
Poderíamos mover o registro DNS para um nó alternativo sempre que o tempo de inatividade for esperado. Isso seria uma dor de gerenciar manualmente. Eu posso imaginar uma solução emparelhada com o serralheiro que lide com isso automaticamente, mas eu realmente não quero construí-la e ela não lidaria com o tempo de inatividade inesperado.
Parte do raciocínio para usar o Docker Swarm (ou Kubernetes) é tornar os nós intercambiáveis.
Coloque um balanceador de carga/proxy reverso na frente do cluster Traefik. O proxy reverso pode fornecer failover entre todos os nós do Traefik e o DNS apontaria para o proxy reverso.
- Sim, este é um SPOF, mas na minha experiência, é muito fácil obter um bom tempo de atividade com essa configuração. Se for necessária manutenção ocasional, o registro DNS pode ser apontado para um novo proxy.
Estou faltando alguma coisa ou pensando demais nisso?
existem diferentes tipos de soluções.
1) Crie seu próprio balanceador de carga de alta disponibilidade na frente de seu cluster Swarm/Kubernetes para distribuir o tráfego e realizar failover.
Há muitos aparelhos diferentes por aí:
Embora essa abordagem seja HA, geralmente não é barata.
Uma alternativa mais barata para isso pode ser uma configuração Nginx/Haproxy + Keepalived .
No entanto, é claro que você precisa de um IP flutuante e precisa cuidar dos caches arp.
2) Use um "Cloud Loadbalancer". Digital Ocean, AWS, GKE, Openstack fornecem esse recurso. É mais fácil de configurar (na maioria das vezes), mas se for mais barato você tem que calcular.
Na DigitalOcean, o LB custa apenas 20$ e há um Beta com um cluster Kubernetes gerenciado. Você pode querer dar uma olhada nele. Todos os componentes se conectam bem https://www.digitalocean.com/products/kubernetes/
3) Se seus aplicativos não são 100% críticos, posso sugerir uma solução especial que usei até agora:
Cloudflare + TTL baixo + https://github.com/Berndinox/cloudflare-ddns
Funciona tão simples: https://github.com/Berndinox/compose-v3-collection/blob/master/wordpress/www.yml Como: Ele ativa o WordPress e todos os seus requisitos, incluindo o DNS Container. O Contêiner DNS está Atualizando o Registro DNS do Domínio na Cloudflare (Depende de qual host o contêiner inicia, o IP é diferente). Bom, se um Host for reinicializado ou a verificação de integridade do contêiner falhar, o contêiner será reprogramado. Ao ser reagendado e o Host inicialmente colocado estiver offline, o container iniciará em outro host e então enviará o novo IP para a Cloudflare. Isso tudo acontece automaticamente sem fazer nada. :)
Os TTLs da Cloudflare são realmente baixos, portanto, pode haver apenas alguns segundos de inatividade.
Se você quiser 'rolar sua própria' camada HA em cima do Traefik, posso sugerir um ângulo ligeiramente diferente. Eu uso Netscalers (renomeado como 'ADC' pela Citrix) no meu trabalho diário, e minha sugestão é fazer o Traefix agir como um ADC... se você conseguir fazer isso. no mundo ADC, isso seria um 'par de HA de braço único' e *deveria operar como ativo-passivo (não ativo-ativo).
Configure mais de uma instância do Traefik, com IPs diferentes. Para o meu exemplo, eu uso 10.0.1.11 e 10.0.1.12. Esses IPs devem ser usados para qualquer patch de SO, ou qualquer outra coisa *exceto o tráfego de proxy reverso. Em um ADC, essas são as entradas NSIP.
Configure uma segunda interface de rede (IF) em cada instância de um terceiro IP 'flutuante'. Para o meu exemplo, eu uso 10.0.1.10. Em um ADC, isso seria um SNIP. *certifique-se de que este IF permaneça inativo durante a configuração ou você terá conflitos de endereço IP. Configure também este IF para *não iniciar automaticamente na inicialização. Configure o Traefik para usar apenas este IP para tráfego de proxy reverso.
Em seguida, você precisa descobrir como manter a configuração das instâncias 'em sincronia'. Sou um pouco novo no Traefik, então não tenho certeza sobre isso ... mas se o Traefik se comportar bem com ele, use um compartilhamento NFS para armazenar a configuração em um local, montado em todos os nós. Monte o NFS no local correto ou use soft links. Se o Traefik não se comportar bem com isso (ou se você não tiver um bom NFS), talvez armazene a configuração em um repositório git e use scripts para sincronizá-los... ou use rsyc... ou (Ansible|Puppet|salt |etc)... ou... ou... claramente mais trabalho é necessário aqui. Você pode precisar de scripts de reinicialização de serviços quando a configuração for atualizada... não tenho certeza. Isso claramente precisaria ser feito com cuidado para que todos os nós não reiniciem os serviços ao mesmo tempo.
Agora configure a pilha Corosync para gerenciar qual instância está 'ativada'. A pilha Corosync pode ser configurada para manter o IF com o 'IP flutuante' 10.0.1.10 disponível em apenas uma instância e gerenciar o início e a interrupção de serviços em todas as instâncias. O estado 'normal' de todos os serviços precisa estar 'up', exceto o IF. Dessa forma, há pouca interrupção se a pilha Corosync precisar 'descer' o IF em uma instância e 'aumentar' o IF em outra. Adapte estas instruções: https://www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-setup-with-corosync-pacemaker-and-floating-ips-on-ubuntu-14- 04
Por último, coloque sua entrada DNS para apontar para o 'IP flutuante' 10.0.1.10.
O resultado é que você *deve ser capaz de gerenciar as instâncias, sincronizar as configurações e corrigir o SO nos IPs 10.0.1.11 e 10.0.1.12, enquanto apenas uma instância sempre tem o IP 10.0.1.10 disponível para gerenciar o proxy reverso tráfego.
Estou pensando em configurar algo assim, e fornecerei atualizações se o fizer.
Ou faça como Berndinox sugeriu e pague para ter algo que você não precisa projetar, algo que você sabe que funcionará. Os ADCs funcionam muito bem na minha experiência.