Actualmente estoy en proceso de migrar nuestro servidor desde una implementación existente basada en Bitnami (una versión bastante antigua) a la instalación oficialmente soportada en AWS utilizando la última versión de Discourse. Esta nueva instalación tiene instancias externas de Elasticache y RDS y también utilizará S3 para copias de seguridad y cargas.
Tengo 2 preguntas:
El servidor antiguo de Discourse tiene una versión bastante antigua; ¿al realizar la copia de seguridad/restauración en el nuevo servidor de Discourse se ejecutarán automáticamente todos los comandos de actualización relevantes?
Si copio el archivo de copia de seguridad en el nuevo contenedor Docker de Discourse en el nuevo servidor e inicio la restauración desde la línea de comandos, ¿se sobrescribirán los nuevos valores de bucket que establecí en mi configuración como parte de la restauración o se utilizarán mis nuevos valores? Supongo que mi nueva base de datos se rellena a partir de la copia de seguridad y luego, cuando salgo del contenedor y ejecuto ./launcher rebuild app, se utilizarán mis nuevos valores de S3.
Si mis suposiciones son correctas, entonces antes de realizar la restauración, supongo que debería copiar el contenido de los buckets S3 antiguos a los nuevos, ¿verdad?
¿Hay alguna otra complicación al realizar este tipo de migración con una copia de seguridad?
Quizás me estoy perdiendo algo, pero ¿por qué estáis creando nuevos buckets? Un nuevo bucket de copia de seguridad con las reglas de ciclo de vida apropiadas parece estar bien, pero si vuestra instancia de Discourse existente está utilizando un bucket de carga de S3, tendréis algunos problemas.
No estoy 100% seguro de que la migración desde Bitnami funcione sin problemas, por lo que no queremos afectar ningún dato existente en caso de que necesitemos abortar la migración.
Cambiamos el nombre de nuestros buckets, así que pensamos que sería más fácil tener 2 buckets completamente nuevos para esto.
El punto 1 es el que más me preocupa, así que estoy siendo extra cauteloso.
¿Qué problemas prevés con el nuevo bucket de subidas? El antiguo servidor de Discourse se pondrá en modo de solo lectura. El plan es que una vez que el nuevo servidor esté activo y validado, detendremos nuestro servidor antiguo, cambiaremos el DNS al nuevo servidor y luego purgaremos la caché en la CDN (Cloudfront) y luego lo abriremos al público.
Me perdí que ibas a copiar los datos de los contenedores antiguos. Eché un vistazo a AWS, parece sencillo. Si fuera yo, no me molestaría en cambiar los contenedores antes de migrar a AWS o a un nuevo servidor en otro lugar.
[quote=“stevejr, post:1, topic:395948”]a la instalación oficialmente compatible en AWS utilizando la última versión de Discourse.
[/quote]
¿Oficialmente compatible? No estoy tan seguro de eso.
Sugiero encarecidamente que actualices Discourse antes de la migración a un nuevo servidor.
En la instancia antigua, sugiero que muevas la configuración de S3 a app.yml si no está allí ya antes de la migración.
Tengo mucha curiosidad sobre cómo realizar este tipo de instalación aporta valor añadido.
A partir de las numerosas publicaciones sobre instalaciones no compatibles, parece que causa más problemas que beneficios, a menos que la gente las haga para aprender/experimentar.
Dicha configuración podría ser una instalación no compatible desde el punto de vista de Discourse, pero desde la perspectiva de una organización de TI empresarial, RDS y Elasticache podrían ser estándar y la instalación estándar de Discourse sería la extraña.
Como mencionó @RGJ, nuestra infraestructura empresarial utiliza servicios externos para cosas como caché, base de datos, etc., de ahí Elasticache y RDS. Esto significa que podemos tener copias de seguridad completas y redundancia para estos servicios, y también ayuda con los controles de seguridad. Esta es una instalación oficial/soportada desde el punto de vista de Discourse; solo utiliza un conjunto diferente de plantillas; usamos discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (quizás usar la palabra estándar fue un poco engañoso, disculpas).
Entonces, parece que primero deberíamos actualizar los nombres de nuestros buckets para la instalación existente y luego realizar la migración al nuevo servidor. Actualizar la instalación existente a la última versión no es una opción; experimentamos problemas con la actualización de Bitnami anteriormente, de ahí el cambio al método de instalación oficial.
Sin embargo, ¿puedo preguntar qué problemas podrían ocurrir si realizamos la restauración con los buckets existentes y luego actualizamos el app.yml para que haga referencia a los nuevos buckets? ¿No tienen precedencia todas las variables de entorno DISCOURSE_ sobre cualquier configuración en la base de datos (si corresponde)? ¿O hay algo más que podría causar un problema?
Ya que si lo haces antes de la migración y las cosas salen mal, tendrás el problema en la instancia de Bitnami más antigua en lugar de en tu instancia estándar recién instalada. Y, además de la versión antigua, incluso la mención de la palabra Bitnami hará que recibas mucho, mucho menos soporte aquí en meta.
Una pregunta más si me lo permites: cuando ejecuto la restauración desde la línea de comandos dentro del contenedor de Discourse, ¿utiliza la configuración existente de /var/www/discourse/config/discourse.conf para los detalles sobre la conexión a la base de datos, la conexión a Redis, etc., o sobrescribe esa configuración con lo que hay en el archivo de copia de seguridad?
discourse.conf se genera a partir de app.yml, no se incluye en el archivo de copia de seguridad.
Generalmente, lo que está en discourse.conf anula la configuración del sitio.
Por lo tanto, si tienes setting_foo en tu base de datos, puedes anularlo definiendo DISCOURSE_SETTING_FOO en tu app.yml, lo que luego generará setting_foo en discourse.conf.
Apuntar un contenedor de Discourse a un servidor externo de postgresql y redis usando nuestra imagen de contenedor con nuestras herramientas es una instalación compatible.
RDS[1] es Postgresql, y Elasticache es Redis, esto está bien.
Esto debería estar bien, hacemos esto para las personas que se mudan a nuestro hosting.
Mi preferencia es mantener el proceso lo más simple posible, así que si puedes ejecutar una copia de seguridad completa (incluyendo subidas) en el servidor antiguo y restaurarla en el nuevo, eso te permite probar completamente la nueva configuración sin ningún impacto en la antigua.
Haré la copia de seguridad/restauración sin cambiar los nombres de los buckets como también sugirió @RGJ. Como dije, mi preocupación era no afectar los datos existentes del servidor de ninguna manera, pero si hago una copia de seguridad de los buckets existentes primero y me aseguro de que el servidor existente esté en modo de solo lectura durante la migración, creo que la integridad de los datos subidos en los buckets está bastante bien protegida.
