Como suspender solicitações Nginx durante atualizações de backend

Question

Eu gostaria de ter Nginx suspender (manter) solicitações http por curtos períodos de tempo, enquanto eu atualizo ou reinicio o serviço de back-end, faço uma migração de banco de dados ou alguma outra tarefa administrativa, sem causar erros aos usuários finais.

Basicamente, gostaria de fazer a seguinte sequência de operações:

1. diz ao Nginx para parar o encaminhamento de solicitações para o meu back-end, em vez disso, mantenha-as em suas filas assíncronas;
2. espere e seja notificado quando todas as solicitações pendentes para o back-end forem concluídas;
3. atualize, reinicie ou opere no serviço de back-end ocioso;
4. verifique rapidamente se o serviço de back-end está operacional, usando seu endereço particular;
5. abra as comportas do Nginx e deixe todas as solicitações pendentes passarem.

Idealmente, isso me permitiria executar tarefas administrativas que precisam de acesso exclusivo a todo o servidor de backend, como reinicializações, atualizações ou migrações, sem causar aos usuários finais nada mais sério que um atraso, esperançosamente de menos de um minuto. / p>

Eu encontrei esta solução , mas ela não está abordando o ponto 2. Além disso, ela precisa do interpretador Lua compilado no Nginx, com qualquer vazamento de memória e problemas de segurança que possam implicar.

Existe algum truque de configuração ou módulo Nginx especificamente direcionado para esse problema? Isso pode ser feito com o Nginx, talvez testando a existência de um arquivo de controle?

Como outros administradores abordam esse problema em geral?

(Eu sei que o servidor de aplicativos uWSGI para todos os propósitos e um pouco disperso tem esse recurso, entre centenas de outros, mas prefiro evitar a introdução de outro elemento entre o Nginx e meu backend.)

    

Answer 1

você poderia configurar o nginx para executar um script para massagear e passar a chamada http para algum processo de fila, como o beanstalkd, usando o tratamento de erros no 502 BAD GATEWAY e / ou 503 SERVICE UNAVAILABLE. (erro quando o serviço de back-end não está disponível).

então, após a atualização de backend, retire o reqs do beanstalkd e processe-os para o serviço de back-end.

Além disso, se o serviço de back-end cair inadvertidamente, isso pode ser uma solução de alta disponibilidade para não perder as chamadas de API. configure um jenkins / cron para verificar e processar automaticamente qualquer fila de beans de feijão.

    

Answer 2

Acho que você está lidando com um cenário de manutenção com tempo de inatividade mínimo.

Recomendamos que você use um servidor de backup para reter a solicitação dos segundos necessários < 20 > (ou) mesmo < 100 > e redirecionar para o URI original depois que o aplicativo for reiniciado.

Você pode seguir o tópico nginx abaixo, em que a solução é compartilhada.

link

    

Answer 3

Eu nunca fiz isso, mas se eu alguma vez tentei, acho que usaria um firewall. Eu provavelmente precisaria fazer o script da solução, que seria assim:

1. Diga ao firewall para permitir conexões existentes, mas para filtrar novas conexões na porta 80 (ou 443).
2. Aguarde a conclusão das solicitações pendentes para o backend (mesmo se as conexões do nginx aos clientes ainda estiverem abertas).
3. Atualize, reinicie, o que for.
4. Diga ao firewall para permitir conexões novamente.

Se as etapas 2 + 3 não demorarem muito, os clientes tentarão novamente e, eventualmente, conseguirão se conectar na etapa 4. Se demorarem muito tempo, os clientes terão tempo limite, mas isso não é um problema, já que os usuários a paciência terá expirado mais cedo, não?

A solução tem algumas capturas. Um cliente pode conseguir obter a página principal e, em seguida, pode não conseguir prosseguir para obter os arquivos estáticos (considerando o que você tem em mente, poderia). Isso não será um problema, no entanto, se você servir seus arquivos estáticos de outra máquina ou CDN.

Além disso, acredito que alguém normalmente se preocuparia com o que você está preocupando somente depois que eles já tivessem configurado alguma solução de alta disponibilidade, por exemplo, dois servidores mais um endereço IP que pode ser movido de um servidor para outro. Quando você move o endereço IP de um servidor para o outro, os usuários que possuem uma conexão aberta são desconectados. Eu acho que isso é aceitável, porque esses usuários pegam algo parecido com uma página em branco no navegador, perguntam o que diabos aconteceu, clique em reload, dessa vez funciona, e eles não se incomodam mais; eles nem se lembram do incidente alguns minutos depois. Usar o truque do firewall para evitar essa desconexão criaria mais problemas do que soluciona, porque a etapa 2 precisaria ser modificada para esperar que o nginx terminasse de atender as solicitações aos clientes, e isso pode levar muito tempo se um usuário tiver uma conexão lenta. Em qualquer caso, acho que a alta disponibilidade tem tantos problemas que isso teria uma prioridade tão baixa que nunca seria feito (a menos que você seja o Google ou algo assim).