Reiniciando os backends do nginx sem perder pedidos

Question

Tenho certeza de que foi perguntado antes em palavras diferentes, mas eu rodei vários sites do Django via uwsgi (modo emporer) por trás do nginx. É tudo uma configuração bastante normal, mas acho que, se eu reiniciar o processo central do uwsgi, o nginx apenas lança 502s em vez de esperar que o socket se torne disponível.

Eu reconheço que a maioria disso é provavelmente por uma razão, mas as pessoas que vêem 502 erros realmente me picam. Certamente não é algo que eu quero que um cliente veja. Então ...

• Posso implorar ao nginx para esperar / tentar novamente os backends? Ou
• Existe alguma coisa (além do óbvio) que eu possa fazer para minimizar o dano comercial das reinicializações do uwsgi?

Answer 1

Uma ideia é substituir o modelo 502 padrão do nginx por uma página que atualize automaticamente o cliente. Você basicamente só precisa criar um novo arquivo que tenha <meta http-equiv="refresh" content="5"> no cabeçalho. Dê a ele algum texto amigável, explicando que o site está passando por manutenção (ou algum equivalente a BS) e vincule-o à sua configuração do nginx:

error_page 502  /502.html;  
location = /502.html {  
    root  /var/www/502.html;  
}

Você precisará disso em todos os seus sites (pode haver uma maneira de fazer isso globalmente), mas o resultado é que qualquer um que ver um tempo limite de gateway verá uma página que não parece particularmente estranha e que, dentro de cinco segundos, coloque-os na página que eles originalmente queriam.

Isso tudo supõe que o back-end voltará a funcionar. Se houver uma chance de ele ser desligado indefinidamente, talvez você queira escrever algo no JS que verifique a própria URL e tenha um novo contador. Tudo bastante simples, mas pode satisfazer os clientes que estão ficando irritados com a queda de um site.

    

Answer 2

Apenas um pensamento, nem testado nem certo se possível:

E se você configurar vários servidores upstream no nginx que apontam para a mesma instância do uWSGI. Se o nginx não se comunicar com o uwsgi, ele enviará o pedido para o próximo upstream (a diretiva proxy_next_upstream ajuda aqui?), que é na verdade a mesma, mas pode estar pronto.