¿Es posible actualizar a una versión más nueva sin reconstruir todo el sistema?
Estoy pensando en un escenario donde dos aplicaciones de Discourse son virtualmente idénticas y una vez que tengo una nueva imagen lista, de cualquiera de las dos, podría usarla para implementar el segundo Discourse, teniendo toda la configuración/parámetros para el contenedor.
Supongo que lo único que quedaría por gestionar para dicho contenedor sería la migración de la base de datos pg, ¿verdad?
¿Tiene sentido y, si es posible, cómo se haría, idealmente sin modificar ningún código fuente?
Puedes construir una imagen, enviarla a un repositorio y luego iniciarla usando ./launcher start-cmd app para obtener el comando docker para iniciar el contenedor (pero sustituirás tu repositorio de contenedores por el local).
Y sin embargo, luego necesitas migrar la base de datos, precompilar activos, y demás.
Si lo que quieres evitar es el tiempo de inactividad, la configuración de dos contenedores te permite construir un nuevo contenedor mientras el antiguo sigue en ejecución y luego se encarga de las migraciones y demás.
Si quieres ser extremadamente cuidadoso, puedes configurar SKIP_POST_DEPLOYMENT_MIGRATIONS en tu app.yml y luego ejecutar rake db:ensure_post_migrations db:migrate después de que se inicie el nuevo contenedor. No hacerlo puede migrar la base de datos de tal manera que el contenedor antiguo ya no pueda usarla. No es un problema frecuente, y entonces, no por mucho tiempo.
El tiempo de inactividad no es un problema para mí.
Dos aplicaciones que se me ocurren serían —virtualmente idénticas— pero no iguales.
Dos aplicaciones serían sitios diferentes, lo que significa diferentes bases de datos (dbs), volúmenes, puertos, nombres… pero tendrían el mismo —por así decirlo— discurso base (+ los mismos complementos, lo mismo que pueda ser crítico para ese núcleo/base).
En el mundo ideal de Discourse —si es que aún no existe— para tal escenario, una nueva imagen una vez construida por primera vez, podría usarse incluso directamente con herramientas de docker; y la base de datos o cualquier cosa que tuviera que ser “migrada” a tal nueva imagen/versión de Discourse, el proceso de inicio/arranque de tal contenedor “secundario” decidiría —quizás con la ayuda de variables de entorno— verificar/llevar a cabo las migraciones necesarias de las bases de datos.
La principal ventaja —en la que muchos ya deben haber pensado— es una única imagen para ambos (o muchos más si alguien hace eso) contenedores/aplicaciones.
Puedes hacer eso como describí. También hay un nuevo esquema en desarrollo que hace posible usar una sola imagen y no reconstruir. No es compatible, por lo que deberás buscar bien aquí o en github.