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

[Discourse]

Questo argomento spiega come configurare alcuni fornitori di Object Storage compatibili con S3 (cloni S3). Consulta Set up file and image uploads to S3 per maggiori dettagli sulla configurazione di Amazon AWS S3, che è supportata ufficialmente 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, aggiungi questa wiki.

Configurazione

Per memorizzare le risorse statiche di Discourse nel tuo Object Storage, aggiungi questa configurazione nel tuo file 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, è necessario anche un CDN per servire ciò che viene memorizzato nel bucket. Ho usato StackPath CDN nei miei test e, oltre alla necessità di impostare Dynamic Caching By Header: Accept-Encoding nella loro configurazione, funziona bene.

DISCOURSE_CDN_URL è un CDN che punta al nome host di Discourse e memorizza nella cache le richieste. Verrà utilizzato principalmente per le risorse recuperabili (pullable): 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. Verrà utilizzato principalmente per le risorse spingibili (pushable): JS, immagini e caricamenti degli utenti.

Consigliamo che siano diversi e che gli amministratori impostino entrambi.

Non utilizzare un CDN (o inserire l’URL del bucket come URL del CDN) probabilmente causerà problemi e non è supportato.

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

La configurazione di queste impostazioni nelle variabili d’ambiente nel tuo app.yml è consigliata perché è il modo in cui CDCK lo fa nella loro infrastruttura, quindi è ben testato. Inoltre, il compito di caricare le risorse avviene dopo che le risorse sono state compilate, il che avviene durante una ricostruzione (rebuild). Se vuoi 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 inizi.

Scegli il tuo provider dalla lista sottostante e aggiungi queste impostazioni alla sezione env del tuo file app.yml, adattando i valori di conseguenza:

AWS S3

Ciò che supportiamo ufficialmente e utilizziamo internamente. La loro offerta CDN Cloudfront funziona anche per servire 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 di DO è buona e funziona subito. È possibile abilitare Restrict File Listing. L’unico problema è che la loro offerta CDN è pessima, quindi devi usare un CDN diverso per i file. Inoltre, non devi installare la regola CORS, poiché la reinstalla ad ogni rebuild.

Esempio di configurazione:

  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

Per Linode è richiesto un parametro di configurazione aggiuntivo, HTTP_CONTINUE_TIMEOUT.

Esempio di configurazione:

  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 non funziona, quindi è necessaria una variabile d’ambiente extra 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, quindi non consigliamo di usarlo 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. Vedi questo argomento per la discussione specifica su Google Cloud.

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

Esempio di configurazione:

  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 di Scaleway è anche molto buona e, per la maggior parte, tutto funziona bene.

Gli upload 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 farà sì che i backup di Discourse falliscano e l’upload incompleto potrebbe dover essere cancellato manualmente prima di nuovi tentativi. Per le istanze piccole questo non è un problema. Scaleway sembra abbastanza aperto al feedback, quindi se vuoi che questo limite venga modificato dovresti contattarli.

Nota che per il parametro DISCOURSE_S3_ENDPOINT, Discourse usa l’endpoint dell’intera regione: https://s3.{region}.scw.cloud. L’“Bucket endpoint” trovato nel tuo dashboard di Scaleway ha la forma https://{bucketName}.s3.{region}.scw.cloud. Ometti il sottodominio del nome del bucket per evitare errori di connessione.

Esempio di configurazione:

  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

Per Vultr è richiesto un parametro di configurazione aggiuntivo, HTTP_CONTINUE_TIMEOUT.

Esempio di configurazione:

  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 configurarlo manualmente.

Ci sono report di clean up orphan uploads che non funzionano correttamente con BackBlaze. Devi cambiare le regole del ciclo di vita del tuo bucket affinché la pulizia degli upload orfani funzioni.

Esempio di configurazione:

  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 di 2500 transazioni gratuite giornaliere 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 siano soddisfatti prima di poter usare il server di storage MinIO come alternativa a S3:

1. Hai un’istanza server MinIO completamente configurata
2. Hai abilitato il supporto del dominio nella configurazione di MinIO, per URL dei bucket basati su dominio. Questo è un requisito di configurazione obbligatorio per MinIO e Discourse, poiché MinIO supporta ancora gli stili “path” legacy di S3 che non sono più supportati in Discourse.
3. Hai configurato correttamente il DNS per MinIO in modo che i sottodomini del bucket si risolvano correttamente al server MinIO e il server MinIO sia configurato con un dominio base (in questo caso, minio.example.com)
4. Il bucket discourse-data esiste sul server MinIO e ha una politica “public” impostata
5. Il tuo URL S3 CDN punta a un CDN configurato correttamente che punta al bucket e memorizza nella cache le richieste, come affermato precedentemente in questo documento.
6. I tuoi CDN sono configurati per usare effettivamente un’intestazione “Host” dell’URL S3 principale - per 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, un esempio di configurazione 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 è installata dal rebuild dell’app - per default, sembra che CORS sia 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 usato con Discourse. C’è 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 storage Azure in S3.

Al momento della scrittura, il servizio è gratuito su Azure e ti serve solo un livello VM di base (economico) per iniziare a eseguirlo. Richiede, tuttavia, un po’ di configurazione.

1. Nel portale Azure, crea una nuova risorsa di tipo Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. Per un uso leggero, la configurazione VM minima sembra funzionare perfettamente. Puoi accettare la maggior parte della configurazione predefinita. Ricorda di salvare il file chiave PEM quando crei la VM.
3. Vai al link della VM Flexify.IO e entra nel sistema. Segui le istruzioni configurando il provider di dati Azure Blob Storage e l’endpoint S3 generato. Assicurati che l’impostazione di configurazione dell’endpoint Public read access to all objects in virtual buckets sia true. Copia l’URL dell’endpoint S3 e le chiavi.
4. Premi New Virtual Bucket e crea un bucket virtuale. Può avere lo stesso nome del tuo contenitore Azure Blob Storage, o può avere un nome diverso. Collega qualsiasi contenitore(i) da unire in questo bucket virtuale. Questo bucket virtuale è usato per esporre un bucket leggibile pubblicamente tramite S3.
5. Per default, Flexify.IO installa un certificato SSL autofirmato, mentre un endpoint S3 richiede HTTPS. Effettua SSH nella VM usando il file chiave (il nome utente è per default azureuser) e sostituisci i seguenti file con i file 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, quello che inizia con BEGIN PRIVATE KEY e non BEGIN RSA PRIVATE KEY che è PKCS#1)

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

6. Per default, Flexify.IO crea un servizio S3 di livello root con più bucket. Discourse richiede il supporto sub-domain per i bucket. Vai a: <IP della tua VM Flexify.IO>/flexify-io/manage/admin/engines/configs/1 che aprirà una pagina di configurazione nascosta!
7. Specifica il dominio base S3 (diciamo che è s3.mydomain.com) nel campo Endpoint hostname, che dovrebbe essere vuoto per default. Premi Save per salvare l’impostazione.
8. Riavvia la VM Flexify.IO nel portale 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 admin (sì, non c’è bisogno 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

L’uso dello stesso bucket per produzione e staging non è consigliato. Se lo fai comunque, prendi provvedimenti per assicurarti che il tuo sito di staging non cancelli le tue risorse di produzione (imposta s3 disable cleanup come minimo, e fai attenzione che non cancelli i backup della produzione).

Wasabi

@pfaffman ha provato wasabi per i backup, ma sembrava fallire intermittente e silenziosamente, lasciando i backup sull’hard drive e alla fine riempiendo il disco. Né wasabi né meta avevano indizi, quindi non lo consiglio, anche se le tue esperienze potrebbero variare. @pfaffman è ora abbastanza certo che questo problema fosse dovuto a backup e riavvii automatici programmati in qualche modo allo stesso tempo; era usato solo per i backup, ma sembrava funzionare bene. Se qualcuno vuole provarlo e riportare qui, dovrebbe funzionare, almeno per i backup.

Oracle Cloud

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

Cloudflare R2

Cloudflare R2 è compatibile con l’object storage S3 quando si usa Cloudflare CDN. Il piano gratuito di Cloudflare offre 10GB di storage che dovrebbe essere più che sufficiente per le esigenze della maggior parte dei forum.

Per configurare Cloudflare R2, dovrai configurare le impostazioni rilevanti nel dashboard di Cloudflare sotto R2 Object Storage.

A seconda delle tue esigenze (caricamenti o backup o entrambi), queste sono le impostazioni rilevanti da inserire nel tuo file app.yml o nella 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 admin:

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

• Enable S3 uploads = true
• Enable direct S3 uploads = true
• S3 access key ID = "xxx"
• S3 secret access key = "xxx"
• S3 region = any
• S3 upload bucket = your upload bucket name
• S3 endpoint = https://<your-account-id>.r2.cloudflarestorage.com
• S3 CDN URL = https://uploads.yourdomain.com
• S3 use ACLs = false (disabilita questo!)
• S3 backup bucket = your backup bucket name
• Backup location = S3

Note Importanti sulla Configurazione di Cloudflare R2:

1. Quando configuri il tuo app.yml o web_only.yml per Cloudflare R2, imposta solo DISCOURSE_S3_CDN_URL. NON impostare DISCOURSE_CDN_URL. Se stai proxying il tuo dominio principale attraverso Cloudflare, questo sta già memorizzando nella cache e servendo le tue risorse dell’app automaticamente. Se tenti di configurare un DISCOURSE_CDN_URL separato usando Cloudflare DNS, il routing host rigoroso di NGINX di Discourse rifiuterà le richieste, risultando in loop infiniti di redirect 301, blocchi della politica CORS e un sito rotto.

• Lascia DISCOURSE_CDN_URL commentato.
• Imposta DISCOURSE_S3_CDN_URL: https://your-r2-custom-domain.com

2. Permessi del Token API: Poiché Discourse ha solo un set di campi delle 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 token, seleziona “Apply to all buckets” oppure usa “Apply to specific buckets” e assicurati che entrambi siano selezionati. Inoltre, assicurati di selezionare Object Read & Write quando crei la chiave API (il default è solo Object Read only).

3. Quando copi l’URL dell’endpoint da Cloudflare, potrebbe aggiungere il nome del bucket all’URL - dovresti cancellare il nome del bucket dalla fine della stringa nel tuo file .yml (o nelle impostazioni admin) se viene incollato.

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

5. Se abiliti DISCOURSE_ENABLE_DIRECT_S3_UPLOADS (true) dovresti disabilitare DISCOURSE_S3_USE_ACLS (false). Questo perché Cloudflare R2 usa i 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 i task rake delle regole CORS o scrivere json IAM, poiché lo configurerai nel dashboard di Cloudflare quando imposti i permessi del tuo bucket. Il token “Object Read & Write” di Cloudflare concede automaticamente i permessi di upload multipart, e incollare la seguente regola CORS direttamente nelle impostazioni del bucket di caricamento R2 di Cloudflare Dashboard sotto CORS Policy sostituisce la necessità del task rake.

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

Vedi anche questo argomento per più informazioni sulla configurazione di Cloudflare: Using Discourse with Cloudflare: Best Practices

Contabo

@tuxed ha provato a far funzionare Contabo Object Storage per i caricamenti compatibili con S3. Sembra che durante il caricamento anteponga il nome del repository nell’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 contare e poi contrassegnare come non sicuri quei caricamenti, dato che sai che non devono essere sicuri, nel qual caso dovrai usare 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 ai bucket in stile virtual-host e non funzionerà ↩︎