Reinicio de backends de nginx sin perder solicitudes

Estoy seguro de que se ha preguntado antes en diferentes palabras, pero ejecuto varios sitios de Django a través de uwsgi (modo emporer) detrás de nginx. Todo es una configuración bastante estándar, pero me parece que si vuelvo a iniciar el proceso central uwsgi, nginx bombas justo 502 en lugar de esperar a que el socket para estar disponible.

Reconozco que la mayor parte de esto es probablemente por una razón pero la gente que ve 502 errores realmente me picara. Ciertamente no es algo que quiero que un cliente vea. Asi que…

  • ¿Puedo pedirle a nginx que espere / vuelva a intentar los backends? O,
  • ¿Hay algo (aparte de lo obvio) que puedo hacer para minimizar el daño comercial de los reinicios de uwsgi?

Una idea es reemplazar la plantilla 502 de nginx por defecto con una página que actualiza automáticamente el cliente. Usted esencialmente sólo tiene que hacer un nuevo archivo que tiene <meta http-equiv="refresh" content="5"> en el encabezado. Déle un poco de texto amistoso, explicando que el sitio está actualmente en mantenimiento (o algún equiv BS) y enlace a él desde su configuración nginx:

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

Usted necesitará eso en todos sus sitios (puede haber una manera de hacer eso globalmente) pero el resultado es cualquier persona que vería un plazo de la entrada ahora verá una página que no parezca particularmente impar y, dentro de cinco segundos, Desembarcarlos en la página que originalmente querían.

Que todo supone que el backend volverá. Si existe la posibilidad de que esté apagado indefinidamente, es posible que desee escribir algo en JS que compruebe la URL en sí y tener un contador de reintento. Todo bastante simple, pero puede apaciguar a los clientes que se están molestando con un sitio que está abajo.

Sólo un pensamiento, ni probado ni seguro si es posible:

¿Qué pasa si se configuran varios servidores ascendentes en nginx que apuntan a la misma instancia uWSGI. Si nginx no se comunica con uwsgi, enviará la solicitud a la siguiente cadena ascendente (¿aconseja la directiva proxy_next_upstream aquí?), Que es realmente la misma, pero puede estar ya arriba.

    Intereting Posts