Je lutte toujours pour déplacer les uploads vers Spaces. Lorsque s3_cdn_url est défini, Discourse pointe vers le CDN S3 pour les ressources, mais elles n’y sont pas. J’ai essayé rake s3:upload_assets et j’ai obtenu :
root@shadrack-rbx:/var/www/discourse# rake s3:upload_assets \ninstalling CORS rule\nUploading: assets/vendor-3037640def3beef9cc83cef108868f2bac887cf141d032c6b7388c7879c19601.js\nOPTS: {:cache_control=>\"max-age=31556952, public, immutable\", :content_type=>\"application/ecmascript\", :acl=>\"public-read\", :tagging=>\"\"} # NOTE: Pfaffman added this debug line. . . \nrake aborted!\nAws::S3::Errors::InvalidArgument: \n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-s3-1.30.1/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-s3-1.30.1/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-s3-1.30.1/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-core-3.46.1/lib/seahorse/client/request.rb:70:in `send_request'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-s3-1.30.1/lib/aws-sdk-s3/client.rb:5856:in `put_object'\n/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/aws-sdk-s3-1.30.1/lib/aws-sdk-s3/object.rb:928:in `put'\n/var/www/discourse/lib/s3_helper.rb:44:in `upload'\n/var/www/discourse/lib/tasks/s3.rake:38:in `block in upload'\n/var/www/discourse/lib/tasks/s3.rake:37:in `open'\n/var/www/discourse/lib/tasks/s3.rake:37:in `upload'\n/var/www/discourse/lib/tasks/s3.rake:148:in `block (2 levels) in <top (required)>'\n/var/www/discourse/lib/tasks/s3.rake:147:in `each'\n/var/www/discourse/lib/tasks/s3.rake:147:in `block in <top (required)>'\n/usr/local/bin/bundle:23:in `load'\n/usr/local/bin/bundle:23:in `<main>'\nTasks: TOP => s3:upload_assets\n(See full trace by running task with --trace)\nroot@shadrack-rbx:/var/www/discourse# vi config/discourse.\ndiscourse.conf discourse.config.sample discourse.pill.sample \nroot@shadrack-rbx:/var/www/discourse# vi config/discourse.conf\nroot@shadrack-rbx:/var/www/discourse# rails c\n```
Pour information, cette configuration permet d'uploader des images vers S3 sans problème.
Et, si cela fonctionnait, les ressources seraient-elles poussées vers S3 lors du bootstrap ? Je veux vraiment déplacer ce site vers S3 (73 Go d'images) pour passer à une autre configuration de serveur. Spaces est attrayant car j'ai des crédits de parrainage et un CDN gratuit. Mais peut-être devrais-je simplement abandonner et passer à AWS S3 ?
That’s what I thought, but what’s happening is that all the assets are linked to the S3 CDN url and they aren’t there. I’d assumed that they’d either be served by the CDN like normal (I have one site configured with regular CDN and it points to S3 cdn when that’s configured) or from local storage (I have another site configured with no regular CDN and when I have s3_cdn_url in global settings, all the assets are linked to the s3 CDN.
So, I either need to push assets to S3 or have Discourse not point to assets in S3. I don’t really care, but they need to be somewhere that they can be found, as without assets the whole site is hosed and I have to make changes in console.
No, I really mean assets (uploads seem fine). It seems that when GlobalSettings.s3_cdn_url is defined, discourse expects assets (i.e., the javascript stuff) to be in the S3 CDN, so the site is broken because none of the assets are available.
It makes zero sense to me either.
I just set SiteSettings.s3_cdn_url (not in GlobalSettings) and assets seem to still be coming from the server, not the CDN. So maybe it’s a bug with GlobalSettings.s3_cdn_url?
Yup. Re-setting the value in discourse.conf does this:
That means that if you want to use the GlobalSettings for S3 in the current state you will need to deal with the missing feature in the S3-like service in Digital Ocean, patching around it somehow.
You already have a workaround (use a normal site setting), and we know that we need a setting to disable the CORS rule (pr-welcome for that).
Je ne sais pas si vous (ou quelqu’un d’autre) rencontrez encore des problèmes avec cela, ou si ce qui suit pourrait résoudre le problème, mais comme je suis tombé sur cela en dépannant mon propre problème, j’ai pensé le partager :
Si vous utilisez Digital Ocean Spaces pour le stockage S3, et
Vous avez des thèmes avec des polices téléchargées, par exemple WOFF, qui sont copiées vers le stockage S3, et
Vous rencontrez des erreurs CORS lors du chargement des polices sur votre site Discourse, alors –
Digital Ocean Spaces propose désormais des paramètres de configuration CORS sur le point de terminaison que vous utilisez pour le stockage S3. Définissez l’URL de votre site Discourse comme Origine, GET pour les méthodes autorisées, et une valeur raisonnable comme 86400 pour la durée.
Donc, la conclusion de tout ce sujet était une méprise.
J’ai passé une journée entière à tester la compatibilité de Discourse avec les offres de DO, et le problème CORS ici était un faux ami.
Le problème vient du fait que DO Spaces n’implémente pas l’en-tête tagging dans leur clone S3.
La correction pour la tâche upload_assets est assez simple et se trouve dans une branche.
Le souci, c’est que nous utilisons réellement tagging dans une autre tâche rake, donc si vous utilisez DO Spaces, vous ne pourrez jamais vraiment utiliser la tâche s3:expire_missing_assets. Ce qui peut être un compromis « acceptable » pour certains.
Je compte mettre à jour et créer de nouveaux guides à ce sujet la semaine prochaine.
Je rédige un rapport sur une grande expérience utilisant les services DO avec Discourse (comme le service Redis, le service PostgreSQL, le service Object Store, le service CDN), afin que nous puissions le présenter dans un document concis. J’ai déjà découvert un problème bien plus grave. Leur CDN clone S3 supprime l’en-tête Content-Encoding des fichiers, ce qui empêche de servir nos fichiers JavaScript compressés en GZip et Brotli, et cela casse tout.
Le meilleur résultat à long terme pour tous est que tous les clones AWS S3 soient réellement… précis ? Donc, si nous pouvons suivre et relancer les fournisseurs pour améliorer leurs clones, c’est la voie supérieure.
J’ai pris contact avec Digital Ocean, et il semble qu’ils utilisent MinIO en interne. MinIO a pris en charge les étiquettes il y a un mois. Ils ajouteront le support dès le déploiement de cette nouvelle version.
