Non sono riuscito a capire perché nell’ultimo aggiornamento la nostra installazione abbia smesso di servire le risorse tramite CDN. Stiamo utilizzando Cloudfront e funzionava bene per servire sia i file caricati che le risorse, ma sembra che nell’ultimo aggiornamento le risorse vengano servite direttamente dal server.
Un altro problema che stiamo riscontrando è che, se passiamo la variabile DISCOURSE_CDN_URL, Discourse inizia a richiedere risorse che non vengono generate o caricate dall’attività s3:upload_assets (ad esempio fogli di stile). Questo rompe completamente il sito, mostrando una pagina bianca. Questo post menziona qualcosa di simile.
Ho rimosso DISCOURSE_CDN_URL, che era impostato sullo stesso valore di DISCOURSE_S3_CDN_URL, perché rompeva il sito (provava a caricare risorse che non esistevano su S3).
Ripensando al sito con cui avevo problemi, sembra che avessi omesso https:// nell’URL del CDN che stavo utilizzando. Non sono chiaro su come mai abbia funzionato in passato, oppure, se non ha mai funzionato, su come non abbia notato il problema quando ho inserito il valore errato.
@eatcodetravel, ovviamente devi oscurare le password SMTP e le chiavi S3, ma penso che dovrai condividere almeno i valori del CDN affinché qualcuno possa ipotizzare quale possa essere il problema.
Sì, ho dovuto rimuovere DISCOURSE_CDN_URL; ha iniziato a richiedere risorse che non vengono caricate su S3 dall’attività rake s3:upload_assets, e questo rompe completamente il sito. Forse questa è la parte che è cambiata e dobbiamo aggiornare rake s3:upload_assets affinché funzioni correttamente di nuovo.
Sì, è possibile utilizzare lo stesso URL CDN sia per DISCOURSE_CDN_URL che per DISCOURSE_S3_CDN_URL, ma ciò richiede molte configurazioni di login sulla CDN per utilizzare la sorgente corretta per ogni risorsa in base all’URL. Ad esempio, il CSS proviene dall’applicazione, il JS da S3, e questo è solo un caso: ne abbiamo dozzine.
L’aspettativa è quindi che impostiate entrambi: DISCOURSE_CDN_URL funge da “proxy” per la vostra applicazione web, mentre DISCOURSE_S3_CDN_URL è un proxy per il vostro bucket di archiviazione oggetti.
Ah ok, è qualcosa che è cambiato di recente? Non sono sicuro che CloudFront supporti la configurazione come reverse proxy per la nostra app invece che per un bucket S3.
Vedo che stai usando CloudFront nella meta, c’è qualcosa di speciale che fai per farlo funzionare o è Discourse stesso a occuparsi di tutto?
Se ispezioni questa pagina, vedrai che abbiamo due diversi URL di CloudFront, quindi utilizziamo quanto detto sopra: due distribuzioni, una per il CDN normale e un’altra per S3.
Il problema menzionato nel titolo dell’OP è questo: il CSS proviene dall’applicazione e il JS da S3. Serve un CDN che sappia da dove proviene ogni singola risorsa e possa raggiungere il luogo necessario, oppure due CDN. È per questo che abbiamo due impostazioni diverse, dopotutto.
Anche se ora che lo capisco ha tutto senso, non sono sicuro che sia documentato. E rischi di avere dei problemi (almeno io li ho avuti!), perché il task rake move-uploads-to-s3 richiede che tu abbia un s3_cdn. Questo spiega perché più volte ho provato a spostare le cose su S3 e ho finito per arrendermi.
Penso che sarebbe bello se ci fosse un avviso tipo: “Ehi, non puoi avere un CDN S3 senza un CDN per le risorse” da qualche parte.
Ok, ora capisco cosa stai dicendo; non sapevo che questo fosse necessario. Posso chiedere perché il CSS debba provenire dall’app? Perché non possiamo caricarlo tramite il task rake s3:upload_assets?
Farò alcune ricerche su come realizzare questo su Cloudfront e condividerò qui i miei risultati e gli eventuali ostacoli.
Beh, forse sto spiegando male. Puoi farlo. Ma è complicato, come dimostrano i tuoi argomenti e questo in particolare.
Il sito di @eatcodetravel è attualmente in esecuzione con solo S3_CDN impostato, ma poi si finisce in una situazione strana dove il CSS (che blocca il rendering) viene servito dal tuo server, mentre le immagini nei post no, il che non ha senso.
Perché “Amministrazione > Personalizza” esiste. Le persone possono modificare il CSS dal pannello di amministrazione. Anche gli snippet JS personalizzati presenti nei temi vengono serviti dall’app, per quanto ne so.
Alla fine ho risolto il problema fornendo una seconda distribuzione Cloudfront che punta al server web, mantenendo l’altra solo per S3. Grazie a @Falco per il feedback, ma concordo sul fatto che questo aspetto debba essere documentato un po’ meglio.
s”?