Sto cercando di capire la configurazione “zero downtime”. La mia configurazione attuale prevede alcune istanze di Discourse per diverse community. Entrambe hanno una configurazione di container data/web 2. A livello di host ho un Nginx che gestisce la terminazione SSL e utilizza una connessione a socket che viene passata al Nginx del container.
Ho trovato questi due argomenti di interesse:
Quindi sto cercando di comprendere questo processo. Sembra esserci un po’ di conoscenza presupposta per realizzare ciò. Qualsiasi aiuto qualcuno possa fornire qui sarebbe ottimo.
La prima cosa che vorrei capire è come sapere quando un container data deve essere aggiornato. Sembra che ci siano casi in cui non è possibile semplicemente ricostruire il container web. Come faccio a sapere con certezza quando questo è il caso? Si tratterebbe di tutti i casi in cui l’opzione di aggiornamento è disattivata nel pannello UI di amministrazione per gli aggiornamenti, insieme a potenziali lavori personalizzati su temi e plugin? Potrei sapere con certezza esaminando le migrazioni dello schema del database? Dovrei avere un ambiente di staging e tentare semplicemente di capire con certezza?
La prossima cosa che vorrei sapere è come eseguire un aggiornamento zero-downtime. Dai due link sembra che si debba comunque eseguire una ricostruzione del container data e del container web? Non riesco a decifrare questo. Avrei bisogno di container data/web separati per realizzare lo zero-downtime alla fine?
Qualsiasi guida sarebbe fantastica! Probabilmente potrei passare molte ore a scoprire qualcosa che sembrava funzionare, ma preferirei basarmi sulle spalle dei giganti e non dover scoprire i casi limite nel modo difficile (in produzione) se possibile.
Se avete bisogno di ulteriori informazioni sulla mia configurazione particolare, chiedete chiarimenti. Risponderò direttamente e aggiornerò questo post.
Non so molto sulla “migrazione post-distribuzione”, ma secondo quanto ricordo di aver letto (qui su meta), un modo per realizzarla è utilizzando 3 container: 1 per i dati e 2 per il web. Aggiornate il container web non attivo e, una volta aggiornato, lo impostate come quello da utilizzare.
Penso che abbia senso. Quindi il contenitore dei dati non esegue una ricostruzione tramite il launcher? Gestirei semplicemente l’equilibratura del carico a livello di host con Nginx. Fammi vedere se riesco a risolvere la questione:
contenitore dei dati:
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
Tutto dipende dagli aggiornamenti che devono essere apportati al contenitore dei dati.
L’aggiornamento a Postgres 12 è un buon esempio di tempi di inattività inevitabili. Anche se avessi un contenitore di dati duplicato, dovresti mantenere il tuo sito duplicato in sola lettura mentre viene eseguita l’aggiornamento del database.
L’unico modo per non avere mai tempi di inattività è non aggiornare mai. Gli aggiornamenti effettuati tramite /admin/upgrade su un’installazione con un singolo contenitore sono già a tempo di inattività zero. Gli aggiornamenti effettuati via ssh, come quando è necessario aggiornare l’immagine di base, comportano diversi livelli di tempi di inattività in base al tuo budget e alla tua propensione alla complessità.
Il modo migliore per evitare tempi di inattività è creare una copia di staging, altrimenti corri un piccolo rischio di tempi di inattività dopo ogni aggiornamento quando plugin o personalizzazioni incontrano problemi di compatibilità.
Ok. Quindi, per assicurarmi di non avere problemi gravi, eseguiamo un test in staging e osserviamo i risultati… quindi proverei la procedura sopra descritta per vedere se il contenitore dei dati fallisce?
In tal caso, lo staging potrebbe consistere in 1 server dati e 1 server web, mentre la produzione avrebbe 2 server dati e 2 server web. Nel peggiore dei casi, se si tenta per prima cosa in staging, la procedura in produzione sarebbe:
Se gli utenti non possono accedere al sito, è chiaramente downtime.
Se non possono registrarsi, pubblicare, rispondere o mettere ‘mi piace’, lo considereresti downtime?
Se si tratta di una comunità grande, i costi per eseguire più contenitori di dati su SSD saranno notevoli. Hai considerato l’uso di un server PostgreSQL esterno, come Amazon RDS?
I dettagli a cui @Stephen fa riferimento sono davvero importanti. Perché dobbiamo capire cosa significa zero downtime; ad esempio, potrei aggirare il requisito dello zero downtime facendo quanto segue:
Definisco lo zero downtime come non rispondere mai all’utente con un codice diverso da HTTP 200 quando la richiesta è valida (mantenendo aperti i codici 300 e 400 quando necessario). Quindi distribuisco Discourse su un droplet da 10$ in una soluzione a un singolo container e aggiungo Add an offline page to display when Discourse is rebuilding or starting up per evitare errori 500. In questo modo non mostro mai un sito che è andato offline.
Riteneresti, con una mente razionale, che questo sia zero downtime? Mai. Funziona come proposto? Certamente. E potrei anche aggiungere un server di riserva in un’altra regione per renderlo ancora più a prova di zero downtime.
È per questo che le qualifiche e la semantica sono importanti. Non è la stessa cosa mostrare sempre qualcosa ed avere sempre funzionalità sul sito.
Aiutateci a capire. Di cosa avete bisogno per raggiungere la vostra definizione di zero downtime? Gli utenti possono subire 10-30 minuti di sola lettura? Siete abbastanza esperti per creare una soluzione su misura? Cercate di mostrare ai nostri utenti una pagina carina con la scritta In manutenzione, torniamo subito. Abbiamo bisogno di più dettagli per offrirvi una soluzione più precisa che funzioni davvero per voi. O, almeno, per indicarvi la direzione giusta.
Questa discussione si stava facendo un po’ accesa e fuori tema. Ricordate di rispettarvi a vicenda mentre discutete di un argomento. Le domande di chiarimento servono a fornire una risposta più precisa, poiché le configurazioni e gli obiettivi di ciascuno sono diversi.
e non dover scoprire i casi limite nel modo difficile (in produzione) se possibile.