Come aggiorno Discourse in una configurazione a più container?

[alexk (Alex)]

Ciao! Ho appena avviato una nuova installazione di Discourse con più container e mi chiedo qual è il metodo di aggiornamento migliore.

La documentazione afferma:

Ridurre al minimo i tempi di inattività durante l’aggiornamento alle nuove versioni di Discourse. Puoi avviare i nuovi processi web mentre il sito è in esecuzione e, solo dopo averli costruiti, sostituire l’immagine con quella nuova.

Leggendo questo, mi chiedo se significhi che sia sicuro far funzionare una versione precedente di Discourse in produzione mentre un altro container viene aggiornato.

Ad esempio:

Immaginiamo di avere due container dedicati solo al web in esecuzione su macchine virtuali separate dietro un bilanciatore di carico. Tolgo una delle istanze del container dal bilanciatore di carico ed eseguo il bootstrap con l’ultima versione. La versione vecchia rimane in servizio per garantire zero tempi di inattività (va bene così?). Successivamente, ripristino il container aggiornato nel bilanciatore di carico e ripeto il processo sull’altro container.

Sembra corretto, vero?

[pfaffman (Jay Pfaffman)]

È corretto. Per aggiornamenti con zero tempi di inattività, è necessario avviare il nuovo container impostando SKIP_POST_DEPLOYMENT_MIGRATIONS: 1, quindi avvialo. Successivamente, quando i vecchi container non sono più in esecuzione, esegui SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate. In caso contrario, l’avvio iniziale può (anche se non per ogni aggiornamento) portare il database in uno stato non più utilizzabile dai vecchi container.

[alexk (Alex)]

Oh, che fantastico! Le migrazioni del database erano proprio la mia preoccupazione, quindi è utile sapere come controllarle!