Attualmente, quando eseguiamo qualsiasi tipo di manutenzione (a parte semplici aggiornamenti) e vogliamo mettere il sito offline o impostarlo in sola lettura, non esiste un modo per comunicare ai visitatori cosa sta succedendo o fornire una stima di quanto tempo il sistema potrebbe rimanere inaccessibile.
Sarebbe utile disporre di una modalità offline completa che permetta all’amministrazione di fornire aggiornamenti sullo stato e messaggi ai visitatori durante i periodi di inattività, per gestire le aspettative e far sì che i visitatori si sentano rassicurati invece di chiedersi cosa stia succedendo.
Per completezza, ecco l’osservazione originale che ha dato origine a questa divisione, come indicato da @jomaxro:
Ciò che serve davvero qui è una modalità offline/manutenzione integrata che incorpori questa metodologia e la possibilità di fornire messaggi personalizzati agli utenti mentre il sistema è in modalità offline e/o manutenzione.
Potrebbe essere qualcosa di integrato nel gestore degli aggiornamenti (rinominare il “gestore degli aggiornamenti” in “Gestore del sistema Discourse” e riunire in questa area aggiornamenti, log, processi e backup).
Ciò renderebbe il sistema meno fragile, più amichevole e utile sia per gli amministratori che per gli utenti.
Docker Manager, il plugin ufficiale che supportiamo per gli aggiornamenti, non causa alcun tempo di inattività. Non dovrebbe essere necessario apportare modifiche al plugin, poiché supporta già aggiornamenti senza interruzioni. Il problema a cui questo howto risponde riguarda gli aggiornamenti (ricostruzioni) eseguiti da riga di comando. Questi sono necessari solo raramente, alcune volte l’anno, quando dobbiamo aggiornare una dipendenza sottostante, come la versione di Ruby o Postgres.
Non è possibile far gestire a Docker Manager tali aggiornamenti, poiché Docker Manager, come tutto Discourse, è inattivo durante una ricostruzione. Qualsiasi soluzione deve essere esterna a Discourse, come la soluzione del proxy Nginx fornita in questo argomento.
Hmm, penso che ci siano altre opzioni qui che sarebbero più in linea con la natura di Discourse… Invece di scartare questo concetto, parliamo di modi per migliorare l’esperienza complessiva in questo senso, specialmente se un amministratore deve - per una ragione o per un’altra - mettere offline il sito per manutenzione.
Un’idea che mi viene in mente: perché non integrare la soluzione proxy Nginx come suggerito dall’OP nella configurazione Docker, rendendola così più prevedibile, gestibile e coerente sia per gli utenti/amministratori di Discourse che per il supporto (persone come te qui sul forum), invece di dover gestire soluzioni disaccoppiate come l’opzione presentata qui?
Non intendo liquidare il concetto, sto semplicemente affermando che l’utilizzo di un plugin Discourse per risolvere questo problema non funzionerà. Spostiamo questa discussione in un topic dedicato #feature per una discussione appropriata.
@mreach, modifica l’OP per dettagliare cosa stai cercando e come vorresti che funzionasse. Sentiti libero di modificare anche il titolo, se necessario.
Se desideri minimizzare i tempi di inattività durante ./launcher rebuild app, dovrai configurare un ambiente multi-container.
Questo è già documentato. Si tratta di una configurazione più complessa.
Per avere una pagina “offline” durante l’esecuzione di launcher rebuild in modalità single-container, dovremmo sostituire il container con un container dedicato speciale che mostri “il sito è offline”. Non è impossibile, ma richiederebbe circa due settimane di sviluppo per farlo funzionare perfettamente. Non credo che possiamo permetterci di finanziarlo al momento, dato quanto sia raro il rebuild di un container e considerando che abbiamo già una modalità documentata per eseguire rebuild senza interruzioni.
L’installazione a due container garantisce aggiornamenti con tempi di inattività minimi nella maggior parte dei casi. A volte la costruzione del nuovo container esegue una migrazione che fa crashare il sito in esecuzione. Esiste una soluzione, ma è piuttosto complessa e questi aggiornamenti avvengono molto raramente.
Potresti anche reindirizzare il tuo DNS (o utilizzare un IP elastico, o come lo chiama Digital Ocean) e avviare un droplet (o come lo chiama AWS) con un server web che contiene il tuo messaggio di stato.
A proposito, @jomaxro, come hai separato il mio post in questo nuovo argomento qui? Quali passaggi hai seguito? Sarebbe molto utile saperlo… Non vedo alcuna metodologia per questo in Discourse di default.