Como atualizar automaticamente a lista de servidores upstream nginx quando aws ec2 hostname muda ou aumenta?

Question

Eu quero configurar o escalonamento automático na AWS. Eu não quero usar o Elastic Load Balancer.

As chamadas automáticas no Amazon cria instâncias do EC2 de forma integrada durante picos de demanda para manter o desempenho e diminui automaticamente durante os períodos de calmaria da demanda para minimizar os custos.

Como essas instâncias do EC2 são criadas automaticamente, seus nomes de host são desconhecidos para o NGINX.

Eu sei e já tenho configuração do upstream em nginx para 10 instâncias do EC2.

Eu quero poder adicionar / atualizar / excluir automaticamente nomes de servidores à minha configuração nginx de upstream, quando o escalonamento automático adiciona / atualiza / exclui instâncias do EC2.

    

Answer 1

Isso pode ser feito usando o Amazon SDK (estou quase pronto para isso, vou colocá-lo no github), utilizando o serviço SNS, EC2 e Autoscaling.

Eu segui os passos abaixo para conseguir isso:

1. Ative a notificação HTTP e inscreva-se no meu servidor da web.
2. Adicionado um gancho de ciclo de vida com pulsação de 1 min (para aguardar 1 min antes de terminar) para meu grupo de escalonamento automático para o servidor de término
3. Criado um arquivo de índice para analisar a mensagem para detectar que tipo de mensagem é (ou seja, iniciar ou terminar)
4. Uma vez decidido o tipo de evento, consultei o EC2 para obter o ip privado da instância
5. Em caso de Lançamento, espere até que o cabeçalho 200 seja recebido e, em seguida, adicione o ip à configuração do nginx e recarregue
6. No caso de Terminate, remova o IP da configuração e recarregue o nginx

Por favor, encontre o script aqui link

    

Answer 2

Obrigado @talonx, fiz algumas pesquisas, o Amazon Autoscale tem uma API para consultar o status atual do grupo de autoescalonamento e enumera seus membros. Ele retorna o ID da instância ( link ), então você pode usar a descrição ferramentas para obter o nome do servidor ( link ) e, finalmente, recriar o upstream incluir arquivo. Consegui perceber as notificações de escalonamento automático para iniciar um processo que executa essas tarefas.

Ainda não implementei, mas é um caminho a seguir.

Também é possível usar o Autocaling com o link

do SNS.     

Answer 3

Ainda não implementei isso, mas estou pensando em usar a On-the -fly Reconfiguração de NGiNX Plus . Eu estou pensando que o AMI, ou o gerenciamento de configuração (Puppet, Salt ou tal) que configura uma instância do Auto Scaling Group, poderia alcançar a API de reconfiguração do NGiNX (talvez, por meio de um nome de domínio Route53 interno para que nenhum IP fixo precisa ser usado) e adicione-se ao cluster upstream do proxy reverso. Depois disso, a verificação de saúde integrada do NGiNX assumirá a instância [adicionada] e a descartará caso se torne indisponível. Esta parece ser a solução mais limpa e não há atraso na adição da instância, e quase nenhum atraso em descartá-la, uma vez que o NGiNX Plus apresenta uma verificação de integridade fora da banda.

Essa abordagem evita a necessidade de configurar um sistema de descoberta automática (cônsul, servo ou semelhante), o que, para configurações menores, muitas vezes parece ter muita sobrecarga, tanto nos termos de configuração / administração quanto nas instâncias necessárias do EC2. O cônsul, por exemplo, requer um mínimo de três instâncias para ser estável. O servo talvez pudesse ser executado nas próprias instâncias do ASG, mas ainda há a sobrecarga de mantê-lo, e se o ASG desce para uma ou duas instâncias, você perderia o quorum.

Por fim, isso pode ser combinado com a notificação automática de alterações do grupo do Auto Scaling, talvez no (s) servidor (es) NGiNX usado (s) para o balanceamento de carga. Um ouvinte acionado por tal notificação (isso pode ser o que o Upendra também se referiu) poderia adicionar instantaneamente a nova instância ao NGiNX por meio da API de modificação dinâmica. Além do custo do NGiNX Plus, isso nos leva a imaginar por que alguém usaria o Elastic Load Balancer com seus inúmeros problemas em primeiro lugar.

Editar 2015-12-07: ngx_openresty 's balancer-by-lua ( veja este tópico do GitHub ) oferece uma outra solução possível de código aberto para servidores de adição / remoção a quente do grupo upstream do NGiNX. Eu ainda não experimentei isso, mas queria adicionar uma menção aqui para alguém tropeçar neste post.