Après avoir effectué quelques tests, j’ai constaté que certains de mes messages n’affichent pas les images, même avant d’effectuer une opération de « remap ».
Ils affichent plutôt une petite icône représentant l’image, qui indique le chemin de l’image lorsque je passe la souris dessus, et n’affiche l’image que lorsque je clique dessus.
De plus, cette icône disparaît également (et un espace blanc ou un espace réservé pour l’image apparaît à sa place) si j’exécute une opération « Rebuild Html » via le menu à trois points, ou même si j’effectue une opération de « rebake » à l’intérieur du conteneur.
Je vous serais reconnaissant de bien vouloir me guider.
Si vous n’avez pas effectué de remap et que votre bucket S3 fonctionne toujours, rien n’a dû changer par rapport à avant. Ces images fonctionnaient-elles avant que vous ne commenciez cette démarche ?
En théorie, vous ne perdrez la connexion à ces fichiers image que si vous désactivez votre bucket S3 ou si vous effectuez un remap de manière incorrecte.
Merci.
J’ai constaté que l’icône d’image affiche le chemin /bucket/uploads/optimized/dossier/… (et comme il n’existe aucune image à ce chemin, l’image ne s’affiche pas, seule l’icône apparaît).
Cependant, lorsque je clique sur cette icône d’image, l’image est affichée/fournie depuis le dossier ‘Orig’, c’est-à-dire /bucket/uploads/original/…
Je ne comprends pas comment une seule image peut avoir deux chemins différents enregistrés pour elle ?!!
Quoi qu’il en soit, le problème se résume maintenant à : comment puis-je trouver les publications qui contiennent des images mappées vers le mauvais chemin (sous ‘optimized’) ? Afin que je puisse corriger/remapper leurs adresses vers le bon chemin sous ‘Original’.
Merci @nathank, @Pravi, @itsbhanusharma. Comme j’ai confondu différents problèmes/scénarios, voici où j’en suis actuellement :
Certains de mes posts n’affichent pas les images qui y sont jointes. Au lieu de cela, ils affichent soit une petite icône avec une URL ou adresse de bucket incorrecte lorsque je passe la souris dessus, soit, pour certains, l’image correcte et le chemin du bucket correct uniquement lorsque je clique sur ces petites icônes. D’autres posts n’affichent aucune image, juste un espace blanc vide.
De plus, si j’exécute une opération de remappage (remap wrongbucketurl correctbucketurl), j’ai constaté dans un post échantillon que, bien que l’icône ait été remplacée par l’image correcte (ce qui m’a rendu heureux), le lendemain, cette image a complètement disparu, même l’icône. Un espace blanc est apparu à sa place. J’ai donc dû restaurer mon site web à l’état de la veille.
Lorsque j’ai exécuté cette commande, le résultat a été le suivant :
# rake posts:missing_uploads
Recherche d'uploads manquants sur : default
19 uploads de posts sont manquants.
19 uploads sont manquants.
6 des 7792 posts sont concernés.
J’ai exécuté des variantes de ce processus plusieurs dizaines de fois, et cela ne fonctionne toujours pas.
Nos images ne s’affichent pas via S3, car la direction a décidé de ne pas utiliser de bucket S3 avec un accès public. Nous devons donc revenir à un stockage local.
Initialement, j’ai inspecté les liens brisés et j’ai réussi à déterminer les valeurs à utiliser dans la réaffectation (c’est ce que je pensais). Un grand nombre d’images fonctionnent maintenant, mais la majorité, disons plus de 90 %, ne fonctionnent toujours pas. Contrairement aux liens S3 brisés, où vous pouvez au moins les inspecter pour commencer à comprendre ce qui ne va pas, tout ce que j’obtiens, c’est ceci :
Quelqu’un sait-il ce qui pourrait causer l’échec de ces images ? Je suis bloqué sur ce problème depuis plusieurs jours. Je trouve incroyable qu’il n’y ait a) aucun moyen de revenir en arrière et b) que quelqu’un (pas moi) nous ait migrés alors qu’il n’existe aucun moyen de revenir en arrière.
Pour être clair, j’ai suivi la procédure décrite ci-dessus par @nathank. Je l’ai essayée à de nombreuses reprises, généralement avec de légères variations dans les chemins lors de l’étape de réaffectation, car il n’est pas clair pour moi si ces instructions sont universelles ou dépendent de la structure de votre répertoire (le nôtre contient de nombreux sous-répertoires qui ont été copiés avec succès depuis S3 via l’étape de synchronisation S3).
Je vous serais très reconnaissant de m’aider, car je suis sur le point de devenir fou.
Je pense que ce que vous voulez faire, c’est activer l’option cachée include_s3_uploads_in_backups, effectuer une sauvegarde, puis la restaurer (je le ferais d’abord sur un nouveau serveur de test). C’est ce qui se produit lorsqu’un client de CDCK annule son abonnement : ces sauvegardes peuvent être restaurées sur un nouveau site auto-hébergé sans aucun problème.
NoMethodError: la méthode include_s3_uploads_in_backups= n’est pas définie pour SiteSettings:Module
from (pry):1:in __pry__
Ensuite, j’ai réalisé que je devais peut-être réactiver les uploads S3, car je les avais désactivés, mais j’ai toujours eu la même erreur.
Ah, nous utilisons deux conteneurs et j’exécute cela dans web_only. La commande Rails n’est pas trouvée dans le conteneur de données, donc je suppose que c’est la bonne approche.
Je l’ai exécutée, puis j’ai créé une nouvelle sauvegarde. Après restauration depuis cette sauvegarde, rien n’a changé : la plupart des images affichent toujours l’icône cassée mentionnée ci-dessus. J’ai également essayé de reconstruire les deux conteneurs, mais cela n’a rien changé.
Lorsque je télécharge et examine le fichier zip de sauvegarde, tous ces fichiers sont bien présents, et après restauration, ils sont visibles dans le système de fichiers. Cependant, Discourse refuse tout simplement de les reconnaître et de les afficher.
Pour la petite histoire, j’ai finalement réussi à faire fonctionner cela. J’ai recommencé à zéro (c’est-à-dire à partir d’une capture instantanée de mon instance) et je suis assez certain que la procédure qui a fini par fonctionner était la suivante :
utiliser la console Rails pour exécuter SiteSetting.include_s3_uploads_in_backups=true
créer une nouvelle sauvegarde
restaurer à partir de cette sauvegarde
utiliser discourse remap pour mettre à jour les références vers mes divers emplacements de fichiers S3 vers un emplacement local
rebaker les publications et reconstruire mes deux conteneurs Docker
Merci à @pfaffman de m’avoir orienté dans la bonne direction ici.
EDIT
Je vais autant soulever ce point. Après mon message précédent, j’ai réalisé que six de nos sujets avaient toujours des images brisées (bien que la grande majorité soit désormais fonctionnelle).
Il s’agit de nos six plus anciens messages et toutes les images originales avaient une URL S3 différente de celle de toutes les autres. Clairement, ce n’est pas un hasard. J’ai donc vérifié que tous ces fichiers se trouvaient dans le répertoire uploads/default/original/1X, et ils y étaient tous. Ensuite, j’ai exécuté une commande remap en utilisant cette URL S3 unique, ce qui semblait avoir édité le bon nombre de publications. Puis j’ai rebaké et reconstruit les conteneurs, mais ces sujets sont toujours brisés. Quelqu’un a-t-il une idée de pourquoi un petit nombre échouerait de cette manière ?
