Actualicé mis sitios de 3.1.0.beta1 a 3.1.0.beta2, y después de iniciar la nueva versión, pero antes de destruir los contenedores de la aplicación antigua y comenzar unos nuevos, al menos uno de esos sitios comenzó a mostrar la página de error genérica a los usuarios.
No lo noté en mi sitio de prueba ni en los otros sitios que administro, pero es posible que haya sucedido y no lo haya visto.
En cualquier caso, para mí, en al menos un caso, el proceso de actualización “sin tiempo de inactividad” no tuvo éxito.
(Uso app para la aplicación web incluso en instalaciones multi-contenedor. Sé que no es la práctica normal. Odio escribir web_only)
Algún tiempo después de iniciar bootstrap y antes de destruir la aplicación, la versión antigua ejecutándose contra la nueva base de datos solo mostraba una pantalla de error. No recuerdo el contenido, y no causé una interrupción más larga al detenerme para tomar una captura de pantalla antes de hacer el destroy/start, pero solo era texto sobre blanco y no era la página de mantenimiento del sistema. He visto esto solo unas pocas veces antes, que cuando el bootstrap ejecuta db:migrate como parte de la reconstrucción asíncrona de “cero tiempo de inactividad”, el software antiguo que todavía se ejecuta falla debido a una inconsistencia en el esquema.
Lo que vi fue lo que sucede en caso de inconsistencia de la base de datos. Eso es mucho mejor que seguir adelante sin problemas, ¡rompiendo la base de datos! Cuando publiqué, fue para advertir que este era uno de esos casos raros en los que aplicar una actualización puntual (aquí de 3.1.0.beta1 a 3.1.0.beta2) creaba una incompatibilidad de esquema entre el código 3.1.0.beta1 y la base de datos después de ejecutar la migración de base de datos de 3.1.0.beta2, como sucede rara vez pero ocasionalmente con las actualizaciones normales de bajo tiempo de inactividad en el despliegue multi-contenedor.
Mi experiencia es diferente del error que se ha reportado con ruby en el actualizador gráfico. Es un problema completamente no relacionado. Reconozco que mi publicación fue movida del anuncio a un hilo general de “problemas con”, pero quiero dejar claro que la razón por la que la publiqué en el anuncio fue para advertir a otros auto-alojadores como yo cuando vieran el anuncio que esta actualización en particular era una que podría tener este impacto.
Mi mensaje no se quejaba de un error, ni siquiera de un problema. Solo pretendía ser un aviso de un caso normal pero infrecuente asociado con esta versión en particular y que no se mencionó en las notas de la versión.
Las quejas sobre que el gestor de docker no reconoce que no puede actualizar desde dentro de la imagen no están relacionadas en absoluto con mi intento de proporcionar una notificación útil a otros administradores de auto-alojamiento.
Tendría mucho sentido separar estos problemas no relacionados en hilos independientes para problemas independientes. EDITADO por @supermathie: Hecho
Creo que eso responde a la pregunta. El script launcher no tiene soporte para SKIP_POST_DEPLOYMENT_MIGRATIONS.
De nuevo, no estoy informando de un error. Solo intento advertir a otros con la instalación estándar de varios contenedores utilizando el proceso normal documentado para usar launcher con una instalación de varios contenedores que esta es diferente de su experiencia típica.
De verdad, de verdad, honestamente, lo digo en serio, ¡esto no es un informe de error!
Si quiero una implementación azul/verde con launcher, debería proporcionar una PR para launcher para implementarla.
No se me ocurrió el “problema” en el título del tema; eso se hizo cuando mi comentario fue movido fuera del hilo de anuncios. Ahora he modificado el título para dejar claro, espero, que no me estoy quejando de un problema.
Había visto la documentación de SKIP_POST_DEPLOYMENT_MIGRATIONS. Lo que realmente me había perdido era esta publicación que muestra cómo realizar implementaciones sin tiempo de inactividad con launcher:
He tenido muchos problemas para entusiasmarme con ello cuando proporciono cuatro, algunos meses cuatro y medio nueves de disponibilidad en un servicio que administro de forma gratuita en mi tiempo libre. Es un testimonio de la calidad del desarrollo de Discourse que pueda hacerlo con una política de “pruebas superadas”, incluyendo cosas como el minuto o más de tiempo de inactividad adicional que vi esta vez, y a veces reiniciando el host para actualizaciones de seguridad.
El script de Ansible que utiliza dashboard.literatecomputing.com ejecuta una tarea de Rake después de que se lanza el nuevo contenedor para realizar las migraciones posteriores. Cuenta con tener SKIP_POST_DEPLOYMENT_MIGRATIONS activado en web_only.yml. Hago esto solo en sitios que sé que serán administrados por mis scripts, ya que si no entiendes cómo funciona, es una bomba de tiempo.
Tenga en cuenta que para muchas actualizaciones, el arranque del nuevo contenedor no romperá las cosas para el contenedor en ejecución, pero para algunas sí. No es tan raro que una actualización migre de tal manera que el contenedor antiguo no pueda usar la base de datos (sin usar SKIP_POST_DEPLOYMENT_MIGRATIONS).
