Sto ancora avendo difficoltà a spostare i caricamenti su Spaces. Quando s3_cdn_url è definito, Discourse punta all’S3 CDN per le risorse, ma queste non sono presenti. Ho provato rake s3:upload_assets e ho ottenuto:
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
A titolo informativo, questa configurazione riesce a caricare immagini su S3 senza problemi.
Inoltre, se ciò funzionasse, le risorse verrebbero spostate su S3 durante il bootstrap? Vorrei davvero spostare questo sito su S3 (73 GB di immagini) per passare a una configurazione server diversa. Spaces è allettante perché ho crediti di referral e un CDN gratuito. Ma forse dovrei semplicemente desistere e passare ad 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).
Non sono sicuro che tu (o qualcun altro) abbia ancora problemi con questo, o se quanto segue possa risolverli, ma dato che mi sono imbattuto in questa situazione mentre risolvevo il mio stesso problema, ho pensato di condividerla:
Se stai utilizzando Digital Ocean Spaces per l’archiviazione S3, e
Hai temi con font caricati, ad esempio WOFF, che vengono copiati nell’archiviazione S3, e
Stai ricevendo errori CORS quando carichi i font sul tuo sito Discourse, allora –
Digital Ocean Spaces dispone ora di impostazioni di configurazione CORS sull’endpoint che utilizzi per l’archiviazione S3. Imposta l’URL del tuo sito Discourse come Origine, GET come metodi consentiti e un valore ragionevole come 86400 per il tempo.
Quindi, l’intera conclusione del tema era dovuta a un malinteso.
Ho dedicato un’intera giornata a testare la compatibilità di Discourse con le offerte di DO, e il problema CORS era un falso allarme.
Il problema è che DO Spaces non implementa l’intestazione tagging nella loro clonazione S3.
La correzione per il task upload_assets è piuttosto semplice ed è presente in un branch.
Il problema è che in realtà utilizziamo tagging in modo effettivo in un altro task rake, quindi se si utilizzano DO Spaces non è possibile utilizzare mai il task s3:expire_missing_assets. Questo può essere un compromesso “accettabile” per alcuni.
Intendo aggiornare e creare alcune nuove guide su questo argomento la prossima settimana.
Sto redigendo un rapporto su un esperimento importante che utilizza i servizi di DigitalOcean con Discourse (come il servizio Redis, il servizio PostgreSQL, il servizio Object Store e il servizio CDN), in modo da poterlo presentare in un documento conciso. Ho già individuato un problema ben più grave. Il loro CDN clone di S3 rimuove l’intestazione Content-Encoding dei file, impedendo di servire i nostri file JavaScript compressi con GZip e Brotli, e questo rompe tutto.
Il risultato a lungo termine migliore per tutti è che tutti i cloni di AWS S3 siano effettivamente… accurati? Quindi, se possiamo fare un follow-up e sollecitare i provider a migliorare i loro cloni, questa è la strada migliore.
Ho contattato Digital Ocean e sembra che stiano utilizzando MinIO nei loro sistemi. MinIO ha introdotto il supporto per i tag un mese fa. Saranno pronti a supportarlo non appena rilasceranno questa nuova versione.
