@schleifer Salut, pourriez-vous s’il vous plaît nous donner des directives après cela ?
D’accord, c’est quelque chose avec quoi nous pouvons travailler. Déplacez d’abord tous les fichiers de /default/* vers /original/1X/*.
Cela est connu de nous, mais pas de la base de données. L’étape suivante ajustera le chemin pour tous les téléchargements dans la BD. Avant de modifier quoi que ce soit d’autre, vérifions toutefois la cohérence.
Démarrez une console de base de données :
cd /var/discourse
./launcher enter
rails db
Exécutez cette requête pour examiner les résultats :
select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'
Vous devrez remplacer PREFIX par BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’, ce qui donnera quelque chose comme //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/%.
Cela devrait afficher (0 lignes). Sinon, nous aurons des étapes supplémentaires.
Il y a 7 téléchargements pour votre requête et aucun d’entre eux ne provient de S3.
Donc, tous les liens S3 pointent uniquement vers l’original, n’est-ce pas ? Les 7 téléchargements datent d’avant que nous commencions à utiliser S3 pour les téléchargements (octobre 2018).
Parmi les liens S3 (2614),
2368 utilisent //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 utilisent //pesioforum.s3.ap-south-1.amazonaws.com
Les deux liens fonctionnent, je le mentionne ici car cela pourrait affecter les expressions rationnelles que nous pourrions utiliser.
@schleifer, aide-nous s’il te plaît à terminer cela. 
OK, vous devriez donc pouvoir déplacer les fichiers de /default/ vers /original/1X.
Vous pouvez migrer ces éléments vers S3 en exécutant rake s3:upload_assets.
Le point de terminaison dualstack fonctionne pour IPv6 et IPv4. L’autre est réservé à IPv4 uniquement.
Il existe un script dans l’image pour réattribuer les chaînes de caractères dans la base de données. Avant de l’exécuter, PRENEZ TOUJOURS UNE COPIE DE SÉCURITÉ via /admin/backups (Menu hamburger → Admin → Sauvegardes).
Cela devrait corriger les 246 :
discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'
Après avoir déplacé tout le contenu de /default/ vers /original/1X/, nous pouvons réattribuer ces fichiers dans la base de données. Mais avant cela, nous devons nous assurer que tout ce qui se trouve dans /original/2X est bien présent.
Cette requête renvoie-t-elle le même nombre de lignes que le nombre d’objets réels sous ce chemin dans le bucket ?
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'
Salut @schleifer
Vous pouvez migrer ceux-ci vers S3 en exécutant
rake s3:upload_assets
Je l’ai exécuté et cela a téléchargé les ressources (js, css, etc.) pour le site web. Les 7 fichiers n’ont pas été téléchargés.
J’ai trouvé rake uploads:migrate_to_s3 mais je voulais confirmer qu’il s’agissait bien de la tâche appropriée pour cela.
Il y a un script dans l’image pour remapper les chaînes dans la base de données
Cela a bien fonctionné et il n’y a plus d’anciens liens non dualstack dans la table uploads.
Mais avant cela, nous devons nous assurer que tout ce qui se trouve dans
/original/2Xest bien là.
Malheureusement, ce n’est pas le cas. Il y a 521 fichiers dans le bucket S3, mais 2186 enregistrements dans la table uploads.
J’ai testé quelques fichiers qui ne se trouvent pas dans /original/2X/ comme requis et ils sont tous dans /default/.
Exemple : Depuis la table uploads,
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg n’existe pas, mais le même fichier se trouve à
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg
À ce stade, en tant que solution temporaire unique, nous sommes d’accord pour simplement déplacer tous les fichiers de /original/2X/{}/ vers /original/1X/ et mettre à jour les publications, etc., avec les nouveaux liens.
Les nouveaux téléchargements sont correctement placés dans 2X de toute façon.
Aha, oui, c’est bien celle que je voulais en réalité. Elle devrait pousser les sept derniers.
En effet, c’est la meilleure option à ce stade. Copiez tous les fichiers hors de leur sous-préfixe /2X/ et déplacez tout dans /1X/.
Une fois que tout est en place, voici une commande qui devrait mettre à jour toutes les entrées de la base de données :
discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"
(N’oubliez pas l’avertissement précédent concernant la prise de sauvegarde.)
Après cela, certaines publications devront peut-être voir leur version HTML reconstruite via le menu clé à molette. S’il y en a plus que quelques-unes, vous pouvez tout reconstruire avec rake posts:rebake.
@schleifer Ça a fonctionné ! Avec une expression rationnelle modifiée et une régénération de tous les messages, la plupart des images et des fichiers uploadés fonctionnent bien.
Quelques images (hors messages) pointent encore vers /optimized/, mais nous pouvons les corriger manuellement. Par exemple : les logos dans différents thèmes, etc.
Merci beaucoup pour votre aide !
Bonjour, nous avons rencontré un problème similaire dans notre environnement et nous espérions obtenir de l’aide pour le résoudre également.
Notre problème ressemble à celui-ci à bien des égards :
- Nous avons la même valeur répertoriée sous
s3 upload bucketets3 backup bucket. - Nous avons rencontré ce problème lors de la mise à niveau de Discourse :
Ancienne version : v2.3.0.beta3
Nouvelle version : v2.5.0.beta6
- Je me suis connecté au conteneur Discourse et j’ai interrogé la base de données :
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';
id | url
----+----------------------------------------------------------------------------------------------------
1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 lignes)
- Je me suis connecté au conteneur Discourse et j’ai interrogé la base de données :
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';
//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 lignes)
- J’ai vérifié combien d’éléments se trouvent dans ./original/3X/, la réponse est
251éléments.
Questions :
- Nous utilisons
dualstacket je ne souhaite pas remapper nos URL pour ne pas l’utiliser. - Notre structure de dossiers est différente, nous avons des éléments comme
3X/X/Y(par exemple3X/7/a), alors comment puis-je déplacer tout le contenu dedefaultvers3X/*? Cela ne sera toujours pas mappé correctement.
Mon idée actuelle est d’écrire un script qui utilisera la sortie de l’étape 4 pour déterminer où déplacer le fichier vers le dossier ./original/3X/X/Y.
Le seul problème est que, lorsque je l’ai fait, dualstack n’avait pas encore hébergé ce fichier. Ce que je veux dire, c’est que lorsque je remplace le fichier par original/3X/X/Y, je peux le voir en allant à :
Cassé https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png
Mise à jour Il s’avère que le point de terminaison dualstack n’a jamais été cassé comme je le pensais. J’ai fait une erreur lorsque j’ai initialement copié le fichier image dans ./original/3X/6/b, où j’ai oublié d’autoriser la lecture par tout le monde.
Ma question est donc la suivante :
Serait-il une option viable de remettre les fichiers image de ./default dans ./original/3X/x/y sans modifier la base de données du tout ?
D’accord, j’ai une mise à jour.
Il semble que je puisse prédire où les images ./original sont censées aller, mais je ne sais pas comment corriger les images ./optimized.
Dans notre forum, si vous naviguez vers l’un de nos messages, il tente d’afficher l’image ./optimized.
Y a-t-il un moyen de savoir quelle est une image optimized ?
Mon hypothèse est que les images optimisées se terminent par _2_10x10.png. Serait-ce une hypothèse raisonnable ? Si c’est le cas, serait-il viable d’utiliser un script pour copier tout ce qui contient quelque chose comme _2_10x10.png vers le dossier optimized et tout le reste directement vers le dossier ./original ?
exemple :
GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]
Merci !
@41821 Si les URL dans la table uploads sont correctes et fonctionnelles, mais que les publications tentent toujours de charger les images optimisées, effacer la table optimized_images et reconstruire toutes les publications devrait résoudre le problème : discourse=> delete from optimized_images;
Merci beaucoup pour vos retours. En fait, j’ai fini par résoudre le problème (si on peut appeler cela ainsi) en écrivant un script pour déplacer l’image du répertoire /default vers /optimized en fonction du nom du fichier. Cela semble avoir fonctionné et je n’ai plus aucun problème.
Cependant, si cela se reproduit à l’avenir, je ferai comme vous l’avez suggéré : je supprimerai tout depuis optimized_images et je rebakerai.
Merci !