Contêineres de carga da maratona balanceados com o Haproxy e o cônsul devolve pedidos aleatórios de 503

Question

Atualmente a arquitetura é organizada assim:

• 192.168.1.10, 192.168.1.11, 192.168.1.12 - mestre mesos com maratona e servidor consul
• 192.168.1.21, 192.168.1.22, 192.168.1.23 - três mesos escravo com agente cônsul

Todas as máquinas da seguinte configuração:

• seu próprio endereço IP como servidor DNS
• HAPROXY com consul-template para geração automática de haproxy.cfg
• consul-mesos para registrar os contêineres do estivador em execução com seu endereço IP do host, para evitar que o serviço tenha o endereço 172.1.0.1 no DNS ao resolver de uma máquina diferente

O problema que estou tendo atualmente é que quando eu inicio o contêiner do Docker com um serviço em modo de ponte, o endereço é resolvido pelo DNS como deveria ser (se você tiver luigi.service.consul isso será feito sem um problema), mas quando eu tento CURL -L http://luigi.service.consul/ , eu tenho aleatório 503 error codes , às vezes o endereço é resolvido e às vezes não é.

Alguma idéia de como investigar isso?

Verifiquei /etc/resolv.conf e, de tempos em tempos, vejo que o endereço DNS foi alterado para o antigo endereço IP do DNS (8.8.8.8), devo usar o endereço IP do host como DNS IP ou preciso usar o endereço do líder do cônsul?

Eu tentei depurar o tcpflow, quando a resposta é 503 é como esperar algum tempo, como se estivesse falhando ao resolver o serviço.

    

Answer 1

Demora algum tempo para buscar uma imagem do Docker, iniciar o contêiner e, finalmente, começar a atender solicitações. Idealmente, você deve recarregar o HAProxy no momento em que sua nova instância estiver pronta. Mas ainda pode haver conexões ativas para sua instância antiga. Quando você começa a investigar esse problema, verifica-se que já existe uma solução, chamada implantação azul-verde , conforme descrito por M. Fowler.

Se você deseja zero-downtime, não haverá uma solução trivial. Os engenheiros do Yelp descrevem como recarregar o HAProxy com verdadeiro tempo de inatividade zero adicionando extras regras para o iptables.

Recentemente o esquema de implantação azul-verde foi mesclado em marathon-lb (incluindo o truque iptables do Yelp). Acho que consul-mesos atualmente não suporta isso.