Merci pour le remerciement ! J’avais signalé pour une attention modérée car je n’avais pas les droits de modification à ce moment-là, mais je les ai maintenant grâce au message que j’ai posté. Ironique, n’est-ce pas ?
Mais avant de faire une annonce générale en dehors de la section MinIO, pouvons-nous confirmer que Discourse dans son ensemble ne prend plus en charge les chemins non basés sur le domaine comme le mentionne ce post qui a lancé ma recherche de modifications ?
Si nous savons que Discourse dans son ensemble ne prend pas en charge le mode chemin (c’est-à-dire les chemins minio.server.com/BUCKET/foo/bar/...) et prend uniquement en charge les chemins de domaine (c’est-à-dire BUCKET.minio.server.com/foo/bar/...), alors nous pouvons en faire une annonce globale dans le wiki et je serai heureux de le faire - cependant, j’ai besoin de l’entendre de quelqu’un de beaucoup plus haut placé que moi (en tant que simple membre de la communauté) que c’est bien la configuration requise pour Discourse. Si c’est le cas, je pourrai le modifier, sinon… eh bien, je le laisserai simplement comme une note dans les prérequis MinIO.
MinIO est le seul clone S3 populaire ayant utilisé le style de chemin S3 maintenant déprécié, je ne pense donc pas qu’il mérite un avertissement global, juste dans la section MinIO suffit.
Merci, Falco, je l’ai laissé dans les prérequis MinIO, mais j’ai aussi mis un fort accent sur cette section de mise en garde en raison du fil de discussion lié ci-dessus qui explique pourquoi je reviens à la charge.
ÉCHEC
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets a échoué avec le retour #<Process::Status: pid 2064 exit 1>
Emplacement de l'échec : /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap a échoué avec le code de sortie 1
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
Salut @Falco. Est-ce que cela a du sens ? Je vérifie les réponses pour m’assurer qu’elles ont été traitées afin que nous puissions activer la suppression après 30 jours sur ce sujet.
J’ai vérifié quelques-uns des téléchargements marqués comme privés et ils se trouvaient dans des sujets ordinaires, donc je n’ai pas pu comprendre pourquoi ils étaient marqués comme sécurisés. (Les téléchargements sécurisés n’étaient pas activés ?)
Logique. J’ai mis à jour le début du message initial avec cette information. Avez-vous une idée de la raison pour laquelle les téléchargements locaux auraient été marqués comme sécurisés sur un site qui n’avait ni S3 ni de téléchargements sécurisés activés ?
Je pense que ce problème de téléchargement vers Cloudflare R2 pourrait être résolu avec Upload.where(secure: true).update_all(secure: false). J’essaierai de m’en occuper avant que ce message ne soit supprimé (mais j’ai ajouté une note à l’OP).
Hmm, nous n’avons pas de téléchargements sécurisés. Je pense que je vais essayer Cloudflare R2, car leurs limites gratuites sont assez généreuses et ils ont un (bêta) outil de migration S3. Je suppose que je le découvrirai, mais avez-vous vu si R2 allait bien à la fin @pfaffman ?
Je ne me souviens plus si le problème s’est produit lorsque j’ai essayé de téléverser des images ou lorsque j’en ai simplement téléversé une nouvelle. En y repensant, je pense que je l’ai testé sur un tout nouveau site.
Migrer vers une plateforme S3 différente est assez délicat. Il existe des sujets à ce sujet, mais si vous voulez utiliser Cloudflare R2, je vous suggère d’abord de l’essayer sur un site de test ; il y a de très fortes chances que cela ne fonctionne pas.
Ça fonctionne plus ou moins, mais ce n’est pas encore prêt pour la production.
J’avais une ancienne installation de développement locale de Discourse 2.7 qui traînait et elle fonctionnait bien, c’est-à-dire pour les téléchargements d’images, l’utilisation du CDN et les sauvegardes vers un bucket privé lorsqu’elle était configurée pour Cloudflare R2. J’ai mis à jour vers la dernière version 2.9 (comme celle utilisée par notre forum) et il semble que cela échoue lors du traitement de rattrapage de Jobs::UpdateGravatar, où il utilise la notation de bucket incorrectement pour Cloudflare, car il essaie de mettre en cache une image distante gravatar vers R2. Exemple (où mon nom de bucket sur R2 est ‘uploads’) :
Mise à jour du téléchargement (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
Donc, je démarrais l’interface utilisateur et les avatars dans ma configuration de test/développement locale pointeraient vers //uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg
Ma meilleure supposition est donc que S3 accepte la notation par points du bucket et que Cloudflare R2 ne le fait pas, ou peut-être que le cache gravatar doit utiliser la valeur du CDN S3 à la place ? C’est dommage car cela semble très proche…
J’ai reçu une réponse de Cloudflare indiquant que pour R2, jusqu’à ce qu’ils implémentent correctement les ACL d’objets, ils l’ont modifié pour renvoyer un 200 s’ils obtiennent des valeurs dans cette propriété qu’ils ne prennent pas encore en charge. Ce comportement modifié sur R2 date de fin novembre apparemment. Clairement pas idéal (c’est dans un bucket public, avec l’API demandant qu’il soit privé) mais cela signifie que pour ce problème, cela « fonctionne » maintenant.
Oh ! Cela semble prometteur. Je pense qu’il faudrait peut-être un compartiment séparé pour les téléchargements, bien que ce serait un jeu de devinettes pour obtenir le nom de fichier d’une sauvegarde.
J’utilise bien des buckets de téléchargement et de sauvegarde séparés, et cela semblait fonctionner correctement, dans le sens où le bucket de sauvegarde R2 n’est pas public et que Discourse, via l’interface d’administration, y a écrit une sauvegarde compressée sans problème. Je l’ai téléchargée et examinée, et elle semblait cohérente (pas la même chose qu’une restauration réelle, mais suffisant pour un lundi). Mon bucket de téléchargements, je l’ai testé avec un domaine personnalisé pour le S3_CDN, et cela semble bien fonctionner.
Pour être honnête, je n’arrive pas vraiment à comprendre ce qui ne va pas avec ma version 2.9 qui n’affiche pas d’interface utilisateur dans ember-cli (elle devient vide après la création de l’utilisateur administrateur), mais c’est probablement quelque chose que vous verrez rapidement.
EDIT : Oh, il semble qu’elle essaie de charger les ressources JavaScript des plugins depuis Pseudo-S3/R2, par exemple beaucoup de 404 sur des éléments comme assets/locales/en.br.js.
Je n’ai pas de succès avec un bundle exec rake s3:upload_assets, donc c’est mon meilleur indice actuel.
EDIT2 : Oui, c’est lié aux ressources, car si je vide mon DISCOURSE_S3_CDN_URL, l’interface utilisateur se charge. J’essaierai de télécharger manuellement les ressources sur place pour l’instant.
EDIT3 : Le problème semble juste être que l’application a besoin que les ressources soient précompilées et où pointe DISCOURSE_S3_CDN_URL, et pour un environnement de développement local, ce n’est pas habituel. Je serai intéressé par ce que trouvera @pfaffman, car je pense que cela fonctionnerait dans une instance auto-hébergée déployée avec Docker, en utilisant le hook after_assets_precompile pour R2.
Ouais. Un CDN pour un environnement de développement local ? Je n’arrive pas à imaginer que cela puisse fonctionner. Cela semble fonctionner pour un déploiement en production.
Oui, rétrospectivement, ce n’est pas surprenant dans une configuration de développement. Je pense que ce à quoi je ne m’attendais pas, c’est qu’avec DISCOURSE_S3_CDN_URL défini sur le CDN Cloudflare pour R2, mais ensuite DISCOURSE_CDN_URL défini sur vide (ou local ou ngrok), il utilisait toujours l’URL de récupération Cloudflare pour les actifs précompilés, etc., et pas seulement pour les téléchargements/images. Je pense que cela fonctionnera correctement en production dans un conteneur approprié, donc je vais essayer rapidement. Mon plan sera quelque chose comme rendre les téléchargements de médias TL4 temporairement, basculer les ID, etc. vers Cloudflare dans le fichier app.yaml, tester, et si c’est bon, le laisser à R2, puis utiliser rclone pour transférer tous les objets S3 existants - après cela, je re-cuirai les publications et j’espère que tout ira bien .
.