Actualización autoalojada a 3.1.0.beta2 con instalación típica multicontenedor requiere tiempo de inactividad adicional

Quisiera repetir que no estaba usando el actualizador gráfico. Tengo una instalación multi-contenedor. Hice:

git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup

(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

1 me gusta