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.
Comme je l’ai dit, si vous souhaitez restaurer sur un serveur utilisant le même bucket S3, assurez-vous que S3 est configuré dans app.yml et créez une sauvegarde sans les fichiers uploadés (discourse backup --sql_only). Les URLs des uploads ne seront pas réécrites si la sauvegarde ne contient pas les fichiers uploadés.
Si vous souhaitez restaurer sur un serveur utilisant un bucket S3 différent, ou n’ayant aucune configuration S3, utilisez une sauvegarde complète incluant les fichiers uploadés. Les URLs des uploads seront réécrites lors de la restauration.
Êtes-vous certain à 100 % que vous avez configuré le S3 OVH via les variables d’environnement dans app.yml sur les deux serveurs et que vous avez utilisé une sauvegarde sans les fichiers uploadés (extension de fichier .sql.gz) ?
Lorsque je l’ai restauré initialement avec les téléchargements effectués, cela a en fait planté, alors j’ai dû tout effacer et recommencer, cette fois en faisant une sauvegarde sans les téléchargements. C’est là que le problème a commencé. Les URLs étaient toujours écrites incorrectement.
Je ne sais pas comment cela s’est produit. Le processus de restauration ignore tout le code lié aux uploads (y compris la réécriture des URL des uploads) lorsque vous restaurez un fichier .sql.gz.
Peut-être parlons-nous de choses différentes ? Je parle de la colonne url dans la table uploads, qui est généralement //your-s3-bucket/original/... par opposition à /uploads/original en local.
Une mise en garde concernant la restauration d’un fichier .sql.gz est qu’aucune URL n’est réécrite. Il s’attend à ce que le serveur soit accessible via le même nom d’hôte que le serveur sur lequel la sauvegarde a été créée. Vous devrez mapper les URL à nouveau si vous changez les noms d’hôte.
Aucun nom d’hôte n’a été modifié. Seuls les enregistrements A ont été mis à jour, sauvegardés et finalisés.
Les avatars des utilisateurs étaient manquants (car je n’avais pas migré le dossier uploads). Les images S3 pour les pièces jointes et les médias ont été réécrites pour l’URL du forum, et non l’URL du bucket.
Ainsi, alors que je m’attendais à ce que les URL des uploads S3 pour ce qui précède soient écrites sous la forme https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized, elles étaient en réalité https://forum.somedomainhere.com/uploads/optimized, ce qui, bien sûr, ne fonctionnera pas.
Je peux littéralement lancer une autre VM et effectuer une restauration complète si vous souhaitez que je vérifie toutes les étapes que j’ai effectuées.
Oui, s’il vous plaît faites-le. Et regardez la sortie de la restauration. Elle ne devrait pas mentionner de remappage d’URL lors de la restauration d’un fichier .sql.gz.
Je l’ai restauré en utilisant simplement la sauvegarde SQL stockée dans S3, et jusqu’à présent, seuls certains avatars d’utilisateurs et quelques publications ont été affectés, mais je suppose que cela venait du fait qu’ils n’avaient pas été téléchargés sur S3 lors de leur création.
Dans un environnement de production, en supposant que tout se passe bien dès le lancement et que tout est dans S3… si je restaure depuis une sauvegarde, je ne rencontrerai pas le même problème étrange que celui mentionné dans le premier post, c’est bien ça ?
