Migrazione a un nuovo server con un nuovo DB e nuovi bucket S3 per backup e caricamenti

Ciao,

Attualmente sto migrando il nostro server da una distribuzione esistente basata su Bitnami (una versione piuttosto vecchia) all’installazione ufficialmente supportata su AWS utilizzando l’ultima versione di Discourse. Questa nuova installazione ha istanze Elasticache e RDS esterne e utilizzerà anche S3 per backup e caricamenti.

Ho 2 domande:

  1. Il vecchio server Discourse è su una versione piuttosto obsoleta: eseguendo il backup/ripristino sul nuovo server Discourse verranno eseguiti automaticamente tutti i comandi di aggiornamento pertinenti?
  2. Se copio il file di backup nel nuovo container Docker di Discourse sul nuovo server e avvio il ripristino dalla riga di comando, i nuovi valori del bucket che ho impostato nella mia configurazione verranno sovrascritti durante il ripristino o verranno utilizzati i miei nuovi valori? Presumo che il mio nuovo DB venga popolato dal backup e poi, quando esco dal container ed eseguo ./launcher rebuild app, verranno utilizzati i miei nuovi valori S3.

Se le mie supposizioni sono corrette, allora prima di eseguire il ripristino presumo che dovrei copiare il contenuto dei vecchi bucket S3 in quelli nuovi?

Ci sono altre insidie per questo tipo di migrazione con un backup?

Grazie in anticipo.

Forse mi sfugge qualcosa, ma perché state creando nuovi bucket? Un nuovo bucket di backup con regole di ciclo di vita appropriate sembra accettabile, ma se la vostra istanza Discourse esistente sta utilizzando il bucket di caricamento S3 avrete qualche problema.

1 Mi Piace

2 motivi per cui abbiamo bisogno di nuovi bucket:

  1. Non sono sicuro al 100% che la migrazione da Bitnami funzionerà senza problemi, quindi non vogliamo influenzare alcun dato esistente nel caso in cui sia necessario interrompere la migrazione.
  2. Abbiamo cambiato la denominazione dei nostri bucket, quindi pensavamo fosse più facile avere 2 bucket nuovi di zecca per questo.

Il punto 1 è quello che mi preoccupa, quindi sono solo extra cauto.

Quali problemi prevedi con il nuovo bucket di caricamento? Il vecchio server Discourse verrà impostato in modalità di sola lettura. Il piano è che una volta che il nuovo server sarà attivo e convalidato, spegneremo il vecchio server, cambieremo il DNS sul nuovo server e poi svuoteremo la cache nel CDN (Cloudfront) e poi lo apriremo al pubblico.

Non avevo notato che avresti copiato i dati dai vecchi bucket. Ho dato un’occhiata ad AWS, sembra semplice. Se fossi io, non mi complicherei a cambiare i bucket prima di passare ad AWS o a un nuovo server altrove.

[quote=“stevejr, post:1, topic:395948”]all’installazione ufficialmente supportata in AWS utilizzando l’ultima versione di Discourse.
[/quote]
Ufficialmente supportata?? Non ne sono così sicuro.

Suggerisco vivamente di aggiornare Discourse prima di passare a un nuovo server.
Sulla vecchia istanza, suggerisco di spostare la configurazione S3 in app.yml se non è già lì prima di spostarla.

Questa è una cosa che puoi facilmente testare senza influenzare la produzione.

Personalmente, farei tutto il possibile per evitare di fare queste due cose contemporaneamente.

  1. vedere se è possibile evitare del tutto di spostare i bucket
  2. se non è possibile, fallo dopo la migrazione da Bitnami
1 Mi Piace

Sono molto curioso di sapere come eseguire questo tipo di installazione rappresenti una proposta di valore aggiunto.
Dalle numerose discussioni sulle installazioni non supportate, sembra che crei più problemi che benefici, a meno che le persone non le facciano per imparare/sperimentare.

Una tale configurazione potrebbe essere un’installazione non supportata dal punto di vista di Discourse, ma dal punto di vista di un’organizzazione IT aziendale, RDS e Elasticache potrebbero essere standard e l’installazione standard di Discourse sarebbe quella fuori standard.