Ich habe immer noch Probleme damit, Uploads zu Spaces zu verschieben. Wenn s3_cdn_url definiert ist, verweist Discourse auf das S3_CDN für Assets, aber diese sind dort nicht vorhanden. Ich habe rake s3:upload_assets ausgeführt und folgendes erhalten:
root@shadrack-rbx:/var/www/discourse# rake s3:upload_assets
installing CORS rule
Uploading: assets/vendor-3037640def3beef9cc83cef108868f2bac887cf141d032c6b7388c7879c19601.js
OPTS: {:cache_control=>"max-age=31556952, public, immutable", :content_type=>"application/ecmascript", :acl=>"public-read", :tagging=>""} # NOTE: Pfaffman added this debug line. . .
rake aborted!
Aws::S3::Errors::InvalidArgument:
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/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'
/var/www/discourse/lib/s3_helper.rb:44:in `upload'
/var/www/discourse/lib/tasks/s3.rake:38:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:37:in `open'
/var/www/discourse/lib/tasks/s3.rake:37:in `upload'
/var/www/discourse/lib/tasks/s3.rake:148:in `block (2 levels) in <top (required)>'
/var/www/discourse/lib/tasks/s3.rake:147:in `each'
/var/www/discourse/lib/tasks/s3.rake:147:in `block in <top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
root@shadrack-rbx:/var/www/discourse# vi config/discourse.
discourse.conf discourse.config.sample discourse.pill.sample
root@shadrack-rbx:/var/www/discourse# vi config/discourse.conf
root@shadrack-rbx:/var/www/discourse# rails c
Nur zur Info: Diese Konfiguration kann Bilder problemlos auf S3 hochladen.
Und falls dies funktionieren würde, würden Assets dann beim Bootstrap-Vorgang auf S3 übertragen? Ich möchte diese Seite wirklich auf S3 verschieben (73 GB Bilder), um zu einer anderen Serverkonfiguration zu wechseln. Spaces ist verlockend, da ich Empfehlungs-Guthaben und ein kostenloses CDN habe. Aber vielleicht sollte ich es einfach sein lassen und direkt zu AWS S3 wechseln?
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).
Ich bin mir nicht sicher, ob du (oder jemand anderes) immer noch Probleme damit hast oder ob das Folgende es lösen würde, aber da ich darauf gestoßen bin, als ich mein eigenes Problem beheben wollte, dachte ich, ich teile es mit:
Wenn du Digital Ocean Spaces für S3-Speicher verwendest, und
Du Themes mit hochgeladenen Schriftarten hast, z. B. WOFF, die in den S3-Speicher kopiert werden, und
Du CORS-Fehler beim Laden der Schriftarten auf deiner Discourse-Website erhältst, dann –
Digital Ocean Spaces verfügen nun über CORS-Konfigurationseinstellungen für den Endpunkt, den du für den S3-Speicher verwendest. Gib die URL deiner Discourse-Website als Ursprung an, GET für erlaubte Methoden und etwas Vernünftiges wie 86400 für die Zeit.
Die gesamte Schlussfolgerung des Themas war also ein Missverständnis.
Ich habe einen ganzen Tag damit verbracht, die Kompatibilität von Discourse mit den Angeboten von DO zu testen, und die CORS-Sache hier war ein Ablenkungsmanöver.
Das Problem ist, dass DO Spaces den tagging-Header in ihrem S3-Clone nicht implementieren.
Die Korrektur für die upload_assets-Aufgabe ist ziemlich einfach und befindet sich in einem Branch.
Das Problem ist, dass wir tagging tatsächlich in einer anderen Rake-Aufgabe wirklich verwenden. Wenn Sie also DO Spaces nutzen, können Sie die s3:expire_missing_assets-Aufgabe eigentlich nie verwenden. Das kann für manche ein „akzeptabler
Ich dokumentiere gerade ein großes Experiment mit DO-Diensten für Discourse (wie Redis-Service, PostgreSQL-Service, Object Store-Service, CDN-Service), damit wir dies in einem prägnanten Dokument weitergeben können. Ich habe bereits ein viel gravierenderes Problem entdeckt. Ihr S3-Clone-CDN entfernt den Content-Encoding-Header von Dateien, sodass wir unsere GZip- und Brotli-JavaScript-Dateien nicht ausliefern können. Das bringt einfach alles zum Erliegen.
Das langfristig beste Ergebnis für alle ist, dass alle AWS S3-Klone tatsächlich… akkurat sind? Wenn wir also die Anbieter nachfassen und drängen können, ihre Klone zu verbessern, ist das der überlegene Weg.
Ich habe Kontakt mit Digital Ocean aufgenommen, und es scheint, dass sie MinIO im Hintergrund einsetzen. Minio hat vor einem Monat die Unterstützung für Tags erhalten. Sobald sie diese neue Version ausrollen, wird die Unterstützung dafür verfügbar sein.
