Ho dovuto mettere da parte questo per ora, poiché sembrava che stesse per funzionare, ma poi c’è qualcosa di strano che succede con R2 in termini di codifica dei contenuti con gli asset, sia durante il caricamento e non impostando l’header, sia qualcos’altro. Si blocca con un ‘Token non valido o imprevisto’ dato l’asset gz di qualcosa come browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js. Il comando rake s3:upload_assets sembra funzionare, ma i file non vengono letti correttamente dal lato browser.
Non capisco davvero perché con AWS S3 vada bene usare l’URL del server locale per gli asset (non esistono nel nostro bucket S3 esistente per i caricamenti), ma per R2 richieda l’uso di DISCOURSE_S3_CDN_URL solo per gli asset. Se potessi forzare gli asset a provenire dall’URL del server, probabilmente tutto funzionerebbe.
EDIT: Parlando su CF, questo sembra essere il problema, e da oggi il motivo per cui R2 non può essere utilizzato con Discourse senza alcune modifiche. Potrei creare uno script nel passaggio post-hook per rimuovere gli asset gz, ma sento di essere già abbastanza “fuori strada” per oggi:
I file che comprimi in gzip non vengono attualmente gestiti correttamente da R2. Devi caricare file non compressi. Cloudflare ha la compressione trasparente, sceglie identity, gzip o Brotli in base a ciò che il client può gestire. Questa è una differenza rispetto a S3.
Grazie per aver messo insieme questa guida! Ho avuto un certo successo con Minio.
Per chiunque altro stia cercando di configurarlo localmente con Docker Compose, è possibile indicare a Docker di aggiungere un alias host in modo che funzioni come sottodominio, in questo modo:
In questo caso, dovresti impostare DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000, DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000 e impostare il tuo file locale /etc/hosts/ per puntare il sottodominio a localhost.
Pensavo che sarebbe stato utile menzionare questo nella sezione Minio o nel riepilogo, ovvero che DISCOURSE_S3_CDN_URL deve essere sulla porta 80 o 443.
Ciao @Falco - Ti riferisci al modo in cui l’header Content-Encoding: gzip funziona con la loro CDN Spaces? Questo suona simile a Cloudflare R2, nel senso che la posizione dell’asset viene resa uguale alla CDN di upload, quindi il gzip si interrompe? Ecco cosa succede oggi con R2.
Potrebbe valere la pena considerare un’opzione per quel comportamento, ad esempio servire gli asset dall’origine piuttosto che sempre da DISCOURSE_S3_CDN_URL? Sarò felice di cercare come fare, se venisse considerato come una potenziale modifica di configurazione.
Questo è ciò che dovrebbe accadere se ometti la configurazione di DISCOURSE_S3_CDN_URL ma poiché è un caso limite strano e un potenziale errore costoso, non è una configurazione comune.
Sì, capisco. Una nuova voce booleana GlobalSetting S3_ORIGIN_ASSETS (o S3_BROKEN_PROXY_FUDGE ) più o meno qui, un po’ come per come gli script di test non sono compressi permetterebbero a Digital Ocean Spaces e Cloudflare R2 di funzionare con Discourse fin da subito, il che è una bella aggiunta di funzionalità con poco sforzo? Magari da considerare in futuro comunque.
Oh, ho visto nelle note di rilascio della 3.0.beta che è stato aggiunto qualcosa. Ci proverò, a meno che non abbia capito male a cosa serve? Potrebbe consentire l’uso di Cloudflare R2 e Digital Ocean Spaces con le loro CDN che fanno cose strane con gzip.
L’impostazione mi ha permesso di specificare il sito locale come origine, per aggirare la necessità che gli asset js fossero sul sito S3 (in questo caso Cloudflare o Digital Ocean Spaces con CDN abilitato). Grazie a @david per la modifica, anche se non era l’intenzione.
sembra che sia stato risolto di recente.
Nel changelog del 16/03/2023 è elencata una correzione di bug per la gestione dei file gzip.
Stiamo eseguendo il nostro forum discourse su discourse.aosus.org con R2 in questo momento (non abbiamo ancora eseguito migrate_to_s3), e sembra che vada tutto bene! Nessun problema evidente finora.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" #alias to auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true #dovrebbe essere supportato
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: il tuo url cdn
DISCOURSE_S3_BUCKET: NOME_BUCKET
c’è un modo per specificare un host separato per i backup? Sarebbe fantastico se fosse possibile lasciare R2 solo per le cose CDN.
È strano che le impostazioni in ENV non vengano riflesse nell’interfaccia utente di amministrazione. Si verifica una sovrascrittura? Le nuove impostazioni di S3 nell’interfaccia utente di amministrazione sovrascriveranno quelle nell’ambiente?
) più o meno qui, un po’ come per come gli 