Configura un fornitore di storage di oggetti compatibile con S3 per gli upload

[Discourse]

Questo argomento tratta la configurazione di alcuni provider comuni 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 è ufficialmente supportata e utilizzata internamente da Discourse per i nostri servizi di hosting.

Provider	Nome del 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	No
Contabo	Object Storage	No

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

Configurazione

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

Quando si utilizza l’object storage, è necessario anche un CDN per servire ciò che viene archiviato nel bucket. Ho utilizzato 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 tuo hostname Discourse e memorizza nella cache le richieste. Sarà utilizzato principalmente per le risorse recuperabili: 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.

Raccomandiamo che siano diversi e che gli amministratori impostino entrambi.

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

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

Si consiglia di configurare queste impostazioni nelle variabili d’ambiente nel file app.yml, poiché è così che CDCK le gestisce nella propria infrastruttura, quindi sono ben testate. Inoltre, l’attività di caricamento delle risorse avviene dopo la compilazione delle risorse, che avviene durante un 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 dell’avvio del sito.

Scegli il tuo provider dall’elenco sottostante e aggiungi queste impostazioni alla sezione env del 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 mettere in primo piano 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. È corretto abilitare la restrizione dell’elenco dei file. L’unico problema è che la loro offerta CDN è terribilmente difettosa, 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 non funziona, quindi hai bisogno di un ENV aggiuntivo per saltarlo in modo che le risorse possano funzionare. Salta anche CORS e configuralo manualmente.

Poiché non puoi elencare i file, non potrai 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 di Scaleway è anche molto buona e per la maggior parte tutto funziona bene.

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, ciò causerà il fallimento dei backup di Discourse e il caricamento incompleto potrebbe dover essere eliminato manualmente prima di ulteriori tentativi. Per le istanze piccole questo non è un problema. Scaleway sembra abbastanza aperta al feedback, quindi se desideri 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 ha il formato 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 configurarlo manualmente.

Ci sono segnalazioni che indicano che la pulizia dei caricamenti orfani non funziona correttamente con BackBlaze. Devi modificare le regole di ciclo di vita per il tuo bucket affinché la pulizia dei caricamenti 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 verso 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 dei bucket basati sul 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 dei 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 “public” 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 possono causare problemi CORB.

Assumendo che le avvertenze e i prerequisiti sopra menzionati 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 è difettoso.

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, il servizio è gratuito su Azure e hai solo bisogno di un livello VM molto basilare (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 uso leggero, la configurazione VM minima sembra funzionare perfettamente. Puoi accettare la maggior parte della configurazione predefinita. Ricorda 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 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ò essere un nome diverso. Collega uno o più contenitori per unirli in 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. Accedi alla VM tramite SSH 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, 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 di quelli originali, ovvero root:root e permessi 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 (ad esempio 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’indirizzo IP della VM Flexify.IO.
10. In Discourse, imposta quanto segue nella pagina di amministrazione (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 l'accesso pubblico in lettura 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 in modo intermittente e silenzioso, lasciando i backup sul disco rigido e alla fine riempiendo il disco. Né Wasabi né meta avevano indizi, quindi non lo consiglio, anche se i 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 allo stesso momento; era utilizzato 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 alle bucket in stile virtual-host e non funzionerà

Cloudflare

L’offerta di Cloudflare è incompatibile. Nei test, @fearlessfrog ha aperto un ticket con Cloudflare e nel dicembre 2022 hanno dichiarato:

I file che compressi con gzip non sono attualmente gestiti correttamente da R2. Devi caricare file non compressi. Cloudflare ha una compressione trasparente: sceglie identity, gzip o Brotli in base a ciò che il client può gestire. Questa è una differenza rispetto a S3.

Contabo

@tuxed ha provato a far funzionare Contabo Object Storage per i caricamenti compatibili con S3. Sembra che durante il caricamento venga aggiunto un prefisso al nome del repository nell’URL e non è stato in grado di 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 i 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 alle bucket in stile virtual-host e non funzionerà ↩︎