Configura un provider di archiviazione oggetti compatibile con S3 per i caricamenti

[Discourse]

Questo argomento tratta la configurazione di alcuni provider di Object Storage compatibili con S3 comuni (cloni S3). Consulta Set up file and image uploads to S3 per maggiori dettagli sulla configurazione di Amazon AWS S3, che è ufficialmente supportata e utilizzata internamente da Discourse per i nostri servizi di hosting.

Provider	Nome Servizio	Funziona con Discourse?
Amazon AWS	S3	Sì
Digital Ocean	Spaces	Sì
Linode	Object Storage	Sì
Google Cloud	Storage	Sì
Scaleway	Object Storage	Sì
Vultr	Object Storage	Sì
BackBlaze	Cloud Storage	Sì*
Self-hosted	MinIO	Sì
Azure Blob Storage	Flexify.IO	Sì
Oracle Cloud	Object Storage	No [1]
Wasabi	Object Storage	Forse
Cloudflare	R2	Sì
Contabo	Object Storage	No

Se hai fatto funzionare un servizio diverso, aggiungilo a questa wiki.

Configurazione

Per memorizzare le risorse statiche di Discourse nel tuo Object Storage, aggiungi questa configurazione nel tuo app.yml sotto la 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

Quando si utilizza l’object storage, è inoltre necessario un CDN per servire ciò che viene memorizzato nel bucket. Ho utilizzato StackPath CDN nei miei test e, a parte la necessità di impostare Dynamic Caching By Header: Accept-Encoding nella loro configurazione, funziona bene.

DISCOURSE_CDN_URL è un CDN che punta al tuo hostname Discourse e memorizza nella cache le richieste. Sarà utilizzato principalmente per le risorse scaricabili: CSS e altre risorse del tema.

DISCOURSE_S3_CDN_URL è un CDN che punta al tuo bucket di object storage e memorizza nella cache le richieste. Sarà utilizzato principalmente per le risorse caricabili: JS, immagini e caricamenti degli utenti.

Consigliamo che questi siano diversi e che gli amministratori impostino entrambi.

Non utilizzare un CDN (o inserire l’URL del bucket come URL CDN) è probabile che causi problemi e non è supportato.

Negli esempi seguenti, https://falcoland-files-cdn.falco.dev è un CDN configurato per servire i file sotto il bucket. Il nome del bucket è stato impostato su falcoland-files nei miei esempi.

Si consiglia di configurare queste impostazioni nelle variabili d’ambiente nel tuo app.yml, poiché è così che CDCK lo fa nella propria infrastruttura, quindi è ben testato. Inoltre, l’attività di caricamento delle risorse avviene dopo la compilazione delle risorse, che avviene durante un rebuild. Se desideri avviare un Discourse che funzioni correttamente con l’object storage fin dall’inizio, devi impostare le variabili d’ambiente in modo che le risorse vengano caricate prima che il sito venga avviato.

Scegli il tuo provider dall’elenco qui sotto e aggiungi queste impostazioni alla sezione env del tuo file app.yml, regolando i valori di conseguenza:

AWS S3

Ciò che supportiamo ufficialmente e utilizziamo internamente. La loro offerta CDN Cloudfront funziona anche per fronteggiare i file del bucket. Consulta Set up file and image uploads to S3 per sapere come configurare correttamente i permessi.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-west-1
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Digital Ocean Spaces

L’offerta DO è buona e funziona fuori dalla scatola. È corretto abilitare la restrizione dell’elenco dei file. L’unico problema è che la loro offerta CDN è terribilmente rotta, quindi devi utilizzare un CDN diverso per i file. Inoltre, non devi installare la regola CORS, poiché viene reinstallata ad ogni rebuild.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false 

Linode Object Storage

È richiesto un parametro di configurazione aggiuntivo, HTTP_CONTINUE_TIMEOUT, per Linode.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Google Cloud Platform Storage

L’elenco dei file è rotto, quindi hai bisogno di una variabile d’ambiente aggiuntiva per saltarlo in modo che le risorse funzionino. Salta anche CORS e configuralo manualmente.

Poiché non puoi elencare i file, non sarai in grado di elencare i backup e i backup automatici falliranno; non consigliamo di utilizzarlo per i backup. Tuttavia, alcuni suggeriscono che se cambi il ruolo da Storage Legacy Object Owner a Storage Legacy Bucket Owner, i backup funzionano correttamente. Consulta questo argomento per una discussione specifica su Google Cloud.

Esiste un plugin di terze parti per migliorare l’integrazione su Discourse GCS Helper.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east1
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  FORCE_S3_UPLOADS: 1
  DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  #DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  #DISCOURSE_BACKUP_LOCATION: s3

Scaleway Object Storage

L’offerta Scaleway è anche molto buona e tutto funziona bene per la maggior parte.

I caricamenti multipart di Scaleway supportano solo un massimo di 1.000 parti. Questo non corrisponde ad Amazon S3, che supporta un massimo di 10.000 parti. Per istanze più grandi, questo causerà il fallimento dei backup di Discourse e il caricamento incompleto potrebbe dover essere eliminato manualmente prima di ulteriori tentativi. Per istanze piccole questo non è un problema. Scaleway sembra molto aperta ai feedback, quindi se vuoi che questo limite venga modificato, dovresti contattarli.

Nota che per il parametro DISCOURSE_S3_ENDPOINT, Discourse utilizza l’endpoint dell’intera regione: https://s3.{region}.scw.cloud. L’endpoint del bucket trovato nella dashboard di Scaleway viene fornito sotto forma di https://{bucketName}.s3.{region}.scw.cloud. Ometti il sottodominio del nome del bucket per evitare errori di connessione.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: fr-par
  DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Vultr Object Storage

È richiesto un parametro di configurazione aggiuntivo, HTTP_CONTINUE_TIMEOUT, per Vultr.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Backblaze B2 Cloud Storage

Devi saltare CORS e configuralo manualmente.

Ci sono segnalazioni che indicano che la funzione clean up orphan uploads non funziona correttamente con BackBlaze. Devi modificare le regole di ciclo di vita per il tuo bucket affinché la pulizia degli orfani funzioni.

Configurazione di esempio:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: "us-west-002"
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
  DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Nota: Durante la migrazione iniziale a B2, potresti raggiungere il limite gratuito giornaliero di 2500 transazioni di classe C. Dovrai aggiungere un metodo di pagamento per rimuovere i limiti.

MinIO Storage Server

Ci sono alcune avvertenze e requisiti che devi assicurarti di soddisfare prima di poter utilizzare il server di storage MinIO come alternativa a S3:

1. Hai un’istanza del server MinIO completamente configurata
2. Hai abilitato il supporto dei domini nella configurazione di MinIO, per gli URL degli bucket basati sul dominio. Questo è un requisito obbligatorio per MinIO e Discourse, poiché MinIO supporta ancora gli stili “path” S3 legacy che non sono più supportati in Discourse.
3. Hai configurato correttamente il DNS per MinIO in modo che i sottodomini degli bucket risolvano correttamente al server MinIO e il server MinIO sia configurato con un dominio di base (in questo caso, minio.example.com)
4. Il bucket discourse-data esiste sul server MinIO e ha una policy “pubblica” impostata su di esso
5. Il tuo URL CDN S3 punta a un CDN correttamente configurato che punta al bucket e memorizza nella cache le richieste, come indicato in precedenza in questo documento.
6. I tuoi CDN sono configurati per utilizzare effettivamente un’intestazione “Host” dell’URL S3 principale - ad esempio, discourse-data.minio.example.com quando recupera i dati - altrimenti può causare problemi CORB.

Assumendo che le avvertenze e i prerequisiti sopra siano soddisfatti, una configurazione di esempio sarebbe qualcosa del genere:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: anything
  DISCOURSE_S3_ENDPOINT: https://minio.example.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
  DISCOURSE_S3_BUCKET: discourse-data
  DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

CORS sarà comunque abilitato su MinIO anche se la regola non viene installata dal rebuild dell’app - di default, sembra, CORS è abilitato su tutti i verbi HTTP in MinIO, e MinIO non supporta BucketCORS (API S3) di conseguenza.

Azure Blob Storage con Flexify.IO

Azure Blob Storage non è un servizio compatibile con S3, quindi non può essere utilizzato con Discourse. Esiste un plugin, ma è rotto.

Il modo più semplice per esporre un’interfaccia compatibile con S3 per Azure Blob Storage è aggiungere un server Flexify.IO che traduce il protocollo di archiviazione di Azure in S3.

Al momento della stesura di questo documento, il servizio è gratuito su Azure e hai bisogno solo di un tier VM molto base (economico) per iniziare a eseguirlo. Tuttavia, richiede un po’ di configurazione.

1. Nel portale di Azure, crea una nuova risorsa di Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. Per un utilizzo leggero, la configurazione VM minima sembra funzionare bene. Puoi accettare la maggior parte della configurazione predefinita. Ricordati di salvare il file della chiave PEM quando crei la VM.
3. Naviga al link della VM Flexify.IO e accedi al sistema. Segui le istruzioni impostando il provider di dati Azure Blob Storage e l’endpoint S3 generato. Assicurati che l’impostazione della configurazione dell’endpoint Public read access to all objects in virtual buckets sia vera. Copia l’URL e le chiavi dell’endpoint S3.
4. Premi New Virtual Bucket e crea un bucket virtuale. Può avere lo stesso nome del tuo contenitore Azure Blob Storage o può essere un nome diverso. Collega qualsiasi contenitore per unirlo a questo bucket virtuale. Questo bucket virtuale viene utilizzato per esporre un bucket leggibile pubblicamente tramite S3.
5. Di default, Flexify.IO installa un certificato SSL autofirmato, mentre un endpoint S3 richiede HTTPS. Connettiti via SSH alla VM utilizzando il file della chiave (il nome utente è di default azureuser) e sostituisci i seguenti file con quelli corretti:

• /etc/flexify/ssl/cert.pem - sostituisci con il file del certificato (codifica PEM)

• /etc/flexify/ssl/key.pem - sostituisci con il file della chiave privata (codifica PKCS#8 PEM, ovvero quello che inizia con BEGIN PRIVATE KEY e non BEGIN RSA PRIVATE KEY che è PKCS#1)

  Questi file sono di root, quindi dovrai usare sudo per sostituirli. È meglio assicurarsi che i file di sostituzione abbiano la stessa proprietà e gli stessi permessi degli originali, ovvero root:root e permesso 600.

6. Di default, Flexify.IO crea un servizio S3 a livello di root con più bucket. Discourse richiede il supporto dei sottodomini per i bucket. Vai a: <your Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1 che aprirà una pagina di configurazione _nascosta`!
7. Specifica il dominio di base S3 (diciamo s3.mydomain.com) nel campo Endpoint hostname, che dovrebbe essere vuoto di default. Premi Save per salvare l’impostazione.
8. Riavvia la VM Flexify.IO nel portale di Azure.
9. Nel tuo DNS, mappa s3.mydomain.com e *.s3.mydomain.com all’IP della VM Flexify.IO.
10. In Discourse, imposta quanto segue nella pagina di amministrazione (sì, non è necessario che le impostazioni siano in app.yml):

use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket>  (qualsiasi contenitore va bene, poiché non richiede accesso in lettura pubblico e Flexify.IO li esporrà automaticamente)
backup location: s3

Non è consigliabile utilizzare lo stesso bucket per produzione e staging. Se lo fai comunque, prendi misure per assicurarti che il tuo sito di staging non elimini le risorse di produzione (imposta almeno s3 disable cleanup e controlla che non elimini i backup di produzione).

Wasabi

@pfaffman ha provato Wasabi per i backup, ma sembrava fallire intermittente e silenziosamente, lasciando i backup sull’hard disk e alla fine riempiendo il disco. Né Wasabi né meta avevano indizi, quindi non lo consiglio, anche se i tuoi risultati potrebbero variare. @pfaffman è ora abbastanza sicuro che questo problema fosse dovuto al fatto che i backup e i riavvii automatici erano in qualche modo programmati nello stesso momento; era usato solo per i backup, ma sembrava funzionare bene. Se qualcuno vuole provarlo e riferire qui, dovrebbe funzionare, almeno per i backup.

Oracle Cloud

Oracle Cloud non supporta l’accesso agli bucket in stile virtual-host e non funzionerà

Cloudflare R2

Per configurare Cloudflare R2, dovrai configurare le impostazioni pertinenti nella dashboard di Cloudflare sotto R2 Object Storage.

A seconda delle tue esigenze (caricamenti o backup o entrambi), queste sono le impostazioni pertinenti da inserire nel tuo file app.yml o nella tua ricerca Admin-All site settings per S3:

  DISCOURSE_ENABLE_S3_UPLOADS: true
  DISCOURSE_S3_REGION: auto
  DISCOURSE_S3_ENDPOINT: https://<your-account-id>.r2.cloudflarestorage.com
  DISCOURSE_S3_ACCESS_KEY_ID: "xxx"
  DISCOURSE_S3_SECRET_ACCESS_KEY: "xxx"
  DISCOURSE_S3_UPLOAD_BUCKET: your-upload-bucket-name
  DISCOURSE_S3_CDN_URL: https://uploads.yourdomain.com
# DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true

  DISCOURSE_ENABLE_DIRECT_S3_UPLOADS: true
  DISCOURSE_S3_USE_ACLS: false
  
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_BACKUP_BUCKET: your-backup-bucket-name

Se non vuoi modificare il tuo app.yml, puoi farlo nell’interfaccia di amministrazione:

“Admin → All site settings” (cerca S3):

• Abilita caricamenti S3 = true
• Abilita caricamenti S3 diretti = true
• ID chiave di accesso S3 = "xxx"
• Chiave segreta di accesso S3 = "xxx"
• Regione S3 = any
• Bucket di caricamento S3 = your upload bucket name
• Endpoint S3 = https://<your-account-id>.r2.cloudflarestorage.com
• URL CDN S3 = https://uploads.yourdomain.com
• Usa ACL S3 = false (disabilita questo!)
• Bucket di backup S3 = your backup bucket name
• Posizione backup = S3

Note:

1. Permessi del token API: Poiché Discourse ha solo un insieme di campi di credenziali, il token API che generi in Cloudflare deve avere il permesso di accedere sia al tuo bucket di caricamento che al tuo bucket di backup. Quando crei il tuo token, seleziona “Applica a tutti i bucket” o usa “Applica a bucket specifici” e assicurati che entrambi siano selezionati. Inoltre, assicurati di spuntare Object Read & Write quando crei la chiave API (il default è solo Object Read only).

2. Quando copi l’URL dell’endpoint da Cloudflare, potrebbe aggiungere il nome del bucket all’URL - dovresti eliminare il nome del bucket dalla fine della stringa nel tuo file .yml se viene incollato.

3. Rimuovi il commento da # DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true se vuoi utilizzare il tuo bucket di caricamento R2 per tutti i caricamenti, inclusi i file PDF e ZIP. (Nota che questo renderà tutti i file caricati pubblicamente disponibili tramite link diretto)

4. Se abiliti DISCOURSE_ENABLE_DIRECT_S3_UPLOADS (true), allora dovresti disabilitare DISCOURSE_S3_USE_ACLS (false). Questo perché Cloudflare R2 utilizza permessi a livello di bucket; il tuo bucket di caricamenti dovrebbe essere pubblico e il bucket di backup dovrebbe essere privato. Per i caricamenti Cloudflare R2, NON devi configurare le attività rake delle regole CORS o scrivere IAM json, poiché lo configurerai nella dashboard di Cloudflare quando imposti i permessi del tuo bucket. Il token “Object Read & Write” di Cloudflare concede automaticamente i permessi per i caricamenti multipart, e incollare la seguente regola CORS direttamente nelle impostazioni del bucket di caricamenti R2 nella dashboard di Cloudflare sotto CORS Policy sostituisce la necessità dell’attività rake.

[
  {
    "AllowedOrigins": [
      "https://forum.yourdomain.com"
    ],
    "AllowedMethods": [
      "GET",
      "PUT",
      "POST",
      "DELETE",
      "HEAD"
    ],
    "AllowedHeaders": [
      "*"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3000
  }
]

Contabo

@tuxed ha provato a far funzionare Contabo Object Storage per i caricamenti compatibili con S3. Sembra che durante il caricamento aggiunga il nome del repository all’URL e non è riuscito a farlo funzionare.

Caricamenti sicuri

I caricamenti sicuri sono supportati solo per AWS S3. Se il tuo rake uploads:migrate_to_s3 fallisce, dovresti inserire questi comandi per prima cosa contare e poi segnare come non sicuri quei caricamenti, dato che sai che non hanno bisogno di essere sicuri, nel qual caso, dovrai utilizzare AWS S3.

./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)

---

1. Oracle Cloud non supporta l’accesso agli bucket in stile virtual-host e non funzionerà ↩︎

[Richie (Richie Rich)]

Ciao a tutti,

Utilizzo lo storage S3 da diversi anni senza una CDN.

Seguendo il consiglio ricevuto in un altro thread, oggi ho configurato la CDN CloudFront.

Prima di aggiungere l’URL della CDN al mio pannello di controllo e rigenerare oltre 230.000 post solo per scoprire di aver impostato male CloudFront e rompere tutto, potreste confermarmi che questo è il comportamento atteso per me?

Attualmente, ecco un esempio di URL per un’immagine caricata da un utente:

https://greyarrows.s3.dualstack.eu-west-2.amazonaws.com/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png

Che viene visualizzata così:

Il “Domain Name” della mia CloudFront è: d1q8cepst0v8xp.cloudfront.net

Se modifico manualmente l’URL di esempio sopra e sostituisco la parte esistente S3 del nome di dominio con il nome di dominio della mia CloudFront, ottengo:

https://d1q8cepst0v8xp.cloudfront.net/original/3X/8/3/8335cab232f512f4a979c7f0c8562e149c01b212.png

E infatti, l’immagine si carica correttamente:

Quindi, ho ragione a pensare che debba semplicemente aggiungere un URL CDN S3 di d1q8cepst0v8xp.cloudfront.net al mio pannello di controllo Discourse, rigenerare tutti i post e poi rilassarmi in attesa che la magia avvenga?

Grazie in anticipo, la CDN è tutta nuova per me e non ho un ambiente di sviluppo in cui testarla in sicurezza

[Richie (Richie Rich)]

Ho anche abilitato l’impostazione s3 configure tombstone policy:

Questo sarà un problema? Dato che ora sto usando una CDN? O le operazioni in background controllano ancora il bucket S3 originale, invece di un URL CDN?

Penso naturalmente che sia quest’ultimo caso, ma non posso permettermi di bloccare i caricamenti di foto di centinaia di migliaia dei miei utenti

[Richie (Richie Rich)]

@Richie

Quindi, ho capito bene che devo solo aggiungere l’URL CDN S3 di d1q8cepst0v8xp.cloudfront.net al pannello di controllo di Discourse, rifare il baking di tutti i post e poi sedermi e aspettare che la magia avvenga?

La risposta è sì.

Per testare questa teoria, prima di rifare il baking di centinaia di migliaia di post, ho eseguito i seguenti controlli di coerenza:

• Ho caricato un’immagine
• Ho modificato l’impostazione dell’URL CDN S3
• Ho ricostruito l’HTML del mio post di prova (tramite l’interfaccia utente)
• Ho aggiornato la pagina nel browser
• Ho controllato la scheda Network della console del browser per confermare che l’immagine venisse caricata tramite CloudFront
• Ho caricato una nuova immagine di prova in un nuovo post
• Ho controllato la scheda Network della console del browser per confermare che l’immagine venisse caricata tramite CloudFront

Al momento sto rifacendo il baking di tutti i post

[scottfsmith (Scott Smith)]

Grazie per la segnalazione, Richie. Anche io ho utilizzato l’archiviazione immagini di AWS S3 per diversi anni e sono arrivato a questo post tramite il messaggio della console. Tuttavia, la descrizione in alto non menziona il caso in cui si dispone già di S3 e si ha semplicemente bisogno di una CDN.

Per completezza, ecco cosa ho fatto:

1. Sono andato alla console di AWS, sotto Network and Content Delivery ho selezionato CloudFront.
2. Ho cliccato sul pulsante Create distribution.
3. Ho compilato il modulo abbastanza intuitivo; l’unica cosa che dovevo davvero fare era selezionare il bucket AWS S3 contenente le immagini dal menu a discesa.
4. Ho aspettato qualche istante il completamento della configurazione di CloudFront.
5. Un dominio <gibberish>.cloudfront.net è apparso nella colonna “Domain Name” dell’elenco delle distribuzioni CloudFront.
6. Ho copiato e incollato quel dominio nel campo s3 cdn url nelle impostazioni File dell’amministrazione del mio sito.
7. Ho eseguito alcuni test:
   a. Ho creato un nuovo post con un’immagine caricata e ho confermato che era su CloudFront.
   b. Ho cliccato su Rebuild HTML su alcuni post esistenti con immagini a caso e ho visto che sono stati ricostruiti con immagini cloudfront.net.
8. Poiché tutto sembrava funzionare correttamente, ho avviato un rebake, che ha richiesto diverse ore dato che ora ho circa mezzo milione di post:

./launcher enter app
# rake posts:rebake

9. Tutto sembra funzionare bene. Ha inserito un sacco di job nella coda di Sidekiq, uno per ogni post a quanto pare, che richiederanno alcuni giorni per essere elaborati, ma sta già lavorando su di essi a blocchi.

[Falco]

Sei sicuro che sia così? Questo sito utilizza asset da CDN e non abbiamo dovuto svuotare la cache. Inoltre, si tratta di una modifica EmberCli che non dovrebbe influire sulla produzione

[Falco]

Oh, quei dannati ottimizzatori. Ti consiglierei di disabilitarli se possibile, dato che Discourse include già configurazioni ottimali per ogni risorsa. Questi ottimizzatori sono ottimi quando si ospita un software web “black box” degli anni 2000, ma falliscono miseramente con le tecnologie moderne. Inoltre, persino il famoso ottimizzatore di Cloudflare spesso rompe Discourse, quindi non mi faccio troppe speranze per gli altri. Potrebbero funzionare un giorno e rompere tutto il giorno dopo, lasciando tutti i visitatori con una pagina vuota. Tutto questo senza alcun beneficio.

[Falco]

C’è la possibilità che tu abbia abilitato secure_uploads nelle impostazioni del sito?

Sembra anche che questo problema sia stato segnalato e risolto oggi a causa della compatibilità con Discourse:

Regression: dummy PutObjectACL now throwing 501 Not Implemented

fix: muxing order for rejected APIs (#12321)

[smlbiobot (SML)]

C’è un modo per disabilitare questo avviso che appare sulla mia dashboard di amministrazione?

Il server è configurato per caricare file su S3, ma non è configurato nessun CDN S3.

Ho avuto problemi a configurare un CDN S3, ma non mi costa un occhio della testa, quindi mi va bene usare direttamente S3. Tuttavia, mi piacerebbe molto che questa notifica scomparisse, poiché sono pienamente consapevole delle conseguenze.

[tuanpembual (Estu Fardani)]

Ciao.

Voglio solo dare un aggiornamento. Ora saremo in grado di configurare il backup utilizzando GCS. L’ho pubblicato anche in un altro thread. Spero che questo possa aiutare altre persone che hanno cercato con difficoltà questa soluzione.

Come fare?
Abilita la configurazione predefinita per il backup (o puoi impostarla dal pannello di amministrazione).

DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3

Quindi imposta i permessi del bucket come Storage Legacy Object Owner:

1. Vai al tuo progetto nella Google Cloud Console
2. Seleziona Storage
3. Seleziona il tuo bucket
4. Vai alla scheda Permessi
5. Aggiungi un nuovo permesso, inserisci l’email del tuo account di servizio con il tuo account. Per i ruoli, seleziona Storage Legacy Object Owner
6. Salva ed è fatto.

Scusa per il doppio post, volevo solo condividere questo buon aggiornamento.
Grazie

[tenzan (Askar)]

Sarebbe fantastico se poteste aggiungere anche Wasabi…

[pfaffman (Jay Pfaffman)]

Ho usato Wasabi per i backup per un po’. Per quanto riguarda la configurazione, “ha funzionato semplicemente”, quindi potresti provarlo se vuoi.

Tuttavia, con una certa frequenza i backup fallivano in modo silenzioso e rimanevano sul computer locale, riempiendo il disco. Ho esaminato gli errori di Wasabi e di Discourse, ma non ho mai trovato una spiegazione che permettesse a una delle due parti di “risolvere” qualcosa.

Non lo consiglio, poiché non sono sicuro che sia “eccellente.”

[tenzan (Askar)]

Grazie!
Controllerò come va questa volta.
La frequenza di backup predefinita è di 7 giorni tra un backup e l’altro, con un massimo di 5 backup.
Condividerò come va.

[pfaffman (Jay Pfaffman)]

Facevo backup quotidiani; non ricordo quanti ne volessi conservare, ma l’hard disk locale aveva spazio solo per un paio.

[tenzan (Askar)]

Quale archiviazione consiglieresti personalmente?
Non credo che AWS e Azure siano convenienti per progetti personali.
Non sono sicuro riguardo ad Azure, ma AWS sembra confuso e imprevedibile…

[pfaffman (Jay Pfaffman)]

Speravo che Wasahi fosse almeno buono per i backup. Backblaze S3 è conveniente. Non credo di averlo usato per gli upload, ma funziona per i backup (credo). Penso che l’unico problema con Backblaze sia che (l’ultima volta che l’ho testato) dovevi usare una chiave globale (quindi non potevo usarla per clienti che potevano vedere la chiave). Credo che qualcuno abbia recentemente pubblicato una soluzione per questo (qualcosa del tipo “legacy” da qualche parte). Per un progetto personale, è quello che proverei dopo, credo. (E se sei su Digital Ocean, Spaces va bene, credo.)

[tenzan (Askar)]

Io uso DO, ma in termini di costi Blackblaze/Wasabi è più economico.
Cosa hai usato per i caricamenti?

[tenzan (Askar)]

Scusa, non riesco a capire.
Perché dobbiamo specificare le impostazioni in app.yml, dato che possiamo inserire queste informazioni direttamente da Discourse > Impostazioni?

[pfaffman (Jay Pfaffman)]

A causa di come gestisce la creazione degli asset quando il contenitore viene costruito, credo. È piuttosto confuso che il comportamento sia diverso quando le impostazioni sono nelle variabili d’ambiente rispetto al database, ma è così che funziona. È anche un modo migliore per gestirle, poiché significa che puoi creare e ripristinare un nuovo sito dalla riga di comando.

[Zup]

@Falco

È necessario un parametro di configurazione aggiuntivo, HTTP_CONTINUE_TIMEOUT, per Vultr.

Dove devo impostarlo? Non riesco a trovarlo nelle impostazioni di amministrazione di Discourse?