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.