Estoy intentando migrar Discourse de un alojamiento personal a un servidor Amazon LightSail. He buscado en el foro y leído todas las publicaciones sobre la migración de servidores y la configuración de Discourse:
Exportar una copia de seguridad del Discourse existente (actualmente la copia de seguridad está configurada para guardarse en S3, pero entiendo que esto será una copia de seguridad manual de archivos)
Importar la copia de seguridad al nuevo Discourse (manualmente, ya que, según entiendo, no puede recuperarla desde S3)
Estoy un poco atascado sobre cómo realizar el paso 1, dado que tengo algunas restricciones: tengo un único nombre de dominio y quiero mantener el mismo nombre de dominio para el nuevo servidor, y no quiero tiempo de inactividad (mi objetivo es completar la configuración del nuevo servidor, restaurar la copia de seguridad y, finalmente, cambiar la entrada DNS para que apunte al nuevo servidor, evitando así cualquier tiempo de inactividad, ya que ambos servidores estarán funcionando al mismo tiempo).
Según mi comprensión, al configurar el nuevo servidor de Discourse, puedo copiar el archivo app.yml del servidor existente al nuevo servidor y luego ejecutar discourse-setup. El problema que veo aquí es que, al hacerlo, se utilizará el mismo nombre DNS que el servidor existente (que es lo que quiero), pero prevo dos problemas que estoy tratando de resolver:
Let’s Encrypt no generará un certificado SSL para el nuevo servidor, ya que el nombre de dominio todavía apunta al servidor antiguo.
Sin el certificado SSL (la configuración del servidor antiguo está establecida para usar solo SSL, lo cual se heredará en app.yml), el servidor no se iniciará.
He intentado conectarme al servidor de Discourse utilizando una redirección de nombre DNS, pero si la URL introducida no coincide con la configuración de app.yml, ya sea NGINX o Discourse no funcionará; obtendrás un error en el navegador al intentar conectarte. Por lo tanto, sin una interfaz web, no puedo iniciar el proceso de restauración.
Entonces, ¿cómo completo la configuración del nuevo servidor de Discourse utilizando el app.yml del servidor existente y luego restauro la copia de seguridad, seguido de un cambio de DNS? ¿O hay una forma más fácil de hacerlo?
Si no vas a usar el mismo bucket de S3, existe una configuración oculta que obliga a la copia de seguridad a descargar los archivos de S3. Puedes buscar el nombre en el archivo de configuración y establecerlo en la consola de Rails. Hay un tema que lo discute, pero quizás sea más fácil buscar en settings.yml.
No necesitas ejecutar discourse-setup, solo copia app.yml y reconstruye.
Puedes sincronizar con rsync los certificados de Let’s Encrypt. De hecho, puedes copiar todo el directorio /var/discourse (quizás excluyendo algunos registros, etc.).
El objetivo ideal es hacer un ‘lift and shift’, pero eso no es posible con Amazon Lightsail, ya que no se puede importar una imagen existente. Por lo tanto, sí, se utilizaría exactamente el mismo S3.
Parece que tu enfoque se acerca más al ‘lift and shift’. Si entiendo bien lo que dices, ¿puedo simplemente empaquetar con tar/gz toda la carpeta /var/discourse del servidor original y desempaquetarla en el nuevo servidor, seguido de un discourse start, y luego simplemente redirigir el DNS al servidor bee? ¿Es eso todo? ¿Necesito reconstruir Discourse en el nuevo servidor? ¿Qué pasa con Nginx, Docker y otras dependencias fuera de la carpeta?
Gracias. Aparentemente, el proceso de “lift n shift” no fue tan limpio como pensaba; hay algunas verificaciones que deben realizarse antes y después para garantizar una operación de “lift n shift” fluida (Postgres se actualizó de 12.0 a 13.0, lo que me enseñó algunas lecciones sobre el proceso de “lift n shift”). Aquí tienes una guía paso a paso para referencia futura de quienes intenten migrar a un servidor Amazon LightSail (1 GB de RAM):
Servidor original
Crea una copia de seguridad en S3
cd /var/discourse
./launcher rebuild # obtén la última compilación para una transición sencilla
./launcher cleanup # límpialo para eliminar datos antiguos y reducir el tamaño del paquete
./launcher stop app # no hacer esto provoca un fallo al intentar volver a compilarlo más tarde con Postgres
tar -zcvf /var/discourse discourse.tar.gz
Nuevo servidor Amazon LightSail
Instala la imagen Ubuntu 20.20 desde Amazon (1 GB de RAM)
Crea 2 GB de memoria swap # no hacer esto puede provocar que la compilación falle
Configura vm.overcommit_memory=1 # no hacer esto puede provocar un fallo con Postgres durante la compilación
Transfiere por FTPS discourse.tar.gz desde el servidor original
tar -zxvf discourse.tar.gz -C /
cd /var/discourse
Establece UNICORN_WORKERS en app.yml a 2 # aumentarlo más allá de 2 con 1 GB de RAM podría provocar intercambio y estrangulamiento debido a una actividad excesiva del disco
./launcher rebuild
Cambia el DNS para que apunte al nuevo servidor de Amazon
¿Existe una forma más sencilla de migrar servidores (lift n shift) sin tener que pasar por todo el proceso de configuración de Discourse?
¿Te refieres a no ejecutar discourse-setup o te refieres a no construir el contenedor necesario para ejecutar Discourse? Si te refieres a lo segundo, es posible empujando la imagen antigua a un repositorio que el nuevo servidor pueda utilizar, pero eso no es algo que un principiante pueda manejar fácilmente.
Tu proceso se complicó con la actualización a PG13. Podría haber sido un poco más fácil construir una nueva imagen desde cero en el nuevo servidor y restaurar la copia de seguridad desde la antigua, pero aún tendrías algunos detalles complicados para que el nuevo servidor obtenga los certificados de Let’s Encrypt.
Sí, eso fue lo único que me impidió ejecutar ./discourse-setup en el nuevo servidor y luego restaurar desde la imagen de S3 (y cómo hacerlo sin acceso a la consola de administración web, ya que el DNS seguiría apuntando al servidor antiguo y, según tengo entendido, Discourse no responderá a una dirección IP en el navegador). Como tenía un sistema en vivo y necesitaba cambiar el DNS de un momento a otro del sistema antiguo al nuevo, la falta de certificados de Let’s Encrypt fue el único obstáculo para mí.
Si hay una manera de transferir los certificados del sistema antiguo al nuevo, completar ./discourse-setup sin errores de Let’s Encrypt y restaurar desde la copia de seguridad de S3 sin la consola web, eso sería una forma más sencilla de hacerlo.
Si copias los archivos yml dentro de containers, no necesitarás discourse-setup (puede ajustar los parámetros de memoria si son diferentes en el nuevo servidor, pero podrías hacerlo después). Solo ejecuta ./launcher rebuild app.
Vale, creo que entiendo lo que dices, pero para asegurarme, permíteme reformular mi comprensión.
En el servidor original, estaba configurado para hacer copias de seguridad de Discourse en S3 (que incluyen la configuración y el contenido del sitio).
Al copiar los archivos yml desde los containers, se trasladará toda la configuración del servidor original al nuevo servidor. Así, en el nuevo servidor ya no será necesario ejecutar discourse-setup; en su lugar, al ejecutar ./launcher rebuild app se utilizará la configuración del servidor original para descargar la última imagen y configurar Discourse.
Ahora hay dos asuntos pendientes:
¿Cómo se transfieren los certificados de Let’s Encrypt (ya que el DNS aún apunta al servidor original, por lo que no se pueden recrear, y supongo que esto debe hacerse antes de ejecutar ./launcher rebuild app)?
¿Cómo se restaura Discourse (configuración + contenido) desde la copia de seguridad de S3 después de la reconstrucción? Dado que el DNS aún apunta al servidor original, ¿hay alguna manera de acceder a la interfaz web de administración de Discourse mediante una dirección IP o localhost, o se puede restaurar la copia de seguridad de S3 desde la consola?
Gracias por los pasos detallados, acabo de tener que hacer algo similar, mudándome a un nuevo host.
Como el sitio estaba funcionando, no me gustó tener que pasar por las copias de seguridad, así que seguí los pasos aquí.
Casi funcionó, pero la reconstrucción en el nuevo host falló.
Resulta que el mapeo UID/GID no era exactamente el mismo en los dos hosts, por lo que al iniciar Postgres se rompería debido a la propiedad incorrecta de la carpeta de datos.
Hay un detalle adicional para el escenario en esta publicación, y es que el contenedor no se construye, por lo que ./launcher enter app no funciona en esta etapa. Como la reconstrucción tardaría bastante tiempo, pude usar docker ps para obtener el nombre del contenedor que estaba realizando la reconstrucción y luego entrar en el contenedor:
La reconstrucción luego falla (o no puedes detenerla con CTRL+C). Después de que se detiene, simplemente ejecútala de nuevo y los permisos se arreglan:
.