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

Quero configurar o dimensionamento automático na AWS. Não quero usar o Elastic Load Balancer.

A chamada automática no Amazon cria instâncias do EC2 sem interrupções durante picos de demanda para manter o desempenho e diminui automaticamente durante as trocas de demanda para minimizar 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 upstream no nginx para 10 instâncias do EC2.

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

— Luis Lobo Borobia
fonte

Você precisa remover o "escalonamento automático" da sua pergunta. Escalonamento automático é um termo da AWS. Acho que o que você quer dizer é que você deseja dimensionar automaticamente (horizontalmente), adicionando mais nós upstream ao seu nginx, agindo como um LB, e você está perguntando como modificar automaticamente sua configuração do nginx quando os nós upstream são adicionados / excluídos / modificados. Nesse caso, edite sua pergunta de acordo.

— Talonx

bem, na verdade, eu sei o que é a chamada automática, e quero dizer isso. Eu quero misturar os dois. Vou atualizar a pergunta.

— Luis Lobo Borobia

A questão está mais clara agora, em sua intenção. Eu queria votar para reabrir, mas não vejo uma opção - acho que ainda não tenho representante suficiente.

— Talonx

Obrigado @talonx Espero que outros podem upvote para encontrar a minha resposta

— Luis Lobo Borobia

Acho que você pode combinar as notificações de dimensionamento automático da AWS (entregues usando o SNS) - supondo que ele retorne o nome do host da instância recém-criada / encerrada - e uma das APIs nginx de terceiros para atualizar e recarregar sua configuração do nginx. Desculpe por ser vago - não estou muito familiarizado com a API de dimensionamento automático.

— Talonx

Respostas:

Isso pode ser conseguido usando o Amazon SDK (estou quase pronto, o colocarei no github), utilizando o serviço SNS, EC2 e Autoscaling.

Eu segui as etapas abaixo para conseguir isso:

Ative a notificação HTTP e inscreveu meu servidor da web.
Adicionado um gancho de ciclo de vida com pulsação de 1 min (para aguardar 1 min antes de terminar) ao meu grupo de dimensionamento automático para finalizar o servidor
Criou um arquivo de índice para analisar a mensagem e detectar que tipo de mensagem é (por exemplo, Iniciar ou Encerrar)
Depois que o tipo de evento é decidido, consultei o EC2 para obter o ip privado da instância
No caso de Iniciar, aguarde até que o cabeçalho 200 seja recebido e adicione o ip ao nginx config e recarregue
No caso de Terminar, remova o IP da configuração e recarregue o nginx

Encontre o script aqui https://github.com/singhupendra/aws-autoscale

— Upendra
fonte

Alguma chance de você postar isso no github? Estou tentando fazer a mesma coisa e qualquer assistência seria apreciada.

— Aaron

use - github.com/singhupendra/aws-autoscale

— Upendra

Obrigado @talonx, fiz uma pesquisa, o Amazon Autoscale possui uma API para consultar o status atual do grupo de dimensionamento automático e enumera seus membros. Ele retorna o ID da instância ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ) e, em seguida, você pode usar as ferramentas de descrição para obter o nome do servidor ( http: // docs .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) e, finalmente, recrie o arquivo de inclusão upstream. Pude perceber as notificações de escalonamento automático para iniciar um processo que executa essas tarefas.

Eu ainda não o implementei, mas é um caminho a percorrer.

Pode-se também usar a Autocaling with SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Luis Lobo Borobia
fonte

Isso é basicamente o que eu fiz. Eu escrevi um script ruby que é executado a cada N minutos. Usando o AWS SDK, ele consulta os membros do ASG e, usando um modelo de ERB, gera uma nova configuração. Se a nova configuração for diferente da configuração atual, ela a copia e diz ao daemon (haproxy no meu caso) para recarregar sua configuração. Observe que as instâncias permanecem no ASG por um tempo após o término, portanto, certifique-se de que instance.status ==: running. Observe também que se leva N minutos depois que a instância é lançado por ele para atender as solicitações não usá-lo Unil agora> instance.launch_time + N.

— Mark Wagner

Obrigado @MarkWagner. Existe alguma possibilidade de você compartilhar esse script em algum lugar? Gist, github? Obrigado!

— Luis Lobo Borobia

Você teve alguma sorte com este script? Existe um exemplo no github ou em outro lugar?

— Aaron

Não, mas agora o nginx-plus (a versão paga) permite isso mais.

— Luis Lobo Borobia 13/09/2015

Ainda não o implementei, mas estou pensando em usar a Reconfiguração On-the-fly do NGiNX Plus . Estou pensando que a AMI, ou o gerenciamento de configuração (Puppet, Salt ou algo semelhante) 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 interno Route53, para que nenhum IP fixo o fizesse). precisa ser usado) e adicione-se ao cluster upstream para o proxy reverso. Depois que a verificação de integridade interna do NGiNX assumisse o controle dessa instância [adicionada] e a descartaria caso ela se tornasse indisponível. Essa parece a solução mais limpa e não há atraso na adição da instância, e quase nenhum atraso na remoção, pois o NGiNX Plus apresenta verificação de integridade fora da banda.

Essa abordagem evita a necessidade de configurar um sistema de detecção automática (Consul, Serf ou algo semelhante) que, para configurações menores, geralmente pareça muita sobrecarga, tanto nos termos de configuração / administração quanto nas instâncias EC2 necessárias. O Consul, por exemplo, exige no mínimo três instâncias para ser estável. Talvez o serviço seja executado nas instâncias ASG, mas ainda há a sobrecarga de mantê-las, e se o ASG reduzir para uma ou duas instâncias, você perderá o quorum.

Por fim, isso pode ser combinado com a notificação automática de alterações no grupo de escalonamento automático, talvez nos servidores NGiNX que são / são usados para balanceamento de carga. Um ouvinte acionado por essa notificação (que também pode ser chamado de Upendra) pode adicionar instantaneamente a nova instância ao NGiNX por meio da API de modificação On-the-fly. Além do custo do NGiNX Plus, isso nos faz pensar por que alguém usaria o Elastic Load Balancer com seus inúmeros problemas em primeiro lugar.

Editar 2015/12/07: ngx_openresty 's balanceador-by-lua ( ver esta discussão GitHub ) oferece uma outra solução de código aberto possível para hot-adicionar / remover servidores de grupo montante Nginx. Eu ainda não experimentei isso, mas gostaria de adicionar uma menção aqui para quem se deparar com este post.

— Ville
fonte