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.