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

[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?