Proxy Nginx para muitos contêineres em execução em diferentes nós CoreOS

Question

Navegando na Internet, encontrei muitos tutoriais sobre o proxy para diferentes contêineres do Docker em execução no mesmo host, usando Nginx / Confd (ou Haproxy ou Vulcand). No entanto, o que preciso fazer é diferente. Após uma visão geral da minha infraestrutura:

• Um cluster CoreOS on-line com 5 nós, todos executando o etcd
• Em cada nó do cluster, são lançados diferentes contêineres do Docker (servidores Nginx executando aplicativos WordPress) usando frota, sem expor uma porta e gravar seus ips (o Docker ip tomado com o docker inspecionar) no etcd.
• Se um nó ficar inativo, meus serviços serão movidos automaticamente em outro nó disponível

Agora, o que eu preciso fazer é ter um proxy Nginx que direcione meu tráfego para vários contêineres, dependendo do vhost. Seguindo um exemplo:

Nginx (com IP de publicação) recebe solicitação xxx.domain.com - > node-1 - > container com ip atribuído automaticamente (escutando na porta 80)

Nginx (com IP de publicação) recebe solicitação yyy.domain.com - > node-2 - > container com ip atribuído automaticamente (escutando na porta 80)

Aqui minhas perguntas:

• O meu cenário está correto? Estou pensando em algo errado?
• Meu proxy Nginx deve estar fora do cluster CoreOS? Ou eu tenho que executá-lo em cada nó CoreOS?
• Como posso alcançar essa configuração? Qual é o melhor caminho?

Obrigado antecipadamente!

    

Answer 1

Você precisa de algum tipo de descoberta de serviço para que o nginx possa "localizar" os contêineres em execução nos nós. Você pode gravar um registro no etcd quando o container iniciar e remover ao sair e fazer com que o nginx verifique isso.

Para mover serviços por aí, você pode dar uma olhada na frota para um agendamento simples.

    

Answer 2

Não sei se entendi bem. Mas aqui está a maneira que eu faria:

Coloque um balanceador de carga (HAProxy, Nginx, Amazon ELB (se você estiver no EC2)) fora do cluster, roteando todos os tráfegos dentro dele.

Dentro dele, você pode experimentar o Gogeta: link

É um proxy reverso sendo executado globalmente (em cada nó) e roteando o tráfego com base nas entradas de domínio no etcd para os contêineres específicos. você poderia então configurar seus arquivos de serviço adicionando e removendo sua presença para o etcd que o gogeta monitora.

ExecStart=<do something>    
ExecStartPost=/usr/bin/etcdctl set /services/<your_service>/%i/location '{\"host\": "%H", \"port\": <your containers exposed port>}'

ExecStop=/usr/bin/docker stop <your service>
ExecStopPost=/usr/bin/etcdctl rm --recursive /services/<your_service>/%i

Funciona e solicita balanços de carga com a estratégia Round Robin. Embora pareça haver um problema, enviei um link

Isso ajuda você?

    

Answer 3

Você pode usar um trio de nginx, etcd & confie para fazer isso. Há um ótimo post intitulado " Balanceamento de carga com CoreOS, confd e nginx " que percorre três contêineres.

1. Você precisa de um contêiner de "dados" compartilhado, no qual possa armazenar as configurações nginx geradas dinamicamente
2. Você precisa de um contêiner em execução confd , que leia valores de etcd e gere dinamicamente a configuração nginx para você (isso é salvo em um volume dos dados compartilhados) "container"
3. Por fim, você precisará do nginx que simplesmente usa esse volume de "dados" compartilhado para suas configurações.

A chave então é ter cada backend HTTP anunciando-se via etcd, e então confd irá pegar as mudanças e reconfigurar o nginx na hora. Este processo é muito parecido com o que @ Julian mencionou na resposta anterior:

ExecStart=<do something>    
ExecStartPost=/usr/bin/etcdctl set /services/<your_service>/%i/location '{\"host\": "%H", \"port\": <your containers exposed port>}'

ExecStop=/usr/bin/docker stop <your service>
ExecStopPost=/usr/bin/etcdctl rm --recursive /services/<your_service>/%i

Confira os documentos do modelo confd para obter mais exemplos, mas você terá algo mais ou menos assim:

{{range $dir := lsdir "/services/web"}}
upstream {{base $dir}} {
    {{$custdir := printf "/services/web/%s/*" $dir}}{{range gets $custdir}}
    server {{$data := json .Value}}{{$data.IP}}:80;
    {{end}}
}

server {
    server_name {{base $dir}}.example.com;
    location / {
        proxy_pass {{base $dir}};
    }
}
{{end}}

Só para observar, você só precisará de um desses "trios" em execução, a menos que queira uma configuração de disponibilidade mais alta. Nesse caso, você precisará de dois ou mais. Quando você vai HA, você provavelmente vai querer enfrentá-los com uma instância do ELB.