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

Quindi ora funziona?

1 Mi Piace

Perfetto. Mi ci è voluto tanto tempo, ma oltre al fatto che funziona, ho anche imparato moltissimo sulla configurazione di Discourse!

Grazie!

2 Mi Piace

OK. Ho deciso di pubblicare la guida passo passo che ho creato quando stavo eseguendo questa configurazione.

Come configurare il backup S3 e la CDN S3 del forum Discourse (Itechguides.com)

I passaggi in questa guida sono per l’utilizzo di DigitalOcean Space e StackPack CDN.

3 Mi Piace

@pfaffman Mi stavo chiedendo se potessi aiutarmi con questo ulteriore problema di backup:

Dopo aver completato il backup S3 e la configurazione di clonazione, il mio backup automatico non viene eseguito. Lo screenshot qui sotto mostra la mia configurazione.

Posso eseguire i backup manualmente. Il problema sono i backup automatici pianificati: non vengono eseguiti.

1 Mi Piace

Non lo so. Puoi controllare i processi di Sidekiq e assicurarti che siano in esecuzione. Dovrebbe funzionare.

1 Mi Piace

4 messaggi sono stati divisi in un nuovo argomento: Suggerimenti su Google Cloud S3

Ciao,

Grazie per aver corretto il mio post. Ma non posso modificare il mio post per evitare informazioni fuorvianti.

Ciao,

Sono un po’ bloccato e confuso e spero che qualcuno possa aiutarmi.
Avevo prima un’installazione di Bitnami e mi sono reso conto di quanti problemi mi avrebbe causato lungo il percorso, ho reinstallato utilizzando l’installazione standard.
Sono stato in grado di ripristinare il mio backup e tutto è andato bene, anche se sono passato dalla versione beta 2.8 alla 2.9.

Ho testato di nuovo il mio backup sul mio bucket di Google e ha ancora funzionato alla grande.
Nota che tutta la configurazione S3 è stata fatta tramite l’interfaccia web e non tramite variabili d’ambiente.

Per motivi di GDPR, ho creato un nuovo bucket di backup in Europa (chiamiamolo discourse-backup-eu) e ora che sono stato in grado di modificare la variabile d’ambiente, ho impostato DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com, ricostruito l’app, cambiato il nome del bucket di backup nell’interfaccia web, rieseguito il backup e sono stato molto contento di vedere i file di backup apparire nel mio nuovo bucket di backup in Europa.

Ora volevo che gli upload andassero in un altro bucket ed evitassi di riempire lo spazio su disco della mia VM.

Quindi ho configurato un nuovo bucket (chiamiamolo discourse-uploads), l’ho reso pubblico, ho aggiunto il ruolo Storage Legacy Bucket Owner al mio account di servizio su quel nuovo bucket.
Poi ho aggiunto una regola al mio load balancer esistente (chiamiamolo https://www.example.com) per utilizzare un bucket backend con Cloud CDN abilitato come indicato qui. La regola /discourse-uploads/* punta al bucket discourse-uploads.

Ho testato la mia CDN con un test.jpg nella root del bucket ma non sono riuscito a raggiungerlo tramite https://www.example.com/discourse-uploads/test.jpg e ho dovuto creare una sottocartella chiamata discourse-uploads all’interno del bucket, ho spostato il test.jpg all’interno e ora posso vedere la mia immagine di test tramite https://www.example.com/discourse-uploads/test.jpg.

Nell’interfaccia utente web, ho cambiato il nome del bucket fittizio sotto “s3 upload bucket” (che ero stato costretto a impostare in precedenza durante la configurazione del backup) in discourse-uploads, ho riempito l’URL della CDN con https://www.example.com/discourse-uploads e ho spuntato “enable s3 uploads”.

Da quel momento in poi, se provassi a caricare un’immagine, otterrei un popup che dice “Invalid Argument” nella finestra del browser (proveniente da un errore 422 con un contenuto JSON che dice fondamentalmente lo stesso).

Ho provato a rebake tutti i post, ma senza alcun effetto, ho ancora l’errore.

Quindi ho pensato che avrei dovuto provare a usare le variabili d’ambiente invece dell’interfaccia web.

e usare la seguente configurazione:

DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: whatever
DISCOURSE_S3_INSTALL_CORS_RULE: false
FORCE_S3_UPLOADS: 1
DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
DISCOURSE_S3_ACCESS_KEY_ID: MY_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY: MY_ACCESS_KEY
DISCOURSE_S3_CDN_URL: https://www.example.com/discourse-uploads
DISCOURSE_S3_BUCKET: discourse-uploads/discourse-uploads
DISCOURSE_S3_BACKUP_BUCKET: discourse-backup-eu
DISCOURSE_BACKUP_LOCATION: s3

Ho ricostruito l’app.
Poi non riesco più ad aprire discourse perché nessuna delle risorse è stata caricata nel bucket e ottengo un 404
https://www.example.com/discourse-uploads/assets/admin-31467dc73634cbfb81799737c43df0e2939307d893ef32713f1d0770bcb3532c.br.js

Ho pensato che provare a caricare direttamente in una sottocartella del bucket fosse un po’ esagerato, anche se l’OP suggerisce che funzioni (almeno per il bucket di backup)

ho cambiato la variabile d’ambiente in
DISCOURSE_S3_BUCKET: discourse-uploads
(Pensando che più tardi potrei giocare con la regola host invece di dover caricare in una sottocartella)

e ho ricostruito per vedere se qualcosa veniva caricato, ma nulla viene caricato nel bucket e discourse continua a non aprirsi a causa di 404.

Quindi le mie domande sono:

  • L’interfaccia web e la variabile d’ambiente entrano in conflitto?
  • Quando le risorse dovrebbero essere caricate nel bucket?
  • Come posso eseguire il debug di questo? Non vedo errori nei log.
  • È possibile impostare una sottocartella di un bucket nella configurazione?
  • Una volta che questo funziona, le immagini precedentemente caricate vengono trasferite nel bucket? Se faccio il rebake, come saranno gli URL delle immagini precedentemente caricate?

Grazie!

1 Mi Piace

Hai incluso questo pezzo?

Ho inviato una PR con un template per farlo un po’ di tempo fa, ma non credo che abbia mai ricevuto attenzione.

Inoltre, cambiare i bucket è difficile. Devi non solo copiare tutte le risorse dal vecchio al nuovo, ma anche aggiornare il database per utilizzare il nuovo bucket. Credo ci sia un argomento a riguardo.

Se utilizzi le variabili d’ambiente (cosa che dovresti fare), tali impostazioni non sono più visibili nell’interfaccia web.

1 Mi Piace

Un post è stato unito a un argomento esistente: Suggerimenti su Google Cloud S3

Sì. Se non ricordo male, c’è una discussione sopra riguardo a Google che non permette qualcosa (accesso all’elenco, forse?), ma c’era una soluzione alternativa riguardo all’uso di una sorta di “legacy”. Questo è ciò che ricordo. Dovrai scorrere i 100 messaggi precedenti per trovarlo. Se funziona, sarebbe fantastico se potessi aggiornare l’OP per dire come hai fatto in modo che la prossima persona che ha bisogno di saperlo possa trovarlo più facilmente.

1 Mi Piace

Grazie ancora per la tua risposta!
L’avviso sul bucket di Google riguardava l’uso per i backup perché non era in grado di elencare i file.
Ho già pubblicato come risolvere questo problema

Stai suggerendo che aggiorni l’OP con quelle informazioni? Non credo di poterlo fare.

Ancora una volta, il backup funziona, ma l’upload degli asset no, secondo l’OP, questo avrebbe dovuto funzionare anche senza i diritti di Proprietario del bucket legacy di archiviazione.

Penso che ci possa essere una regressione qui, cosa ne pensi @Falco?

1 Mi Piace

Potrebbe esserci una regressione. Sei sicuro di aver aggiunto il comando personalizzato

di cui solo Google ha bisogno?

2 Mi Piace

Oh. Beh, pensavo che qualcuno l’avesse fatto. :person_shrugging:

Era quello che stavo suggerendo. È un wiki, quindi sono abbastanza sicuro che tu possa farlo, anche se non sono sicuro al 100% di quali livelli di fiducia siano coinvolti.

1 Mi Piace

Grazie per la tua risposta, sì, l’ho incluso:

Nota che ho provato con e senza la sottocartella
DISCOURSE_S3_BUCKET: discourse-uploads/discourse-uploads
e
DISCOURSE_S3_BUCKET: discourse-uploads

Grazie ancora

2 Mi Piace

@tuanpembual inizialmente lo ha fatto ma si è riferito a Storage Legacy Object Owner invece che a Storage Legacy Bucket Owner

Sono solo un “utente base”, questo deve essere il motivo per cui non posso modificarlo.

3 Mi Piace

Cercherò di riassumere le risposte alle mie domande:

  • L’interfaccia utente Web e la variabile ENV entrano in conflitto?

Se si utilizzano le variabili ENV (cosa che si dovrebbe fare), tali impostazioni non saranno più visibili nell’interfaccia utente Web.

  • Quando dovrebbero essere caricati gli asset nel bucket?
    Aggiungendo questo snippet ad app.yml nella sezione hook, verrà caricato dopo after_assets_precompile (durante la ricostruzione dell’app).
after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
  • Come posso eseguire il debug? Non vedo errori nei log.
    Eseguendo:
cd /var/discourse
sudo ./launcher enter app
sudo -E -u discourse bundle exec rake s3:upload_assets --trace
  • È possibile impostare una sottocartella di un bucket nella configurazione?

Devo davvero usare bucket separati per caricamenti e backup?

No, non è necessario, ma di solito è il modo più semplice per configurare. Essenzialmente è necessario utilizzare due bucket diversi o un prefisso per il bucket di backup. Ad esempio, le seguenti combinazioni funzioneranno:

  1. Bucket diversi
  • s3_upload_bucket: tuo-bucket-caricamenti
  • s3_backup_bucket: tuo-bucket-backup
  1. Prefissi diversi
  • s3_upload_bucket: tuo-bucket-caricamenti/caricamenti
  • s3_backup_bucket: tuo-bucket-caricamenti/backup

È possibile utilizzare prefissi per organizzare i dati archiviati nei bucket Amazon S3. Un prefisso è una sequenza di caratteri all’inizio del nome della chiave dell’oggetto. Un prefisso può avere qualsiasi lunghezza, soggetta alla lunghezza massima del nome della chiave dell’oggetto (1.024 byte). È possibile considerare i prefissi come un modo per organizzare i dati in modo simile alle directory. Tuttavia, i prefissi non sono directory. (Organizing objects using prefixes - Amazon Simple Storage Service)

  • Una volta che questo funziona, le immagini precedentemente caricate vengono trasferite nel bucket? Se faccio un rebake, che aspetto avranno gli URL delle immagini precedentemente caricate?

Ho abilitato i caricamenti S3 nella mia istanza Discourse (che è in funzione da un po’); cosa devo fare con i caricamenti locali esistenti?

Per migrare i caricamenti esistenti su S3, puoi eseguire un paio di rake tasks. Per farlo, è necessario avere accesso SSH, permessi di root ed essere entrati nell’app Discourse (come da Operazioni di massa amministrative). Ah, e devi impostare alcune variabili d’ambiente in app.yml. Non per i deboli di cuore.

Una volta fatto tutto ciò, sei pronto per le rake tasks:

rake uploads:migrate_to_s3
rake posts:rebake

Una volta completate queste operazioni (e i caricamenti funzionano bene), non sarà più necessario includere i caricamenti nei backup. E come bonus, sarai in grado di Ripristinare un backup dalla riga di comando in caso di catastrofe (basta conservare una copia di app.yml da qualche parte).

3 Mi Piace

Ciao, stavo cercando provider di object storage e ho visto sull’OP che per alcuni di essi, dovrai “saltare CORS e configurarlo manualmente”. Non ho familiarità con CORS né con la sua configurazione, quindi dovrei evitare quelli che richiedono questa impostazione o è semplice da configurare?

1 Mi Piace

Se dovessi chiedere (come farei io) allora ne sceglierei un altro.

1 Mi Piace

Conferma solo, una volta completati i passaggi

rake uploads:migrate_to_s3
rake posts:rebake

posso rimuovere completamente la cartella uploads locale, giusto?

1 Mi Piace