0
419
Vistas¿Por qué mis trabajadores gunicorn Python/Flask están saliendo del término de la señal?
Tengo una aplicación web Python/Flask que estoy implementando a través de Gunicorn en una imagen acoplable en Amazon ECS. Todo va bien y luego, de repente, incluida la última solicitud exitosa, veo esto en los registros:
[2017-03-29 21:49:42 +0000] [14] [DEBUG] GET /heatmap_column/e4c53623-2758-4863-af06-91bd002e0107/ADA [2017-03-29 21:49:43 +0000] [1] [INFO] Handling signal: term [2017-03-29 21:49:43 +0000] [14] [INFO] Worker exiting (pid: 14) [2017-03-29 21:49:43 +0000] [8] [INFO] Worker exiting (pid: 8) [2017-03-29 21:49:43 +0000] [12] [INFO] Worker exiting (pid: 12) [2017-03-29 21:49:43 +0000] [10] [INFO] Worker exiting (pid: 10) ... [2017-03-29 21:49:43 +0000] [1] [INFO] Shutting down: Master
Y los procesos mueren y el programa sale. Luego, ECS reinicia el servicio y la imagen de la ventana acoplable se ejecuta nuevamente, pero mientras tanto, el servicio se interrumpe.
¿Qué estaría causando que mi programa reciba una señal TERM? No puedo encontrar ninguna referencia a que esto suceda en la web. Tenga en cuenta que esto solo sucede en Docker en ECS, no localmente.
3 Respuestas
Responde la pregunta0
Resultó que después de agregar una página de inicio de sesión al sistema, la verificación de estado estaba recibiendo una redirección 302 a /iniciar sesión en /, que estaba fallando en la verificación de estado. Entonces el contenedor fue asesinado periódicamente. ¡El soporte de Amazon es increíble!
0
Si bien no se aplica específicamente al problema de la pregunta, este comportamiento puede deberse a sistemas externos como la orquestación de contenedores (es decir, Kubernetes).
Por ejemplo,
- Comienza un pod creado a partir de una imagen con un alto costo inicial
- Se agota el tiempo de espera de la sonda de actividad
- Kubernetes envía un término sig para detener correctamente el contenedor
En el escenario de Kubernetes , una solución podría ser ajustar las configuraciones de la sonda de actividad o preparación para permitir tiempos de inicio más prolongados.
0
Para agregar al comentario de rjurney, en la consola de AWS para ECS, puede verificar el estado de su aplicación consultando la pestaña Eventos del Servicio que se ejecuta en su clúster de ECS. Así es como me enteré de las comprobaciones de estado fallidas y otros problemas.
