Il supporto/compatibilità di Contabo S3 verrà aggiunto? o qualcuno ha trovato una soluzione per farlo funzionare?
2 Mi Piace
Noi, i manutentori di Discourse, supportiamo solo AWS S3. I provider elencati qui sono stati testati da noi o dalla community per vedere se implementano abbastanza dell’API S3 da essere compatibili con Discourse.
Come da OP, @tuxed ha testato Contabo e l’ha trovato carente. Spetta a Contabo evolvere la conformità della propria implementazione con S3, se lo ritengono in linea con i propri interessi commerciali, non è qualcosa che possiamo fare.
4 Mi Piace
È ancora difettoso? Perché la CDN di Digitalocean non è buona?
1 Mi Piace
Hai seguito i link?
Sembra che il CDN non conosca i metadati. Ma potresti provare a vedere se funziona! Facci sapere se lo fai. Mi stavo chiedendo se fosse stato risolto proprio l’altro giorno. Dall’aspetto della documentazione, non ho intenzione di provarlo presto.
2 Mi Piace
Sto cercando un modo semplice per aggiungere il supporto CDN al mio forum su DigitalOcean. Se S3 è più facile, opterei per quella soluzione.
Non voglio correre rischi con una configurazione che non ha funzionato bene in precedenza.
2 Mi Piace
La soluzione consigliata è semplicemente non utilizzare la loro CDN. Puoi usare Spaces, se segui le istruzioni sopra e qualcosa come bunny.net per la CDN. È economico e facile.
AWS S3 è ciò che usa cdck, quindi è un po’ meglio testato e supportato, ma a meno che tu non abbia già dimestichezza con AWS, il bucket Spaces è una buona soluzione. Semplicemente non usare la CDN di DigitalOcean.
2 Mi Piace
Ci sono appena passato - configurazione CDN, per ora mantengo le immagini locali - prima con Fastly, poi con qualcos’altro che non ricordo. Mi sono fermato a Bunny.net. Molto facile da configurare. Hanno guide specifiche per Discourse. Siamo self-hosted in DO con oltre 100 GB di immagini. Tasso di cache hit del 65% e in aumento.
2 Mi Piace
la policy del tombstone di configurazione s3 funziona solo su aws.amazon?
1 Mi Piace
No. È un problema solo su Backblaze.
2 Mi Piace
3 post sono stati divisi in un nuovo argomento: Esplorazione di soluzioni per problemi di caricamento dell’immagine del profilo utente
Whew, da dove comincio? Sto usando Cloudflare per la cache e il DNS, e Backblaze B2 per lo storage. Sono riuscito a farlo funzionare, ma solo parzialmente. Durante un ./launcher rebuild app ho visto che stava caricando gli asset, quindi ero super entusiasta che sembrasse funzionare. Dopo che la ricostruzione è stata completata con successo, non sono riuscito ad accedere al sito. Vedo solo dei puntini che si muovono al centro della pagina.
Basandomi sull’articolo di Backblaze Deliver Public Backblaze B2 Content Through Cloudflare CDN ho impostato un record CNAME proxato che punta all’origine dell’URL friendly f000.backblazeb2.com chiamato gtech-cdn.
CNAME gtech-cdn –\u003e f000.backblazeb2.com
L’articolo parla anche di Page Rules; ho provato ad attivarle e disattivarle senza successo.
Ecco gli elementi di configurazione pertinenti:
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
Nella sezione **hooks:**...
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
Una delle cose che mi confonde è cosa inserire nelle due variabili DISCOURSE_S3_CDN_URL e DISCOURSE_CDN_URL. Le ho impostate correttamente in base alle informazioni che ho fornito?
Guardando la console degli strumenti per sviluppatori del browser, ricevo errori 404 sugli script .js. L’URL non sembra essere costruito correttamente. Non dovrebbe esserci /file/ prima di /assets? Se lo aggiungo manualmente per creare un URL corretto, funziona:
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
Grazie per qualsiasi aiuto, è molto apprezzato!!!
1 Mi Piace
https://gtech-cdn.mmhmm.com non si risolve, quindi questa è la prima cosa da sistemare.
Non sono sicuro che tu possa usare Cloudflare come CDN in quel modo, ma forse mi sbaglio.
1 Mi Piace
Mi dispiace, avrei dovuto menzionare che mmhmm.com è un dominio fittizio. Risponde a un ping.
Per quanto riguarda Cloudflare non poter essere utilizzato come CDN, immagino di non capire. L’articolo che ho linkato è chiaramente per usarlo come CDN. Se ciò non è vero, allora di nuovo, quali valori devono essere utilizzati nelle due variabili DISCOURSE_S3_CDN_URL e DISCOURSE_CDN_URL?
Saluti,
Se fornisci URL finti, puoi ottenere solo risposte fittizie.
L’URL serve i dati attesi? Puoi recuperarli dall’URL del forum?
Penso che la CDN S3 dovrebbe funzionare. Sta usando l’URL del forum per la CDN del forum, ma non ne sono sicuro.
Una normale CDN ha un URL diverso dal forum e la CDN può contare sui dati statici piuttosto che dover indovinare cosa sia dinamico.
1 Mi Piace
Faccio del mio meglio per non diffondere le mie informazioni su vari forum, quindi scusate la mia segretezza in merito.
Il forum si trova su “https://mmhmm.com”, che è un record DNS di Cloudflare che viene proxato (messo in cache). Prima di configurare Discourse per utilizzare Backblaze, tutto funzionava correttamente.
“https://gtech-cdn.mmhmm.com”, come affermato in precedenza, si risolve e risponde anche a un ping. Anche il target del record CNAME, f000.backblazeb2.com, si risolve. Quell’origine URL B2 Friendly è ciò che l’articolo istruisce a utilizzare. Tuttavia, non è questo il problema. Il problema è che Discourse sta fornendo URL per i file .js utilizzando un URL non valido che non funzionerà mai perché manca la parte “/file/gtech-cdn” del percorso. Se prendi uno di quegli URL .js incompleti e aggiungi manualmente le informazioni mancanti, caricherà correttamente il testo del file .js.
Naturalmente, sto ancora cercando di capire come tutto questo dovrebbe funzionare con queste due variabili. Sono più un tipo che impara visivamente e potrei davvero usare un diagramma di flusso o qualcosa del genere per aiutarmi a capire cosa dovrebbe succedere con le interazioni tra Cloudflare CDN, Discourse e Backblaze B2.
Grazie per il tuo aiuto.
Inoltre, tenterò di rispondere alla tua ultima frase su un CDN normale…
L’articolo di Backblaze ti fa creare due regole di pagina per bucket (nel mio caso viene utilizzato 1 bucket), che, se ho capito bene, sono in qualche modo simili a una regola firewall nel modo in cui elaborano.
La Regola 1 dice che https://gtech-cdn.mmhmm.com/file/*/* dovrebbe utilizzare la cache standard (che è impostata altrove in Cloudflare a 1 mese)
La Regola 2 reindirizza qualsiasi cosa (302 - reindirizzamento temporaneo) che non corrisponde al pattern della Regola 1.
Quindi non tutto verrà memorizzato nella cache andando su mmhmm.com… almeno questa è la mia comprensione.
MODIFICA: Non ha funzionato.
Concentrandomi un po’ di più su questo, ho deciso, per ovvie ragioni, di utilizzare l’URL S3 come destinazione del CNAME invece dell’URL amichevole suggerito dall’articolo di Backblaze. Ora sto solo aspettando la scadenza del TTL del record DNS.
Per quanto riguarda questo hook:
Non vedo nulla con s3 nel dump di rake --tasks. È ancora pertinente o mi manca qualche plugin?
Vedo anche questo quando eseguo manualmente:
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: Alcuni upload non hanno potuto essere migrati al nuovo schema. Devi correggerlo manualmente. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Vedi il trace completo eseguendo il task con --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Si prega di notare che la migrazione a S3 al momento non è reversibile!
6 post sono stati divisi in un nuovo argomento: Cloudflare R2: Navigare l’impostazione e gestire gli errori di configurazione
Sembra che Cloudflare funzioni ora:
Vedi Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 Mi Piace