Nous avons construit, testé et recherché délibérément des failles dans notre forum Discourse avant de déployer l’ensemble en production. Je viens de migrer mon forum de test, qui avait les téléversements S3 activés, d’un serveur vers un autre, et lors de la restauration, toutes les URL des éléments joints ont été réécrites vers l’URL du forum et non vers S3…
Heureusement, il s’agit d’un forum de test, donc nous nous soucions peu des données. Cependant, je souhaiterais :
A. Corriger cela.
B. Trouver un moyen d’atténuer/prévenir que cela se produise en production.
Ce n’était pas seulement les publications, mais toutes les images, les médias, le contenu et les avatars (ce qui est assez dramatique) qui ont été affectés…
Avant de restaurer, vous pouvez configurer S3 sur le site de destination dans votre app.yml (pas via le tableau de bord d’administration). Une fois que vous avez confirmé que la configuration est en place et que vous pouvez accéder au bon bucket, vous pouvez procéder à la restauration et les médias devraient être correctement liés.
Nous avons effectivement fait cela, et c’est ainsi que nous nous sommes retrouvés dans cette situation.
J’ai copié le fichier app.yml tel quel vers la destination, puis j’ai effectué une sauvegarde depuis l’original. C’est la restauration qui a posé problème : lors de la restauration, les URLs ont été réécrites, alors même que rien n’avait changé et que les uploads vers S3 restaient activés.
Nous avons fini par résoudre le problème grâce à une rebake (nous pensons, car le système de cache de Discourse est très agressif ; entre les nombreuses solutions que nous avons essayées, nous ne savons pas exactement ce qui a fonctionné). Cependant, les questions restent sans réponse : comment effectuer des migrations avec un minimum de problèmes, ou même restaurer à partir d’une sauvegarde si nécessaire en production ?
Cela ressemble à une configuration de S3 via les paramètres du site, et non via des variables d’environnement comme l’a suggéré Kris. Le processus de restauration doit connaître S3. Ce n’est pas possible avec les paramètres du site.
Vous pouvez également créer une sauvegarde sans les fichiers joints depuis la console, si vous le souhaitez : discourse backup --sql_only
La restauration d’une telle sauvegarde ne réécrira pas les URL des fichiers joints. Ainsi, tant que votre nouveau serveur a accès au même bucket S3, cela fonctionnera.
La configuration S3 se trouve dans app.yml. Pas dans les paramètres du site.
Édition :
Je réalise que je ne suis pas très explicatif et que je ne cherche pas à cacher des détails.
Nous utilisons OVH S3 et cela est configuré dans app.yml.
J’ai sauvegardé notre forum de test sans les fichiers uploadés, mais S3 était toujours activé à ce moment-là.
Ensuite, je l’ai restauré sur le nouveau site avec exactement le même app.yml, et c’est là que le problème a commencé. Pour être clair, c’est résolu pour le moment, mais je ne sais pas si c’est dû à mes multiples rebaking ou au cache agressif de Discourse. C’est pourquoi j’ai besoin de savoir comment faire cela correctement et obtenir le résultat du premier coup. Ma crainte est que, si jamais je dois restaurer une sauvegarde sur notre instance de production et que nous rencontrons ce problème, je dois savoir exactement comment le résoudre immédiatement avant que les utilisateurs ne s’en aperçoivent.