Estoy tratando de comprender la configuración de “tiempo de inactividad cero” (zero downtime). Mi configuración actual tiene varias instancias de Discourse para diferentes comunidades. Ambas tienen una configuración de contenedores de datos y web 2. Tengo un Nginx a nivel de host que maneja la terminación SSL y utiliza una conexión por socket que se transfiere al Nginx del contenedor.
He encontrado estos dos temas de interés:
Así que estoy tratando de entender este proceso. Parece que hay un poco de conocimiento asumido para lograr esto. Cualquier ayuda que alguien pueda brindar aquí sería genial.
Lo primero que me gustaría entender es cómo saber cuándo se necesita actualizar un contenedor de datos. Parece que hay casos en los que no puedes simplemente reconstruir el contenedor web. ¿Cómo puedo saber con certeza cuándo es este el caso? ¿Sería en todos los casos donde la opción de actualización está deshabilitada en el panel de administración de la interfaz de usuario para actualizaciones, junto con un trabajo personalizado potencial con temas y complementos? ¿Podría saberlo con certeza revisando las migraciones del esquema de la base de datos? ¿Necesitaría tener un entorno de staging y simplemente intentarlo para saberlo con certeza?
Lo siguiente que me gustaría saber es cómo ejecutar una actualización con tiempo de inactividad cero. Según como leo los dos enlaces, ¿estarías haciendo una reconstrucción del contenedor de datos y del contenedor web de todos modos? No logro descifrar esto. ¿Necesitaría contenedores de datos y web separados para lograr tiempo de inactividad cero al final?
¡Cualquier orientación sería increíble! Probablemente podría pasar muchas horas y descubrir algo que parecía funcionar, pero preferiría apoyarme en los hombros de gigantes y no tener que descubrir los casos extremos de la manera difícil (en producción) si es posible.
Si requiere más información sobre mi configuración particular, por favor pida aclaraciones. Responderé directamente y actualizaré esta publicación.
No sé mucho sobre “migración posterior al despliegue”, pero según lo que recuerdo haber leído (aquí en meta), una forma de lograr esto es utilizando 3 contenedores: 1 de datos y 2 de web. Actualizas el contenedor de web que no está en ejecución y lo cambias por el que usas una vez actualizado.
Creo que esto tiene sentido. ¿Entonces el contenedor de datos no ejecuta una reconstrucción a través del launcher? Yo simplemente gestionaría el balanceo de carga a nivel de host con Nginx. Déjame ver si puedo ordenar esto:
contenedor de datos:
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
Todo depende de las actualizaciones que deban realizarse en el contenedor de datos.
La actualización de Postgres 12 es un buen ejemplo de tiempo de inactividad inevitable. Incluso si tuvieras un contenedor de datos duplicado, necesitarías mantener tu sitio duplicado en modo solo lectura mientras se realiza la actualización de la base de datos.
La única forma de evitar el tiempo de inactividad es no actualizar nunca. Las actualizaciones realizadas a través de /admin/upgrade en una instalación de contenedor único ya son sin tiempo de inactividad. Las actualizaciones realizadas vía ssh, como cuando es necesario actualizar la imagen base, tendrán distintos grados de tiempo de inactividad según tu presupuesto y tolerancia a la complejidad.
La mejor manera de evitar el tiempo de inactividad es crear una copia de staging; de lo contrario, corres un pequeño riesgo de tiempo de inactividad después de cada actualización cuando los complementos o personalizaciones encuentren problemas de compatibilidad.
Vale. Para asegurarme de no tener un problema mayor, ejecutaré una prueba en el entorno de staging y observaré los resultados… así que intentaré el procedimiento anterior y veré si el contenedor de datos falla.
De ser así, mi entorno de staging podría constar de 1 servidor de datos y 1 servidor web, mientras que el de producción tendría 2 servidores de datos y 2 servidores web. En el peor de los casos, si se intenta primero en staging, el procedimiento en producción sería:
Depende de tu definición de tiempo de inactividad.
Si los usuarios no pueden acceder al sitio, eso es tiempo de inactividad, obviamente.
¿Considerarías tiempo de inactividad si no pueden registrarse, publicar, responder o dar me gusta?
Si se trata de una comunidad grande, los costos de ejecutar múltiples contenedores de datos en SSD serán considerables. ¿Has considerado un servidor PostgreSQL externo como Amazon RDS?
Los tipos de detalles que @Stephen está señalando son realmente importantes. Porque necesitamos entender qué es cero tiempo de inactividad, por ejemplo, podría eludir un requisito de Cero Tiempo de Inactividad haciendo lo siguiente:
Defino cero tiempo de inactividad como nunca responder al usuario con un código distinto a HTTP 200 cuando la solicitud es válida (manteniendo los códigos 300 y 400 abiertos según sea necesario). Luego, implemento Discourse en un droplet de 10 $ con una solución de un solo contenedor y agrego Add an offline page to display when Discourse is rebuilding or starting up para evitar errores 500. De esta manera, no muestro un sitio que ha estado caído.
¿Pensaría con una mente racional que esto es cero tiempo de inactividad? Nunca. ¿Funciona como se propone? Por supuesto. Y podría incluso agregar un servidor de respaldo en otra región para ser aún más a prueba de cero tiempo de inactividad.
Por eso son importantes las calificaciones y la semántica. No es lo mismo mostrar siempre algo que tener siempre funcionalidad en el sitio.
Solo ayúdanos a entender. ¿Qué necesitas para cumplir con tu definición de tiempo de actividad cero? ¿Pueden los usuarios sufrir de 10 a 30 minutos de solo lectura? ¿Tienes la habilidad suficiente para implementar una solución? ¿Estás buscando ofrecer a nuestros usuarios una página agradable que diga En mantenimiento, volvemos enseguida? Necesitamos más detalles para brindarte una solución más precisa que realmente funcione para ti. O, al menos, para orientarte en la dirección correcta.
Esta discusión se estaba poniendo un poco acalorada y fuera de tema. Por favor, recuerden ser respetuosos entre sí mientras debaten un tema. Las preguntas de aclaración se hacen para dar una respuesta más precisa, ya que la configuración y los objetivos de cada persona son diferentes.
y no tener que descubrir los casos extremos de la manera difícil (en producción) si es posible.