Oui, mais vous l’avez écrasé dans votre point n° 2, ce qui vous ramène à placer les fichiers dans S3.
Les paramètres du fichier app.yml ne sont utilisés que lors de la reconstruction du conteneur et servent à remplir le fichier config/discourse.conf dans le conteneur en cours de construction.
Ah ! Donc, si j’ai des variables s3_ dans mon fichier conf/discourse.conf, Discourse pense que les uploads S3 sont activés ? D’accord… compris… Je vais les supprimer et réessayer.
Il y a probablement une seule chose qui compte… Je ne suis pas à mon ordinateur pour vérifier ce qui pourrait déclencher cela, mais si cette vérification est déclenchée, je m’attendrais à ce que votre site télécharge toutes les nouvelles uploads vers S3.
Ça marche, ça marche, ça marche, ça marche, ça marche ! Ouiii !!! Merci beaucoup pour tout votre travail et pour avoir patiemment expliqué ce que je devais faire. C’est super de pouvoir enfin lancer cela.
Donc, quelques questions rapides pour mieux comprendre ce qui se passe…
J’exécute des lots de 100 à la fois. Lors des premiers cycles, l’outil migrait des publications (?), mais maintenant, il ne fait que copier des images. J’ai des milliers et des milliers de publications, et chacune n’a généralement qu’une seule image jointe… donc je ne comprends pas pourquoi/comment il a « manqué » de publications à migrer ? Que signifie migrer une publication ? C’est donc la question 1 : que se passe-t-il exactement ? 
La question 2 est plus simple. Maintenant, quand je l’exécute, il ne fait que copier des images, mais je remarque que les images 2X sont copiées en 3X localement :
Téléchargé 27/100 : //my-forum-storage.s3.dualstack.us-east-1.amazonaws.com/original/2X/1/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg vers /uploads/default/original/3X/1/4/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg
Remarquez que l’URL passe de 2X/1/xyz.jpeg à 3X/1/4/xyz.jpeg (un chemin de dossier supplémentaire est ajouté).
Est-ce que tout cela est correct ?
Enfin, j’ai vérifié quelques images au hasard et elles semblent correctes, mais comme je ne sais pas à quelle publication est associée chaque image, je ne peux pas vraiment faire de vérification « en direct » sur le forum et être certain à 100 % que mes utilisateurs voient la bonne chose. Comment puis-je mapper le nom de fichier de l’image JPEG à une publication du forum ?
Quelles commandes exactes tapiez-vous ? Vous devrez étendre la limite pour couvrir tous vos messages.
J’ai donc fini par spécifier une limite élevée une fois que j’étais certain d’entrer dans la phase suivante, quelque chose comme ceci :
bin/rake uploads:batch_migrate_from_s3[100,100000]
Il migre d’abord les téléversements qu’il trouve dans les messages ; il n’y a pas d’intégrité référentielle entre les références de post.raw vers un téléversement et l’objet téléversement dans la base de données. Il recherche les messages contenant des références à des URLs simples ou à des URLs de pseudo-protocole upload:// représentant du contenu distant, pour lesquels il doit au moins re-cuire le message après la migration, sinon enregistrer une modification comme pour les URLs de base pointant directement vers S3. Lorsqu’il ne trouve aucun contenu dans un message nécessitant une migration, il passe à l’élément suivant.
Les changements de chemin ne sont pas directement pilotés par le script de migration ; il s’agit simplement de modifications concernant l’endroit où Discourse place les fichiers. Un niveau de répertoire supplémentaire améliore les performances lorsque vous avez beaucoup de fichiers, et de nombreux autres systèmes utilisent deux, et parfois trois, niveaux de répertoires pour répartir les fichiers.
Vous pourriez rencontrer le même problème que moi : la migration des autres téléversements a fait perdre à Discourse la trace des photos de profil des utilisateurs. Je ne l’ai remarqué que trop tard pour restaurer à partir d’une sauvegarde, j’ai donc simplement envoyé des messages aux utilisateurs concernés, présenté mes excuses et demandé qu’ils corrigent leurs avatars. Je ne sais toujours pas ce qui s’est mal passé là-bas.
Ah d’accord, cool. Je vois ceci dans la sortie de progression :
Tous les téléchargements de publications ont été migrés. Migration des téléchargements de profils...
Tous les téléchargements de profils ont été migrés. Migration des autres téléchargements non liés aux publications...
Que sont les « téléchargements non liés aux publications » ? C’est là que semble se concentrer tout le travail restant — la migration des publications et des téléchargements de profils ne semble rien faire.
Merci pour le réconfort concernant les chemins d’accès aux téléchargements bruts !
Je ne suis pas sûr que cela se produise ou non, mais ce n’est pas grave — mon site utilise l’SSO, donc je transmets l’URL de l’avatar à chaque fois que l’utilisateur se connecte (ou modifie sa photo sur le site principal).
Honnêtement, je ne sais pas ce que étaient les autres. J’espérais plutôt que, si l’intégrité référentielle était un problème, il y aurait une contrainte de clé étrangère, et que sinon, il suffirait de rechercher le téléchargement et d’utiliser l’endroit où il se trouvait. J’ai certainement rencontré des contraintes de clé étrangère comme indicateur qu’il fallait faire quelque chose de spécial pour deux téléchargements attachés aux profils d’utilisateurs.
Hmmm, cela semble effectivement fonctionner… bien que j’aie rencontré un problème sérieux ce matin… soudainement, l’utilisation de mon disque a augmenté de 25 % et a saturé le lecteur, faisant planter complètement les forums.
Pour le moment, lorsque j’exécute la commande rake, il semble qu’elle télécharge et téléverse les images directement pendant l’exécution par lots. Je saisis la commande rake, elle traite exactement 300 images (je les exécute par lots de 300), puis elle se termine.
La question importante est donc la suivante : le simple déplacement de ces téléchargements depuis S3 vers le disque local pourrait-il être mis en file d’attente ? Est-ce que cela aurait pu accumuler un quelconque lot qui s’est ensuite exécuté à 5 h et a fait tomber mes forums ? 
J’ai fait en sorte d’attendre que la file d’attente soit vide avant de procéder à chaque nouveau post lors de la migration des messages, à chaque nouvel ensemble de téléchargements de profils, puis à chaque autre téléchargement. Les images devraient être traitées immédiatement après leur déplacement. (La version standard les empile simplement et sature la file d’attente jusqu’à ce que le traitement soit terminé ; dans mon cas, cela aurait signifié 10 à 12 jours sans envoyer de notifications de forum pendant le retraitement des images.)
Je ne vois pas ce qui aurait pu provoquer un tel pic, à moins qu’il n’ait rencontré un grand nombre de fichiers très volumineux ?
Oui, c’est un mystère pour moi. Je veux dire, je n’exécute même pas les lots très souvent — je saisis manuellement la commande à chaque fois et je surveille son exécution. Je n’ai plus de publications ou de profils à migrer ; tout ce qui reste relève des « autres téléversements ». Lorsque j’exécute le lot, il semble qu’il télécharge depuis S3 et réenregistre sur Digital Ocean en temps réel. (Et je ne vois rien dans Sidekiq qui laisserait entendre que des tâches sont mises en file d’attente.)
J’essaie de trouver d’autres journaux qui pourraient indiquer ce qui s’est passé à 5 h 35.
Lisez l’intégralité du sujet.
Mais la plupart du contenu m’a semblé confus. Bien que je maîtrise parfaitement les commandes Docker/conteneurs et les commandes Rails de base.
Je rencontre des problèmes similaires (beaucoup de mes publications ont des images manquantes, ou certaines n’affichent pas les images avant qu’on ne clique dessus).
J’ai utilisé deux buckets S3 différents à deux moments distincts de l’année. J’ai environ 1000 publications et à peu près autant d’images.
J’ai maintenant copié toutes les images des buckets S3 vers mon serveur local. Quelqu’un peut-il m’indiquer comment remapper les URLs de Discourse afin que ces images soient désormais correctement liées aux publications ?