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à ↩︎