nginx atualização backend com proxy reverso e sem tempo de inatividade

Question

Eu tenho uma instância do tomcat servindo solicitações e tenho nginx como proxy reverso para essa instância do tomcat.

Quando atualizo meu aplicativo Java, demorou cerca de 10 segundos. Mas esse site de 10 segundos está inativo e o nginx retorna a página HTTP 503.

O que eu gostaria que o nginx fizesse: pausar todas as conexões de entrada até que o backend esteja ativo. Então comece a servi-los. Idealmente, faça algum teste inteligente, por ex. "/" retorna HTTP 200. Na minha opinião, é melhor que o usuário espere 10 segundos do que ver a página HTTP 503.

Eu não quero cluster para isso. Eu uso caches no aplicativo e meu aplicativo da web está longe de ser carregado. Os clusters introduziriam muitos problemas nos quais não quero gastar tempo.

Eu uso a seguinte diretiva para conectar ao tomcat:

proxy_pass            http://127.0.0.1:8080;

    

Answer 1

Se você estiver usando o fastcgi para se comunicar com o aplicativo, defina fastcgi_read_timeout , fastcgi_connect_timeout e fastcgi_send_timeout para o valor desejado que seja aceitável para nginx "manter" o cliente e aguarde a resposta do aplicativo. (ou seja, 60 segundos)

O navegador permanecerá em branco até a resposta do aplicativo, aguardará até 60 segundos para lançar 503 (serviço não disponível) ou 504 (tempo limite do gateway), mas o soquete / porta no aplicativo deve estar atendendo mesmo com carga alta ou O nginx pode receber uma "conexão recusada" do backend e enviar 503 para o cliente. Se seu aplicativo está travando e removendo o soquete ou fechando a porta de escuta, não tenho 100% de certeza se esse ajuste irá ajudá-lo, mas é bom configurá-los.

Se você estiver falando com o aplicativo por meio de proxy, os nomes das variáveis corretas serão proxy_read_timeout , proxy_connect_timeout e proxy_send_timeout .

Talvez você só precise dos read e connect .

    

Answer 2

A melhor maneira de fazer isso depende da natureza do conteúdo entregue pelo tomcat.

• Se o conteúdo gerado pelo tomcat não puder ser armazenado em cache no lado do nginx, aumente proxy_connect_timeout e proxy_read_timeout para 10s e use o recarregamento de contexto em vez de reiniciar o tomcat (defina reloadable=true em seu arquivo de contexto ou use as chamadas do gerenciador JMX / Tomcat para forçar o recarregamento do webapp, por exemplo, http://[hostname]:[port]/manager/reload?path=[/path/to/your/webapp] ).

• Se o conteúdo gerado pelo tomcat puder ser armazenado em cache no lado do nginx, você poderá executar o procedimento anterior, mas definir tempos limite para alguns valores razoáveis. Em seguida, jogue mais coisas em sua configuração: use proxy_cache_use_stale , proxy_cache_lock e proxy_cache_lock_timeout juntos para exibir uma página obsoleta para o visitante enquanto você permite uma solicitação de cada vez para tentar atualizar o cache, evitando tempos de resposta mais altos no aplicativo redistribuição.

Você também pode procurar pelo módulo de terceiros upstream_check_module (ou usar um fork como tengine que implementa este nativamente ) para uma verificação mais sã de cura.

Se você puder pagar, você também pode usar a edição comercial do nginx chamada nginx plus que implementa isso nativamente (e permite condições mais inteligentes para verificações de http) com health_check e match diretivas.