Sto cercando di migrare Discourse da un hosting personale a un server Amazon LightSail. Ho cercato nel forum e letto tutti i post relativi alla migrazione dei server e alla configurazione di Discourse:
Esportare un backup dal server Discourse esistente (attualmente il backup è configurato per essere salvato su S3, ma capisco che in questo caso sarà necessario un backup manuale dei file)
Importare il backup nel nuovo server Discourse (manualmente, poiché non può recuperarlo da S3, a quanto ho capito)
Sono un po’ bloccato su come eseguire il passaggio 1, dato che ho alcune limitazioni: possiedo un solo nome di dominio e voglio mantenerlo per il nuovo server, senza alcun tempo di inattività (il mio obiettivo è completare la configurazione del nuovo server, ripristinare il backup e infine modificare la voce DNS per puntare al nuovo server, evitando così interruzioni, dato che entrambi i server saranno attivi contemporaneamente).
Come ho capito, quando configuro il nuovo server Discourse, posso copiare il file app.yml dal server esistente al nuovo server e poi eseguire discourse-setup. Il problema che vedo qui è che, facendo così, verrà utilizzato lo stesso nome DNS del server esistente (che è proprio ciò che voglio), ma prevedo due problemi che sto cercando di risolvere:
Let’s Encrypt non genererà un certificato SSL per il nuovo server, poiché il nome di dominio punta ancora al vecchio server.
Senza il certificato SSL (la configurazione del vecchio server è impostata per utilizzare solo SSL, il che verrà ereditato in app.yml), il server non si avvierà.
Ho provato a connettermi al server Discourse utilizzando una reindirizzamento DNS, ma se l’URL inserito non corrisponde alla configurazione di app.yml, né NGINX né Discourse funzioneranno: riceverai un errore nel browser durante il tentativo di connessione. Quindi, senza un’interfaccia web, non posso avviare il processo di ripristino.
Come posso quindi completare la configurazione del nuovo server Discourse utilizzando il file app.yml del server esistente, ripristinare il backup e poi effettuare il passaggio del DNS? Oppure esiste un modo più semplice per farlo?
Se non intendi utilizzare lo stesso bucket S3, esiste un’impostazione nascosta che forza il download dei file S3 durante il backup. Puoi cercare il nome nel file delle impostazioni e impostarlo dalla console di Rails. Esiste un argomento che ne discute, ma potrebbe essere più semplice consultare direttamente il file settings.yml.
Non è necessario eseguire discourse-setup; basta copiare il file app.yml e ricostruire l’immagine.
Puoi sincronizzare i certificati Let’s Encrypt tramite rsync. Anzi, puoi copiare l’intera directory /var/discourse (escludendo eventualmente alcuni log e simili).
L’obiettivo ideale sarebbe fare un ‘lift and shift’, ma con Amazon Lightsail non è possibile, dato che non si può importare un’immagine esistente. Quindi sì, si utilizzerebbe esattamente lo stesso bucket S3.
Sembra che il tuo approccio sia il più vicino al ‘lift and shift’. Se ho capito bene, posso semplicemente tar/gz l’intera cartella /var/discourse dal server originale e decomprimerla sul nuovo server, seguito da un discourse start, e poi semplicemente reindirizzare il DNS verso il server bee. È tutto? Devo ricompilare Discourse sul nuovo server? E per quanto riguarda Nginx, Docker e altre dipendenze esterne alla cartella?
Grazie. A quanto pare, la procedura “lift n shift” non è stata così pulita come pensavo; ci sono alcune verifiche da effettuare prima e dopo per garantire un’operazione di “lift n shift” fluida (Postgres è stato aggiornato dalla versione 12.0 alla 13.0, il che mi ha insegnato alcune lezioni sul processo di “lift n shift”). Ecco una guida passo dopo passo per riferimento futuro per chi cerca di spostarsi su un server Amazon LightSail (1 GB di RAM):
Server Originale
Crea un backup su S3
cd /var/discourse
./launcher rebuild # ottieni l’ultima build per una transizione semplice
./launcher cleanup # pulisci per rimuovere i dati vecchi e ridurre le dimensioni del pacchetto
./launcher stop app # non farlo causa un errore durante il tentativo di ricostruire l’app successivamente con Postgres
tar -zcvf /var/discourse discourse.tar.gz
Nuovo Server Amazon LightSail
Installa l’immagine Ubuntu 20.20 da Amazon (1 GB di RAM)
Crea 2 GB di swap # non farlo potrebbe causare il fallimento della ricostruzione
Configura vm.overcommit_memory=1 # non farlo potrebbe causare un errore con Postgres durante la ricostruzione
Trasferisci via FTPS discourse.tar.gz dal server originale
tar -zxvf discourse.tar.gz -C /
cd /var/discourse
Imposta UNICORN_WORKERS in app.yml a 2 # aumentarlo oltre 2 con 1 GB di RAM rischia di causare swapping e throttling a causa di un’eccessiva attività del disco
./launcher rebuild
Modifica il DNS per puntare al nuovo server Amazon
Esiste un modo più semplice per migrare i server (lift n shift) senza dover seguire l’intero processo di configurazione di Discourse?
Intendi senza eseguire discourse-setup o senza costruire il contenitore necessario per far funzionare Discourse? Se ti riferisci a quest’ultimo, è possibile spingendo la vecchia immagine su un repository utilizzabile dal nuovo server, ma non è qualcosa che un principiante possa gestire facilmente.
Il tuo processo è stato complicato dall’aggiornamento a PG13. Potrebbe essere stato leggermente più semplice costruire una nuova immagine da zero sul nuovo server e ripristinare il backup da quello vecchio, ma avresti comunque dovuto affrontare alcune piccole complicazioni per ottenere i certificati Let’s Encrypt sul nuovo server.
Esatto, è l’unica cosa che mi ha impedito di eseguire ./discourse-setup sul nuovo server e poi ripristinare dall’immagine S3 (e come farlo senza accesso alla console di amministrazione web, dato che il DNS puntava ancora al vecchio server e, per quanto ne so, Discourse non risponde a un indirizzo IP nel browser). Dato che avevo un sistema attivo e dovevo cambiare il DNS in tempo reale dal vecchio al nuovo sistema, la mancanza dei certificati Let’s Encrypt era l’unico ostacolo per me.
Se esiste un modo per trasferire i certificati dal vecchio al nuovo sistema, completare ./discourse-setup senza errori relativi a Let’s Encrypt e ripristinare dal backup S3 senza passare per la console web, allora sarebbe un metodo più semplice da seguire.
Se copi i file yml all’interno di containers, non hai bisogno di discourse-setup (può regolare i parametri di memoria se sono diversi sul nuovo server, ma puoi farlo anche in seguito). Dovrai semplicemente eseguire ./launcher rebuild app.
Ok, penso di aver capito cosa intendi, ma per sicurezza lasciami riassumere la mia comprensione.
Nel server originale, era configurato il backup di Discourse su S3 (che include le impostazioni e i contenuti del sito).
Copiando i file yml dalla directory containers, verrà trasferita l’intera configurazione del server originale al nuovo server. Di conseguenza, sul nuovo server non sarà più necessario eseguire discourse-setup; invece, eseguendo ./launcher rebuild app si utilizzerà la configurazione originale per scaricare l’immagine più recente e configurare Discourse.
Ora ci sono due punti ancora da chiarire:
Come si trasferiscono i certificati Let’s Encrypt (visto che il DNS punta ancora al server originale, non è possibile ricrearli, e immagino che questo debba essere fatto prima di eseguire ./launcher rebuild app)?
Come si ripristina Discourse (impostazioni + contenuti) dal backup S3 dopo il rebuild? Poiché il DNS punta ancora al server originale, esiste un modo per accedere all’interfaccia web di amministrazione di Discourse tramite indirizzo IP o localhost, oppure è possibile ripristinare il backup S3 direttamente dalla console?
Grazie per i passaggi dettagliati, ho dovuto fare qualcosa di simile, spostandomi su un nuovo host.
Dato che il sito funzionava, non mi è piaciuto dover passare attraverso i backup, quindi ho seguito i passaggi qui.
Ha quasi funzionato ma la ricostruzione sul nuovo host è fallita.
Si è scoperto che la mappatura UID/GID non era del tutto la stessa sui due host, quindi all’avvio di Postgres si sarebbe verificato un errore a causa della proprietà errata della cartella dei dati.
C’è un dettaglio in più per lo scenario in questo post, ovvero che il container non viene creato, quindi ./launcher enter app non funziona in questa fase. Poiché la ricostruzione sarebbe durata parecchio tempo, sono stato in grado di utilizzare docker ps per ottenere il nome del container che stava eseguendo la ricostruzione, e quindi entrare nel container:
La ricostruzione fallisce quindi (o non è possibile interromperla con CTRL+C). Dopo che si è fermata, eseguila semplicemente di nuovo e i permessi saranno corretti:
.