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:
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?
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?
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.
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.
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.
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.
Come menzionato da @RGJ, la nostra infrastruttura aziendale utilizza servizi esterni per cose come cache, database, ecc., da qui Elasticache e RDS. Ciò significa che possiamo avere backup completi e ridondanza per questi servizi e anche aiutare con i controlli di sicurezza. Questa è un’installazione ufficiale/supportata dal punto di vista di Discourse: utilizza semplicemente un insieme diverso di modelli (forse usare la parola standard è stato un po’ fuorviante, scusate).
Quindi, sembra che dovremmo prima aggiornare i nomi dei nostri bucket per l’installazione esistente ed eseguire quindi la migrazione al nuovo server. Aggiornare l’installazione esistente all’ultima versione è fuori discussione: abbiamo riscontrato problemi con l’aggiornamento di Bitnami in precedenza, da qui il passaggio al metodo di installazione ufficiale.
Posso chiedere, però, quali problemi potrebbero verificarsi se eseguiamo il ripristino con i bucket esistenti e poi aggiorniamo app.yml per fare riferimento ai nuovi bucket? Tutte le variabili d’ambiente DISCOURSE_ non hanno la precedenza su qualsiasi configurazione nel database (se applicabile)? O c’è qualcos’altro che potrebbe causare un problema?
Poiché se lo fai prima della migrazione e le cose vanno male, avrai il problema sull’istanza Bitnami più vecchia invece che sulla tua istanza standard appena installata. E, oltre alla vecchia versione, anche la menzione della parola Bitnami ti farà ottenere molto, molto meno supporto qui su meta.
Un’altra domanda, se posso: quando eseguo il ripristino dalla riga di comando all’interno del container di Discourse, utilizza la configurazione esistente /var/www/discourse/config/discourse.conf per i dettagli sulla connessione al database, la connessione a Redis, ecc., oppure sovrascrive tale configurazione con ciò che è presente nel file di backup?
discourse.conf è generato da app.yml, non è incluso nel file di backup.
In generale, ciò che è contenuto in discourse.conf sovrascrive le impostazioni del sito.
Quindi, se hai setting_foo nel tuo database, puoi sovrascriverlo definendo DISCOURSE_SETTING_FOO nel tuo app.yml, che genererà quindi setting_foo in discourse.conf.
Puntare un container Discourse a un server postgresql e redis esterno utilizzando la nostra immagine container con i nostri strumenti è un’installazione supportata.
RDS[1] è Postgresql, ed Elasticache è Redis, questo va bene.
Questo dovrebbe andare bene, lo facciamo per le persone che passano al nostro hosting.
La mia preferenza è mantenere il processo il più semplice possibile, quindi se riesci a eseguire un backup completo (inclusi i caricamenti) sul vecchio server e ripristinarlo su quello nuovo, questo ti permette di testare completamente la nuova configurazione senza alcun impatto su quella vecchia.
Eseguirò il backup/ripristino senza cambiare i nomi dei bucket come suggerito anche da @RGJ. Come ho detto, la mia preoccupazione era di non influenzare in alcun modo i dati esistenti sul server, ma se eseguo prima il backup dei bucket esistenti e mi assicuro che il server esistente sia in modalità di sola lettura durante la migrazione, penso che l’integrità dei dati caricati nei bucket sia piuttosto ben protetta.
