¿Cómo actualizo Discourse en una configuración de múltiples contenedores?

[alexk (Alex)]

¡Hola! Acabo de configurar una instalación fresca de Discourse con múltiples contenedores y me pregunto cuál sería el mejor método para actualizar.

La documentación indica:

Minimiza el tiempo de inactividad al actualizar a nuevas versiones de Discourse. Puedes iniciar procesos web nuevos mientras tu sitio está en funcionamiento y, solo después de que se hayan construido, cambiar a la nueva imagen.

Al leer esto, me pregunto si esto significa que es seguro ejecutar una versión anterior de Discourse en vivo mientras otro contenedor se actualiza.

Por ejemplo:

Digamos que tengo dos contenedores que solo ejecutan la web funcionando en máquinas virtuales separadas detrás de un equilibrador de carga. Saco una de las instancias del contenedor del equilibrador de carga y ejecuto el arranque con la versión más reciente. La versión antigua sigue en servicio para lograr un tiempo de inactividad cero (¿es eso correcto?). Luego, devuelvo el contenedor actualizado al equilibrador de carga y repito el proceso con el otro contenedor.

Eso suena correcto, ¿verdad?

[pfaffman (Jay Pfaffman)]

Eso es correcto. Para actualizaciones con tiempo de inactividad cero real, necesitas iniciar el nuevo contenedor con SKIP_POST_DEPLOYMENT_MIGRATIONS: 1, luego lanzarlo y, una vez que los contenedores antiguos ya no estén en ejecución, ejecutar SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate. De lo contrario, el inicio puede (aunque no ocurre en cada actualización) dejar la base de datos en un estado que el contenedor antiguo ya no puede utilizar.

[alexk (Alex)]

¡Eso es genial! Las migraciones de base de datos eran exactamente mi preocupación, ¡así que es útil saber cómo controlarlas!