Hemos estado construyendo, probando y buscando intencionalmente fallos en nuestro foro de Discourse antes de lanzar todo a producción. Acabo de migrar mi foro de prueba, que tenía las cargas en S3 habilitadas, de un servidor a otro y, al restaurarlo, todas las URL de cualquier archivo adjunto se reescribieron con la URL del foro y no con la de S3…
Afortunadamente, este es un foro de prueba, así que no nos importa demasiado el dato, pero me gustaría:
A. Arreglarlo de todos modos.
B. Encontrar una forma de mitigar/evitar que esto ocurra en producción.
No solo afectó a las publicaciones, sino también a todas las imágenes, medios, contenido y avatares (lo cual es bastante grave)…
Antes de restaurar, puedes configurar S3 en el sitio de destino en tu app.yml (no a través del panel de administración). Una vez que confirmes que está configurado y que puedes acceder al bucket correcto, puedes proceder con la restauración y los medios deberían enlazarse correctamente.
Eso es exactamente lo que hicimos y así es como terminamos en esa situación.
Copié el archivo app.yml tal cual estaba al destino y luego hice una copia de seguridad desde el original. El problema fue la restauración, ya que al restaurar, las URL se reescribieron, a pesar de que nada había cambiado y aún teníamos las cargas en S3 activadas.
Finalmente, lo resolvimos con un rebake (creemos que fue eso; el sistema de caché de Discourse es muy agresivo, así que entre las muchas soluciones que probamos, en realidad no sabemos cuál funcionó). Sin embargo, siguen sin responderse las preguntas sobre cómo realizar migraciones con mínimos problemas o incluso cómo restaurar desde una copia de seguridad si es necesario en producción.
Eso suena a que configuraste S3 mediante la configuración del sitio, no mediante variables de entorno como sugirió Kris. El proceso de restauración necesita conocer S3, y eso no es posible con la configuración del sitio.
También puedes crear una copia de seguridad sin archivos adjuntos desde la consola si lo deseas: discourse backup --sql_only
Restaurar una copia de seguridad de este tipo no volverá a escribir las URL de los archivos adjuntos. Por lo tanto, mientras tu nuevo servidor tenga acceso al mismo bucket de S3, esto funcionará.
La configuración de S3 está en app.yml. No en la configuración del sitio.
Edición:
Me doy cuenta de que no estoy siendo demasiado explicativo y no tengo la intención de ocultar detalles.
Utilizamos OVH S3 y está configurado en app.yml.
Hice una copia de seguridad de nuestro foro de prueba sin las cargas, pero en ese momento S3 seguía estando activado.
Luego lo restauré en el nuevo sitio con el mismo app.yml y fue allí donde comenzó el problema. Para ser claro, está solucionado ahora mismo, pero no estoy seguro de si fue porque lo volví a crear varias veces o si Discourse hacía caché de forma agresiva. Por eso necesito saber cómo hacerlo correctamente y acertar a la primera. Mi temor es que, si alguna vez necesito restaurar una copia de seguridad en nuestra instancia de producción y nos encontramos con esto, necesite saber exactamente cómo solucionarlo lo antes posible antes de que los usuarios lo noten.
Como dije, si deseas restaurar en un servidor que utiliza el mismo bucket de S3, asegúrate de tener S3 configurado en app.yml y crea una copia de seguridad sin los archivos subidos (discourse backup --sql_only). Las URL de las cargas no se reescribirán cuando la copia de seguridad no contenga archivos subidos.
Si deseas restaurar en un servidor que utiliza un bucket de S3 diferente o que no tiene ninguna configuración de S3, utiliza una copia de seguridad completa con los archivos subidos. Las URL de las cargas se reescribirán durante la restauración.
¿Estás 100% seguro de que configuraste el S3 de OVH mediante variables de entorno en app.yml en ambos servidores y utilizaste una copia de seguridad sin archivos subidos (extensión de archivo .sql.gz)?
Cuando lo restauré inicialmente con las cargas realizadas, en realidad se rompió, así que tuve que borrarlo todo por completo y empezar de nuevo esta vez, haciendo una copia de seguridad sin las cargas. Ahí es donde comenzó el problema. Las URLs aún estaban escritas incorrectamente.
No estoy seguro de cómo ocurrió eso. El proceso de restauración omite todo el código relacionado con las subidas (incluida la reescritura de las URL de las subidas) cuando restauras un archivo .sql.gz.
¿Quizás estamos hablando de cosas diferentes? Me refiero a la columna url en la tabla uploads, que normalmente es //tu-s3-bucket/original/... frente a /uploads/original en local.
Una advertencia al restaurar un archivo .sql.gz es que no se reescriben las URL en absoluto. Se espera que el servidor sea accesible a través del mismo nombre de host que el servidor donde se creó la copia de seguridad. Necesitarás volver a mapear las URL si cambias los nombres de host.
No se cambiaron nombres de host. Solo se actualizaron los registros A, se hizo una copia de seguridad y listo.
Faltaban los avatares de los usuarios (y eso fue porque no migré la carpeta de cargas). Las imágenes de S3 para adjuntos/medios se reescribieron para la URL del foro, no para la URL del bucket.
Así que, aunque esperaba que las URLs para las cargas de S3 mencionadas anteriormente se escribieran como https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized, en realidad eran https://forum.somedomainhere.com/uploads/optimized, lo que, por supuesto, no funcionará.
Literalmente puedo levantar otra máquina virtual y hacer una restauración directa si quieres que verifique todos los pasos que he dado.
Lo restauré simplemente restaurando desde el archivo sql.gz que estaba almacenado en S3, y hasta ahora, lo único que se rompió fueron algunas avatares de usuario y algunas publicaciones, pero supongo que fue porque no se subieron a S3 cuando se crearon.
En un entorno de producción, asumiendo que todo salga bien desde el lanzamiento y todo esté en S3… si restauro desde una copia de seguridad, no tendré el mismo problema extraño que desde la publicación inicial, ¿es correcto?
