Migration hébergé vers auto-hébergé : les uploads passés font toujours référence à l'infra Discourse

Soutien
1

Vérifié : Images lost when migrating to self-hosting, posts:rebake n’a aucun effet bénéfique.

Problème
Nous avons suivi les instructions officielles et créé une instance Lightsail, à partir de laquelle nous avons téléchargé une base de données depuis l’interface utilisateur de Discourse et l’avons appliquée pour obtenir 80% du chemin. L’idée était de passer à l’instance auto-hébergée tout en maintenant la variante précédente en ligne.

Une fois que nous avons une copie en direct de l’ancien forum. Nous commençons à migrer les images. Pour ce faire, nous annulons d’abord notre abonnement pour obtenir et migrer nos images.

Comme de nouvelles images seraient téléchargées sur l’instance auto-hébergée, nous n’aurions qu’à télécharger depuis l’instance hébergée avant la date de transition. Cela signifie que nous n’avons jamais utilisé la sauvegarde de la base de données fournie avec nos images et notre annulation ; comme nous avions déjà effectué la migration, elle était maintenant expirée.

J’observe trois comportements liés à ce point dans le temps.

  1. Les ressources référencées dans la sauvegarde (dump SQL, spécifiquement) pointent vers l’infrastructure Discourse
  2. Les ressources référencées* depuis la création sur la sauvegarde, par exemple les images des nouveaux messages, sont correctement référencées et trouvées sur notre infrastructure

Par conséquent, si je re-télécharge une ressource qui correspond au même hachage, elle pointera vers l’infrastructure Discourse. Par exemple : essayer de corriger le favicon en téléchargeant le même ne fonctionne pas. Je peux cependant télécharger n’importe quelle autre image aléatoire, et cela fonctionnera.

État actuel
D’après ce que je comprends, upload://<X> passe par un décodage b62 (et sha1 ?) pour le mapper au dossier public/uploads. Nous avons chacune de ces images :

Le dump que nous a fourni l’équipe Discourse contient un zip avec default/original/1X et il est actuellement visible dans /var/www/discourse/public/uploads/default/original/1X. Ce dernier dossier contient maintenant 329 éléments, le dump fourni en contenait 249 — cela me semble bon.

Cela signifie que les données devraient être découvrables, même si je ne trouve pas directement le téléchargement dans le dossier. Je cherche à comprendre cette relation, afin de pouvoir corriger le mappage d’une manière ou d’une autre. Initialement, cela ne semblait être qu’une simple substitution de chaîne, et cela a fonctionné pour certaines images. Certaines sont maintenant remplacées par un transparent.png, alors qu’auparavant, il s’agissait simplement d’une image inaccessible.

4

Si la re-cuisson a échoué, vous devriez essayer un remap pour rechercher/remplacer toutes les références à l’infrastructure Discourse et les remplacer par des liens relatifs.

5

Merci Richard !

Pour clarifier, en utilisant : Replace a string in all posts

En utilisant

rake posts:remap["find","replace","string",true]

Faire

rake posts:remap[
  "https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/",
  "/uploads/default/"
]

Le remplaçant alternatif pour le relatif serait "https://forum.everviz.com/uploads/default/"

Est-ce que le lien relatif est ce à quoi vous pensez ?

e : correction de l’url relative avec /

En une seule ligne :

rake posts:remap["https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/", "/uploads/default/"]
6

ça me semble bien ! vous voudrez ajouter une barre oblique devant

/uploads/default/

7

Avez-vous coché « inclure tous les téléchargements » lors de la sauvegarde de votre site hébergé ? Si vous étiez hébergé chez CDCK, il y avait un paramètre caché qu’ils devaient activer avant que vous puissiez effectuer une sauvegarde incluant tous les téléchargements. Je ne suis pas sûr si cela a changé maintenant, mais vous voudrez certainement coordonner avec votre fournisseur d’hébergement avant de procéder pour vous assurer que vous effectuez une sauvegarde complète (et pas seulement un vidage de SQL).

8

Mon fournisseur d’hébergement était Discourse, nous étions sur un plan mensuel. L’interface utilisateur hébergée indique de contacter team@discourse.com pour obtenir les fichiers téléchargés. Leur réponse a été que je devais annuler l’abonnement pour obtenir les fichiers.

Mais oui, comme mentionné, j’ai reçu uploads/original/1X

9

C’est une bonne astuce, mais je l’ai peut-être déjà fait :

root@...:/var/www/discourse$ rake posts:remap["//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/","/uploads/default/"]
Êtes-vous sûr de vouloir remplacer toutes les occurrences de la chaîne "//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/" par "/uploads/default/" ? (O/n)
O
Remappage
0 messages remappés !

Les liens étaient auparavant https://europe1.discourse-cdn.com/standard21/uploads/everviz/ sur le forum hébergé. C’est bien sûr la même chose, seulement via le CDN. Essayons de remapper.

1 message remappé.

Je trouve cette image curieuse :

image
image2272×1242 357 KB

Bien sûr, c’était avant d’exécuter toutes ces commandes aujourd’hui et avant de poster ici. Elle a été envoyée à l’équipe Discourse avant que je n’exécute certaines tâches rake et autres.

10

L’avez-vous fait ? Ils doivent activer un paramètre caché qui téléchargera les images de S3 et les inclura dans votre sauvegarde. Une sauvegarde normale n’inclut pas les images, mais seulement des liens vers celles-ci dans leurs buckets S3. L’annulation d’un abonnement déclenche cela automatiquement, je pense, mais j’ai eu des clients qui ont fait activer le paramètre simplement en demandant. Vous devriez soit annuler votre abonnement, soit demander à nouveau.

Si vous ne voulez pas procéder ainsi, vous devrez écrire un script qui téléchargera les images de S3 et mettra à jour la base de données Discourse en conséquence.

11

J’ai bien annulé et j’ai reçu les fichiers. Bien qu’il semble que la sauvegarde d’origine de la base de données Discourse référence le chemin dans S3. Essentiellement, j’ai tout ce dont j’ai besoin dans /var/www/discourse/uploads/original/1X.

J’ai utilisé un dump SQL téléchargé manuellement pour peupler l’instance, pas celui fourni avec les fichiers. Je craignais que ce dernier ne fournisse des chemins corrigés pour les images, ce qui s’est avéré ne pas être le cas.

Pour démontrer :


![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) = 1aec065017da50538fe5866ae91a6396185234e1.gif

https://forum.everviz.com/uploads/default/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

http://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" role="presentation" width="1" height="1" style="aspect-ratio: 1 / 1;" loading="lazy">

Ce qui précède est un cas particulier où la référence précédente à cdck… n’est qu’une image transparente.png. Quoi qu’il en soit, vous pouvez ouvrir le lien et voir qu’il existe.

12

Donc, je m’attendrais à avoir des problèmes.

Dans ce que je suppose être un message raw que vous avez inclus, avec la base de données incluse avec les fichiers, je m’attendrais à ce que le ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) fasse référence à votre stockage local, mais si quelqu’un collait explicitement un lien vers une image sur son bucket, quelque chose devrait être fait pour le corriger. Si l’image existait et que vous aviez le paramètre download-to-local activé, l’image du bucket serait téléchargée (si elle répondait aux critères du paramètre).

Je ne suis pas tout à fait sûr comment la dernière <img> dans votre exemple a pu être générée.

13

Le téléchargement en local est activé.

Pour le fichier lié, le vidage « officiel » ne comprend pas les chemins relatifs.

<img src="https://europe1.discourse-cdn.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif" alt="" data-base62-sha1="3Qa5S9sUTcc42dT4EFAbz5K0iJP" ...

Cette référence exacte de fichier pointe également vers cdck… à certains endroits.

Cela me semble un peu fou, mais je pourrais faire une sauvegarde maintenant. Et ensuite, écarter les références à l’infrastructure Discourse pour le chemin local dans le vidage lui-même, et le recharger.

Le dernier fichier pourrait faire référence à transparent.png parce que j’ai recuit le message, et que le fichier source n’était plus découvrable dans l’infrastructure Discourse. Je ne pense pas que nous soyons confrontés à une perte totale de données.

14

Si votre site est en ligne, vous iriez simplement corriger les choses dans Rails, dans la mesure du possible.

Mais cette <img> est un post traité, n’est-ce pas ? Pas le post brut ?

15

Le <img provient de la sauvegarde de la base de données. Je suppose qu’il est cuit. Le post cuit actuel fait référence à b62 comme upload://

Le cuit actuel est :

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" ...

Jusqu’à présent, je n’ai pas eu beaucoup de succès avec rake pour trouver et corriger les missing_uploads, remapper et recuire les posts.

Merci Jay pour toute ton aide !

16

Le fichier auquel il est fait référence dans la publication traitée fonctionne. Il n’y a pas de problème avec cela.

Si vous regardez dans les publications traitées du vidage de la base de données, alors vous regardez au mauvais endroit.

Vous avez maintenant un site en ligne, vous devez donc travailler à partir de là.

Que voyez-vous dans la publication brute ? Après une nouvelle cuisson de cette publication, qu’est-ce que la publication traitée montre qui n’est pas ce que vous attendez ?

Sans savoir exactement ce que vous avez fait, et ce qu’il y a dans les publications (brutes et traitées), il n’y a pas beaucoup de moyen d’aider. Puisque vous avez commencé avec une base de données qui est censée ne pas contenir les bonnes données, ce sujet ne sera pas utile aux autres.

17

J’ai fait ce que tout le monde m’avait dit de ne pas faire : trifouiller la base de données et son dumpfile. Actuellement, la plupart des choses fonctionnent, à l’exception de certains cas de :

<img src="https://forum.everviz.com/images/transparent.png"
alt="image" data-orig-src="upload://npqpp5O0wbL89nR9OXtP7Btu4hc.png"
width="517" height="90" style="aspect-ratio: 517 / 90;" loading="lazy">

Calculons le b62 et prenons son hexadécimal

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

Maintenant, essayons de le trouver dans /var/www/discourse/public/uploads :

find . -name '*a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba*'
./default/original/1X/a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba.png

Oui !

932×164 18.5 KB

Mais pourquoi est-ce transparent.png dans le post ? J’ai exécuté rake uploads:recover_from_tombstone et rake posts:rebake

Comment en suis-je arrivé là ?

La colonne des uploads dans la base de données, pour la table url, afficherait toujours cdck comme faisant partie de l’URL source des images. Je suis descendu dans la base de données depuis l’intérieur du conteneur :

postgres psql discourse

Puis

UPDATE uploads
SET url = REPLACE(
           url,
           '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/',
           '/uploads/default/'
         )
WHERE url LIKE '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/%';

Cela a montré des résultats prometteurs, où la plupart des images originales et des miniatures réapparaîtraient.

Une étape de plus : modification des dumpfiles
L’hypothèse est que Discourse est sans état* et que la seule chose dont nous devons nous soucier est ce qui se trouve dans la base de données. Je n’étais pas désireux de trifouiller avec des tâches rake ou ruby pour cela, car je ne suis pas très familier avec l’un ou l’autre ni avec les internes de Discourse. Je veux juste des résultats, rapidement.

*À l’exception du dossier public qui contient nos images. Nous pouvons néanmoins confirmer que nous avons tout ce dont nous avons besoin.

Nous téléchargeons donc une copie de la base de données depuis l’interface utilisateur, puis nous l’ouvrons dans VSCode et substituons progressivement les références cdck (bucket) et europe1 (bucket de CDN).

Par régressif, je veux dire que dans certains cas, vous verrez //... et dans d’autres cas, vous verrez https://. Par conséquent, vous devez d’abord faire correspondre et remplacer //..., sinon vous aurez des https: en trailing dans le fichier.

Ensuite, re-téléchargez le dumpfile modifié. Une partie de ce qui a rendu tout cela délicat est l’étape base62, qui rend un peu plus difficile de passer d’une représentation brute à l’URL d’image réelle.

18

Tâche terminée

Après avoir revérifié la taille de la table des uploads, j’ai remarqué qu’il nous manquait quelques centaines d’entrées. Je ne sais pas à quelle étape elles ont disparu. J’ai fusionné avec la sauvegarde de la base de données du passé à l’aide d’une jointure SQL de base à partir d’une table temporaire.

Comme je l’ai peut-être mentionné ci-dessus, l’URL demandée pour une image est celle qui est stockée dans la table des uploads, colonne url. Depuis la console Rails, j’ai remappé ces références CDN vers notre domaine local avec SQL sur la table des uploads.

Pourquoi ne pas utiliser la tâche Rake

Il y en a probablement quelques-unes qui sont correctes et une combinaison de celles-ci fonctionnerait. Cependant, lorsque vous pouvez observer le comportement actuel, vous savez ce que vous voulez et vous savez comment y parvenir—alors je trouve la limitation arbitraire.

Je tiens à remercier l’équipe Discourse et les bénévoles ici qui m’ont tous donné les informations dont j’avais besoin pour découvrir la solution, qui a fini par consister en quelques étapes.

1 « J'aime »
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.