Vorrei aprire una discussione sulle migliori pratiche per eseguire le attività di manutenzione principali su un’istanza Discourse riducendo al minimo o eliminando i tempi di inattività.
Attività come la modifica delle impostazioni delle risorse critiche (ad esempio, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) o l’applicazione di aggiornamenti importanti richiedono in genere un launcher rebuild app che può richiedere molto tempo, a volte 30 minuti o più.
La mia domanda è: Quali sono le strategie consigliate per gli amministratori di sistema per eseguire questi aggiornamenti essenziali e modifiche di configurazione con il minor tempo di inattività per gli utenti?
Esistono tecniche avanzate, come i deployment blue/green o altre strategie di deployment a tempo di inattività zero, che sono supportate o consigliate per Discourse? O il processo standard di rebuild è l’unico metodo supportato e l’attenzione dovrebbe essere focalizzata sull’ottimizzazione del tempo di rebuild stesso?
Sono interessato a sentire chiunque abbia esperienza nella gestione di istanze di grandi dimensioni o ad alto traffico e quale sia il loro flusso di lavoro per la manutenzione.
Se hai un’installazione a due container, il nuovo container viene creato mentre quello vecchio è in esecuzione. Il tempo di inattività è solo il tempo necessario per avviare il nuovo container. L’unico problema è che hai bisogno di abbastanza RAM per creare un container mentre l’altro è in esecuzione.
Se desideri tempi di inattività pari a zero, hai bisogno di un load balancer che mantenga in esecuzione il vecchio container finché il nuovo non si è avviato completamente. Quindi, arresti il vecchio container ed esegui le migrazioni post-aggiornamento.
Discourse è così stabile che questo è piuttosto non necessario per la maggior parte delle installazioni (ma immagino che potresti considerarlo per requisiti di altissima disponibilità o se stai ospitando altri?!).
Non credo di aver avuto un singolo downtime in 7 anni a causa di un “glitch” di produzione…
I momenti più rischiosi nella vita di un Discourse sono sempre al momento della ricostruzione.
la configurazione a due contenitori ti dà la possibilità di avviare una nuova build prima di impegnarti, anche se questo ovviamente non catturerà alcuni errori di runtime.
Il problema è che se le tue migrazioni sono state eseguite, potresti dover impegnarti nella nuova build e quindi di solito cercheresti di rintracciare e correggere la fonte di quegli errori piuttosto che eseguire il rollback.
In generale, le persone non cercano di eseguire il rollback…