Changement du bucket s3 pour les téléchargements

[Jite (Johannes Tegnér)]

Bonjour !

Nous sommes en train de migrer tous nos fichiers/images entre deux services compatibles S3 différents (les deux sont des espaces DigitalOcean, au cas où cela aurait de l’importance), et j’ai constaté que nous sommes dans une situation plutôt critique.

Je vais commencer par expliquer comment la migration a été effectuée :

1. Nous avons cloné/synchronisé le bucket initial vers le nouveau bucket avec rclone.
2. Toutes les références dans la page Fichiers de l’administration de Discourse ont été mises à jour vers les nouveaux points de terminaison.
3. Un re-baking a été lancé.

Malheureusement, cela n’a pas produit l’effet escompté, et désormais toutes les images sont « disparues » du forum. Elles sont toujours présentes dans le bucket S3 (et heureusement aussi dans l’ancien bucket), mais aucun message ne parvient à retrouver son image respective.

La taille du bucket est d’environ 60 Go, ce qui représente (même si ce n’est pas extrême) une quantité de données assez importante.

J’ai reconstruit le conteneur, j’ai essayé de récupérer des éléments depuis le tombstone, j’ai fait à peu près tout ce qui me passait par la tête ou que j’ai pu trouver dans le forum d’assistance ou via les tâches rake.
J’ai également tenté un remplacement de base de données (via discourse remap).

Chaque image ressemble actuellement à ceci dans le contenu baked :

<img src="https://xxxx.xxxxx.xx/images/transparent.png" alt="image" data-orig-src="upload://h8UudilPhVsGnNmvlJ5lQYEr8PT.jpeg" width="375" height="500">

Ce qui me fait penser que le b64-sha du lien est soit corrompu, soit que le hash de l’image a changé pour une raison quelconque.

Est-ce que quelqu’un a déjà fait cela auparavant ? Toutes les images sont-elles perdues à jamais ? (Oui, oui, j’ai une sauvegarde et les anciennes images, donc je sais qu’il existe une solution).

[Jite (Johannes Tegnér)]

Il vaut peut-être la peine de mentionner que j’ai également essayé d’utiliser l’URI CDN fourni pour le bucket des espaces (avec une rebake).

[Jite (Johannes Tegnér)]

Résultat des uploads manquants :

rake posts:missing_uploads
Recherche des uploads manquants sur : default
Correction des uploads manquants :
🚫
17 075 uploads de publications sont manquants.

16 906 uploads sont manquants.
1 sur 16 906 est un upload de l'ancien schéma.
14 646 des 139 801 publications sont concernées.

Les post_uploads contiennent 3 448 entrées
Les optimized_images contiennent 25 681 entrées
Les uploads contiennent 5 764 entrées

[pfaffman (Jay Pfaffman)]

Vous pouvez consulter Moving from one S3 bucket to another

Je pense avoir un brouillon de la procédure que je tenterai de publier demain.

[Jite (Johannes Tegnér)]

Cela serait très utile, merci beaucoup !

[pfaffman (Jay Pfaffman)]

Salut @Jite !

Voyez si cela fonctionne pour vous. Si c’est le cas, je procéderai à la création d’un vrai howto.

Anciens buckets

Cela suppose que vous pouvez installer et configurer un outil pour déplacer vos données de votre ancien bucket vers une machine locale, puis faire de même depuis le local vers le nouveau bucket. Consultez aws cli sync (qui peut être configuré pour des buckets non AWS) et gsutil rsync pour plus d’informations. Si vous avez d’énormes quantités de données ou si vous déplacez des données entre des buckets chez le même fournisseur, vous voudrez peut-être explorer des méthodes qui transfèrent les données directement entre les buckets.

Placez-vous dans un répertoire adapté pour servir d’espace temporaire (par exemple, mkdir temp-bucket; cd temp-bucket) avant d’exécuter quelque chose comme ce qui suit. Ces exemples incluent les options -n et --dry-run pour vous montrer ce qui se passerait. Si cela correspond à ce que vous souhaitez, exécutez à nouveau la commande sans cette option.

Déplacer les anciennes données de l’ancien bucket vers le local

    gsutil  rsync -r -n  gs://=OLD= .

ou

    aws s3 sync s3://=OLD= .

Déplacer les données du local vers le nouveau bucket

    gsutil rsync -r -n . gs://=NEW=

ou

    aws s3 sync . s3://=NEW=

Mettre à jour la base de données pour utiliser le nouveau bucket

Vous exécuterez ces commandes dans la console Rails. Pour y accéder, faites :

cd /var/discourse
./launcher enter app
rails c

Pour le nouveau bucket, téléchargez une image avec la nouvelle configuration et faites ceci :

Upload.last.url

Vous devriez voir quelque chose comme :

=> "//discourse-bucket.s3.dualstack.us-east-2.amazonaws.com/`original/2X/7/12345fbea574afc4e02db80107e6682430aede2c.png"

Vous obtiendrez alors discourse-bucket.s3.dualstack.us-east-2.amazonaws.com pour le nouveau bucket. Obtenez de la même manière le nom d’hôte de l’ancien bucket à partir de ce qui précède.

Utilisez ceci pour vérifier que vos uploads sont bien là où vous le pensez :

Upload.order(Arel.sql('RANDOM()')).limit(10).pluck(:id, :url)

Maintenant, vous mettrez à jour la base de données pour utiliser le nouveau bucket plutôt que l’ancien. DbHelper.remap remplacera les occurrences dans toutes les tables.

DbHelper.remap("//=OLDHOST=/","//=NEWHOST=/")

Le passage à AWS peut nécessiter de vider votre s3_endpoint.

REMARQUE : Si vous avez un s3_endpoint défini dans vos SiteSettings dans la base de données et que vous passez à AWS (où aucun endpoint n’est nécessaire), vous devrez alors effacer ce paramètre de site après avoir construit le nouveau conteneur avec les paramètres mis à jour (ou après avoir restauré une base de données qui le contient).

Rebake des posts qui font référence au bucket plutôt qu’au CDN S3

Si vous avez des posts qui lient directement vers le nouveau bucket S3 (peut-être que vous n’aviez pas défini d’s3_cdn_url auparavant), voici comment rebake uniquement les posts qui en ont besoin.

Récupérez les posts :

  posts=Post.where("cooked like '%=NEWHOST=%'")

Voyez combien il y en a :

  posts.count

Rebakez ces posts :

  posts.each do |p| p.rebake! end

Ou, remplacez simplement le bucket par le CDN :

posts.each do |p|
  p.cooked.gsub!(/=NEWHOST=/,"=CDN=")
  p.save!
end

[Jite (Johannes Tegnér)]

Merci pour votre réponse.

C’est essentiellement ce que j’ai fait la dernière fois, mais j’ai réessayé. Le problème est que posts.count renvoie 0. Tous les posts contiennent le fichier transperent.png dans le contenu cuisiné et comportent un hachage dans le contenu brut.

Y a-t-il un moyen de faire en sorte que l’image soit résolue correctement lors de la cuisson ?

[pfaffman (Jay Pfaffman)]

Hmm. D’accord. Ce changement bidouillé ne sert qu’à éviter la recréation. Si une recréation échoue, c’est qu’autre chose ne va pas. Peut-être que les ressources ne sont pas là où Discourse le pense ?

[Jite (Johannes Tegnér)]

Eh bien, c’est possible, mais le « déplacement » était essentiellement un transfert 1:1 de tous les fichiers du bucket, hehe…

[pfaffman (Jay Pfaffman)]

Ainsi, vous pouvez remplacer l’ancienne URL du bucket par la nouvelle et cela fonctionne ?

Les valeurs dans Uploads semblent-elles correctes ?

[Jite (Johannes Tegnér)]

J’ai un peu peur que le fait de revenir à l’ancien bucket ne déclenche un travail pour déplacer tout vers la tombe, car ils sont maintenant considérés comme « anciens ». Mais oui, la base de données semble pointer vers les images correctes (nouvel emplacement). C’est essentiellement les anciens posts qui ne résolvent pas vers l’image correcte (je suppose…).

[Jite (Johannes Tegnér)]

Après avoir exécuté la tâche Rake de récupération des tombstones, puis la tâche Rake de correction des pièces jointes manquantes, j’ai enfin réussi à lancer la « correction » des images.
Il semble qu’elles soient téléchargées puis réuploadees, ce qui prend beaucoup de temps et consomme beaucoup de ressources, mais au moins les utilisateurs retrouveront leurs images !

Merci pour votre aide @pfaffman

[system (system) A fermé ce sujet ()]

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