Esta es una configuración avanzada. No sigas esto a menos que tengas experiencia con la administración de servidores Linux y Docker. También debes prestar mucha atención a los commits de discourse_docker para asegurarte de notar si hay un aumento de versión para postgres o redis.
Conversión de tu configuración actual
Logré migrar a dos contenedores. Si alguien más necesita instrucciones, así es como funcionó para mí.
El proceso incluye respaldo, configuración de contenedores separados de web y datos, y restauración de datos.
-
Haz una copia de seguridad de tu instancia de discourse y descarga la copia de seguridad. Puedes seguir la guía sencilla o respaldar y restaurar manualmente más tarde.
-
Detén el contenedor independiente actual
./launcher stop app -
Copia
web_only.ymlydata.ymldesamples/acontainers/y renómbralos como desees, por ejemplo,web_rocks.ymlydata2.yml. -
Si los renombras, presta atención a las entradas
volumes:endata.ymlyweb_only.yml
Si renombrasteweb_only.ymlaweb_rocks.yml, debes modificar la entrada enWeb_rocks.ymlde la siguiente manera:
volumes:
- volume:
host: /var/discourse/shared/web_rocks
guest: /shared
- volume:
host: /var/discourse/shared/web_rocks/log/var-log
guest: /var/log
De manera similar, haz la edición correspondiente en data.yml.
Configuración del contenedor de datos
Comienza con data.yml y establece una contraseña para la base de datos. Luego:
- Ve a la carpeta raíz del contenedor
/var/discourse - ejecuta
./launcher bootstrap data2(data2 o el nombre nuevo que le hayas dado) - ejecuta
./launcher start data2(usando el nombre nuevo de nuevo) - si todo va bien, puedes conectarte al contenedor a través de:
./launcher enter data2(de nuevo usando el nombre nuevo) - Sal del contenedor con
exit.
Configuración del contenedor web
Modifiquemos web_only.yml.
Primero, cambia la plantilla y expón los puertos como lo hace tu app.yml.
En segundo lugar, asegúrate de estar enlazando al contenedor de datos correcto. Si renombraste data.yml a ‘algo_mas’, ponlo en name.
# Usa la clave 'links' para enlazar contenedores, es decir, usa el flag Docker --link.
links:
- link:
name: data
alias: data
Aunque ya no queramos exponer ssh ni ningún otro puerto, aún necesitarás exponer los puertos 80 y 443 para el acceso web. Esto depende de si tienes un nginx ejecutándose al frente y cómo conectas el contenedor con él.
En algún lugar de ahí encontrarás este bloque:
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: mypassword
DISCOURSE_DB_HOST: data
DISCOURSE_REDIS_HOST: data
- Ingresa la contraseña que estableciste dentro del contenedor de datos.
- Ingresa el alias del contenedor de datos que acabas de escribir. Para
DB_HOSTy paraREDIS_HOST. Debe coincidir con el bloque de enlaces que mencionamos. - Probablemente no cambiaste
DB_USERNAME.
Encontrarás los valores para DISCOURSE_DEVELOPER_EMAILS y DISCOURSE_HOSTNAME y muchos más. Ya tienes estos valores en tu app.yml. Cópialos de ahí.
En la sección de hooks (ganchos), recuerda configurar cualquier plugin adicional que ya uses dentro de app.yml.
Ahora deberías estar listo para hacer el bootstrap:
./launcher bootstrap web_only (de nuevo con tu nombre nuevo/propio)
Una vez hecho el bootstrap, puedes iniciar web_only (usa tu nombre nuevo):
./launcher start web_only
Cuando Discourse esté listo, inicia sesión y restaura tu sitio.
Después de esto, todo volvió a funcionar para mí y mi instalación de discourse se ejecutaba de nuevo, pero ahora en dos contenedores separados.
Cómo actualizar cuando se usan contenedores web y de datos separados
Si no te importan los pocos minutos de inactividad, o cuando los datos necesitan ser actualizados. Los cambios en postgres y redis son infrecuentes, y dejar el contenedor de datos en ejecución es lo que permite construir un nuevo contenedor web_only mientras el antiguo se ejecuta.
./launcher stop web_only && ./launcher rebuild data && ./launcher rebuild web_only
Eso funciona para una actualización menor de Postgres y/o una actualización de redis.
Si te importa cada minuto de inactividad y los datos no necesitan ser actualizados (que es la mayor parte del tiempo):
actualizar solo web_only:
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only
Es suficiente reconstruir web_only y omitir data excepto cuando hay una actualización de postgres o redis. Esas ocurren en el orden de una vez al año y verás un anuncio como PostgreSQL 15 update cuando suceda, aunque las actualizaciones de redis y las actualizaciones menores de postgres no se anuncian tan claramente.
Reconstruir los datos requiere tiempo de inactividad (por la misma razón que la versión de contenedor único: no puedes actualizar postgres mientras otro proceso está accediendo a los mismos archivos de base de datos. Además, cuando construyes un nuevo contenedor de datos, debes destruir e iniciar el contenedor web_only porque intentará conectarse al contenedor antiguo).
No necesitas reconstruir el contenedor de datos a menudo (por eso este método ahorra tiempo de inactividad). Debes prestar atención a cuándo hay una actualización en postgres o redis; el front end no lo sabrá; esta es una configuración avanzada que requiere más atención que un contenedor único.
Administración de una instalación de dos contenedores
@pfaffman creará un tema sobre esto algún día, pero mientras tanto, existe esto: Managing a Two-Container Installation - Documentation - Literate Computing Support
