Déplacement d'un bucket S3 vers un autre

Suite à la discussion de Comment déplacer mon bucket d’upload S3 d’un fournisseur à un autre ? :

Je tente de migrer d’un bucket GCP vers un bucket AWS S3. L’ancien système n’utilisait pas de CDN S3 (celui qui l’a configuré ne semblait pas vraiment savoir ce qu’il faisait, apparemment).

J’ai utilisé s3cmd pour synchroniser l’ancien bucket GCP vers un système de fichiers local, puis à nouveau pour envoyer les assets vers le nouveau bucket S3. Le système est désormais correctement configuré avec S3 et les CDN du site, comme décrit dans Utiliser un stockage objet pour les uploads (S3 et clones).

Le sujet lié ci-dessus suggérait d’utiliser rake posts:remap pour mettre à jour les publications (je suppose que je devrais aussi rebaker toutes les publications ? Ou du moins celles correspondant à l’ancien bucket ?).

Lorsque j’ai exécuté posts:remap, une seule publication a été remappée.

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

montre que toutes ces publications pointent vers l’ancien bucket… Ah, c’est le problème. Nous n’avons pas besoin de rake posts:remap mais de discourse remap comme décrit à l’adresse Change the domain name or rename your Discourse.

Oui, je pense.

Je vais voir pour le faire très prochainement. @Falco, de manière générale, voici les étapes :

  • créer un nouveau bucket et un CDN pour celui-ci, reconstruire le conteneur pour utiliser le nouveau bucket/CDN et s’assurer que cela fonctionne
  • configurer s3cmd pour l’ancien bucket et synchroniser les données vers le local
  • configurer s3cmd pour le nouveau bucket et synchroniser les données vers le nouveau bucket
  • exécuter discourse remap NOM-DE-DOMAINE-ANCIEN-BUCKET NOM-DE-DOMAINE-NOUVEAU-BUCKET
  • rebaker

Est-ce que cela vous semble correct ?

Si vous utilisez le même CDN pour l’ancien et le nouveau bucket, vous pourriez éviter de devoir rebaker, mais bien synchroniser le timing semble un peu délicat (on ne peut pas changer l’origine du CDN tant que les données ne sont pas dans le nouveau bucket, mais il faudrait s’assurer qu’aucune donnée n’est uploadée vers l’ancien bucket pendant le processus de synchronisation) — peut-être se contenter de dire que c’est possible.

2 « J'aime »

Peut-être que l’utilisation de l’interface de ligne de commande officielle AWS serait préférable pour un guide ?

Utilisez DbHelper.remap ici.

Pas nécessaire.

Utilisez le même CDN et changez simplement la source CDN dans le panneau CDN, ou utilisez un nouveau CDN et effectuez un remappage avec DbHelper.remap. Aucun rebake n’est nécessaire dans les deux cas.

2 « J'aime »

Ah. D’accord. Je vais jeter un coup d’œil. . . Est-il possible de faire fonctionner la CLI AWS avec des buckets non AWS ?

Salut Rafael. Je suis presque arrivé. Ma version actuelle de ce tutoriel utilise aws cli et gsutil pour synchroniser de l’ancien vers le local, puis du local vers le nouveau (je fais simplement un lien vers ces outils et fournis une commande en ligne de commande avec les noms des buckets remplis dans un espace réservé). Ensuite, j’utilise DbHelper pour mettre à jour les tables. Pour mon site de taille modérée, cela fonctionne assez rapidement. Super.

Le seul problème que je rencontre actuellement est que l’ancienne configuration ne comportait pas de s3_cdn_url, de sorte que ces images sont toujours liées directement au bucket (et non au CDN) dans les publications. Le rebaking ne résout pas le problème. Les nouveaux téléchargements sont correctement liés au CDN. Vous ne pouvez pas corriger cela en définissant DISCOURSE_S3_ENDPOINT: '', car cela n’a aucun effet. Après avoir restauré la base de données, j’ai dû effacer le SiteSetting. Ce n’est pas si grave, mais cela m’a pris plusieurs rebuilds pour comprendre cela.

L’ancienne configuration ne définissait pas de CDN S3. Je peux corriger cela en rebaking tous les 1250 posts qui contiennent l’URL ou le nom d’hôte du bucket, mais cela provoque le téléchargement et l’optimisation de toutes ces images (l’ancien serveur exécute la version 2.7.0.beta5, alors je pensais qu’il aurait déjà effectué certaines réoptimisations récentes ?). Cela met mon pauvre serveur de 2 Go à genoux (charge moyenne de 10 à 20) pendant un certain temps (avec Postgres et Redis sur RDS et ElastiCache). Je suppose que j’aurai peut-être besoin d’une instance EC2 plus puissante pour ce site de toute façon, mais je suis encore un peu surpris que ce rebaking mette le serveur à genoux (erreurs 500 dans l’interface utilisateur).

Devrais-je plutôt procéder à un remplacement de l’hôte du bucket par l’URL du CDN dans le champ cooked de ces publications ?

@pfaffman Merci de m’avoir orienté ici.
Mais mon problème s’aggrave lors des deux dernières étapes.

Problème actuel : Certaines de mes images sont manquantes et remplacées par de petites icônes. Si je passe la souris dessus, l’adresse ‘olds3bucket’ s’affiche. Cependant, lorsque je clique dessus, elles s’affichent correctement en taille réelle et l’URL dans la barre d’adresse montre désormais le chemin du ‘news3bucket’.

  1. Vous avez principalement indiqué de synchroniser les données de l’ancien bucket vers le nouveau, ce que j’ai déjà fait avec succès.
  2. Ensuite, saisissez les paramètres du nouveau bucket dans l’interface web de Discourse, que j’utilise déjà depuis un an.
  3. Maintenant, vous dites de ‘remapper’ l’URL de l’ancien bucket vers le nouveau, puis de rebakez. C’est là que se situe le problème. Lorsque je fais cela (ou même si je fais simplement ‘rebake’, ou même si je sélectionne ‘Reconstruire le HTML’ dans le menu des paramètres du post, avec ou sans avoir effectué l’étape de ‘remap’ au préalable), les images qui s’affichaient uniquement sous forme d’icône disparaissent complètement. Un simple ‘espace blanc’ apparaît à leur place. Je dois donc annuler/restaurer immédiatement.

Merci encore.
(J’ai un très petit site web, et j’ai également…).

rclone est un excellent outil capable de se synchroniser avec plusieurs backends. Nous l’utilisons actuellement pour les sauvegardes.

Salut Jay,

Désolé de te relancer, mais as-tu avancé sur le guide ? Merci !