Shinyproxy: Aclaración sobre el latido de los contenedores Docker

Creado en 25 feb. 2021  ·  4Comentarios  ·  Fuente: openanalytics/shinyproxy

A medida que implementamos las pruebas para los usuarios, empiezo a notar algunos contenedores que no se cierran como era de esperar. Me comuniqué con algunos de estos usuarios para ver qué comportamiento tienen (es decir, dejan pestañas abiertas, etc.):

image

Mientras tanto, me preguntaba si hay alguna característica de tiempo de espera configurable que tal vez no vi en la documentación. Sería genial tener una edad máxima de contenedor o algo así. Podríamos escribir nuestros propios scripts de control de Docker que verifiquen esto, pero sería útil si hubiera algo en ShinyProxy que también permitiera esto.

question

Comentario más útil

Por cierto, tenemos algunos planes para una función max-lifetime , que mata la aplicación después de una cierta cantidad de tiempo, independientemente de si está en uso. Esto aún no se ha implementado y probablemente no lo hará en la próxima versión. Te mantendré informado si empezamos a trabajar en ello.

Todos 4 comentarios

+1

Hola @ jat255

ShinyProxy actualmente funciona de la siguiente manera:

  • cada proxy.heartbeat-rate ShinyProxy envía un latido al cliente. Si el cliente responde, el estado interno se actualiza con la hora actual. El valor predeterminado de heartbeat-rate es 10 segundos. Estos latidos se envían a través del canal websocket (si corresponde).
  • cada solicitud HTTP a una aplicación también actualiza el estado interno.
  • si el último latido de un contenedor es más largo que proxy.heartbeat-timeout hace, ShinyProxy mata la aplicación. Esto es por defecto 60 segundos.

Siempre que el usuario mantenga su navegador abierto y la conexión websocket esté abierta o se envíen solicitudes HTTP, ShinyProxy asume que la aplicación está en uso y, por lo tanto, no la matará.
Tenga en cuenta que Spring también mantendrá abierta la sesión del usuario siempre que la aplicación envíe solicitudes HTTP.

Por lo tanto, puede suceder que las aplicaciones estén viviendo durante mucho tiempo. Sin embargo, veo que tiene una aplicación que está abierta durante 75 horas, que son aproximadamente tres días, esto significaría que el usuario tiene su computadora funcionando durante tres días (sin suspender). ¿Podría este ser el caso? De lo contrario, es posible que haya encontrado un error del que no tenemos conocimiento.

Por cierto, tenemos algunos planes para una función max-lifetime , que mata la aplicación después de una cierta cantidad de tiempo, independientemente de si está en uso. Esto aún no se ha implementado y probablemente no lo hará en la próxima versión. Te mantendré informado si empezamos a trabajar en ello.

@LEDfan muchas gracias por la aclaración. No estoy seguro de si la sesión de larga duración es un error o si alguien dejó una pestaña ejecutándose en la computadora de su oficina (tratando de obtener más información del usuario). Esta duración limitada de la sesión es un problema de seguridad para nuestro equipo del sector de TI (no les gusta ver algo conectado durante mucho tiempo sin un usuario sentado allí). Algo como max-lifetime sería útil. Creo que mientras tanto, vamos a preparar una función de tiempo de espera como esta idea , para presentarles a nuestros usuarios una advertencia de que están a punto de cerrar la sesión, y luego mataremos el servidor Shiny si no hay respuesta, lo cual (según tengo entendido) debería hacer que los contenedores docker se limpien. Seguiré adelante y cerraré esto en base a la aclaración anterior. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones