Hello there,
We are wondering if zero downtime upgrades are possible. We are using the discourse_docker installation using separate web and data containers, so the issue is more around the old application code (v2.1) running against a migrated v2.3.0 database schema. This happens between the time we bootstrap the image (which will run the migrations) and the moment the web servers get restarted (updated) to run the upgraded image. Are there any recommendation for this?
Abbiamo eseguito con successo l’aggiornamento un paio di mesi fa. Pubblico qui la nostra esperienza per chiunque possa avere la stessa domanda in futuro.
Discourse supporta in una certa misura gli aggiornamenti senza downtime utilizzando migrazioni post-deploy. Il processo complessivo, come lo abbiamo compreso, può essere suddiviso in 2 fasi.
FASE 1: Aggiorna alla nuova versione ed esegui migrazioni sicure:
version: <NUOVA_VERSIONE>SKIP_POST_DEPLOYMENT_MIGRATIONS=1./launcher bootstrap web_only)FASE 2: Esegui la migrazione post-deploy (migrazioni ad alto rischio come eliminazione di colonne e tabelle, ecc.). A questo punto questa fase dovrebbe essere sicura poiché tutti i tuoi server stanno eseguendo la nuova versione del codice e non dovrebbero dipendere dai dati eliminati:
version: <NUOVA_VERSIONE>SKIP_POST_DEPLOYMENT_MIGRATIONS=0./launcher bootstrap web_only)Complicazioni:
Abbiamo deciso di eseguire la FASE 1 e la FASE 2 in date diverse, il che ha causato alcuni problemi. C’è stato un grande refactoring sul modello dei sondaggi tra la versione 2.1 e la 2.3. Sembra che inizialmente la maggior parte dei dati dei sondaggi fosse memorizzata come oggetto JSON nella tabella post_custom_fields. Entro la versione 2.3 sono stati spostati nella loro tabella dedicata polls. Questo ha richiesto una migrazione dei dati che è stata eseguita come parte delle migrazioni post-deploy (FASE 2).
Il nostro problema specifico è stato che subito dopo l’aggiornamento alla versione 2.3, i sondaggi creati prima dell’aggiornamento si sono interrotti, probabilmente perché il codice che li rendeva assumeva il nuovo modello di dati. Alcuni utenti se ne sono accorti e hanno provato a aggiornare manualmente i sondaggi dall’interfaccia utente, finendo così per creare record nella nuova tabella polls. Tali record, come abbiamo scoperto con rammarico in seguito, avrebbero innescato un vincolo di unicità postgres durante il processo di bootstrap, bloccandolo di fatto.
Per aggirare il problema, abbiamo deciso di applicare una patch che saltava una specifica migrazione dei sondaggi se questa esisteva già nel database. Questa non era una soluzione perfetta, poiché si poteva perdere dati da post_custom_fields che non venivano mai migrati per questi post. Ma nel nostro caso questo era comunque un buon compromesso, dato che il numero di casi era molto basso nel nostro sistema (2 istanze che abbiamo potuto osservare) e ci ha permesso di eseguire il processo di bootstrap. Ora, testare e applicare la patch ha sollevato altre due domande:
Come testiamo la modifica prima di inviare la PR?
Volevamo testare il nostro codice nelle stesse condizioni in cui sarebbe stato eseguito nella realtà, il che significava testarlo contro il processo di bootstrap. Questo non è banale come testare le modifiche al codice in esecuzione, che puoi fare eseguendo l’applicazione Discourse standalone in locale.
Come incorporiamo le modifiche nel nostro sistema?
Non volevamo aspettare che la patch raggiungesse una versione ufficiale di Discourse, che può essere un processo lungo e ci avrebbe essenzialmente costretti a eseguire un altro aggiornamento. Avevamo già clienti che si lamentavano dei sondaggi esistenti e più aspettavamo, maggiori erano le probabilità che i clienti modificassero manualmente i sondaggi, aggravando i problemi di integrità dei dati.
Quindi abbiamo trovato un modo per testare le modifiche che stavamo introducendo cambiando l’origine del repository che lo script di bootstrap utilizza. Questo ha richiesto alcune prove ed errori poiché non siamo molto esperti di pups e di altri strumenti legati a questo processo. Alla fine, abbiamo fatto qualcosa di simile a questo.
Questo ci ha permesso di verificare che la nostra correzione funzionasse come previsto. Siamo anche riusciti ad avviare il bootstrap di una nuova immagine in produzione partendo dalla nostra versione modificata di Discourse contenente la patch, senza dover attendere una versione ufficiale di Discourse.