Ciao, è normale che il sito sia offline durante l’installazione/aggiornamento di temi e plugin?
1 Mi Piace
È normale che il sito sia offline durante una ricostruzione.
Le soluzioni sono utilizzare un’installazione a due contenitori, che consente di creare un nuovo contenitore, riducendo i tempi di inattività a meno di un minuto, oppure escogitare una pagina “torneremo tra poco” da visualizzare mentre il sito è inattivo, il che non cambia i tempi di inattività, ma almeno tutti sanno che siete consapevoli che il vostro sito è inattivo.
Tutti pensano che almeno una di queste soluzioni sia troppo difficile e non valga assolutamente la pena.
4 Mi Piace
Per aggiungere, a differenza dei plugin, l’installazione o l’aggiornamento di temi e componenti del tema non richiederebbe tempi di inattività. 
4 Mi Piace
Esiste una documentazione sul metodo che hai menzionato? Inoltre, sembra ironico considerando che è molto adatto per la SEO in termini di discorso, ma c’è un’interruzione durante il caricamento e i bot di Google non possono eseguire la scansione del sito.
Quante volte ci si aspetta di installare un nuovo plugin? Questa è solitamente un’occorrenza molto rara.
È possibile aggiornare i plugin online con una minima interruzione del servizio poiché i container vengono scambiati.
2 Mi Piace
Grazie per le risposte. 
1 Mi Piace
Dai un’occhiata a Add an offline page to display when Discourse is rebuilding or starting up quando ti senti coraggioso.
2 Mi Piace
Ciao 
Non sono sicuro e forse mi sbaglio (non ci ho ancora provato) ma questa è ora una cosa principale? C’è un nuovo template qualche mese fa in discourse/templates chiamato offline-page.template.yml e al suo interno attiva GitHub - discourse/discourse-offline-page: offline page for discourse. Che è il sito html statico durante il caricamento di Discourse. C’è anche una PR a riguardo in discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 Mi Piace
Sembra che colpirebbe solo metà? Si presenterebbe all’avvio, ma non durante la ricostruzione, se capisco bene le ricostruzioni:
Aggiunge un template per recuperare e servire file HTML statici da GitHub - discourse/discourse-offline-page: offline page for discourse quando nginx è disponibile, ma rails non lo è.
^ La PR di GitHub
2 Mi Piace
Ma un passo nella giusta direzione, grazie @Don (e @featheredtoast ! )
Sì @Firepup650 Mi chiedevo perché non l’avessi visto, e credo che tu abbia risposto al perché!
Ci sono dei buoni 
qui dentro! 
Mi chiedo se questo sia un pre-passo per una configurazione permanente standard a due container, dove un container nginx viene creato separatamente?!??! 
2 Mi Piace
Mi hai scoperto: c’è un movimento in corso per rendere più ampiamente possibili le pagine servite offline: i commit e i repository menzionati sono le basi per renderlo disponibile, ma non è ancora (ancora) in atto.
5 Mi Piace
Per qualche motivo nessuno dei miei utenti vede che durante la ricostruzione. Beh, almeno in chat e questo è il motivo per cui ci sono stati alcuni incidenti in cui un utente ha perso solo il messaggio scritto.
La mia opinione è che la situazione in cui non informiamo affatto del downtime per gli utenti già loggati sia il più grande problema di UX singolo in Discourse. Certo, posso capire le spiegazioni da cui deriva per la sua stessa natura di questa app, e gli sviluppatori si sono un po’ dipinti in un angolo fin dall’inizio (situazioni simili a quelle con le bozze e alcune altre cose), ma ciò non cancella il problema stesso.
Abbiamo alcune soluzioni alternative. Usare Nginx come reverse proxy davanti a Discourse mostrando una pagina di errore personalizzata è una. E quando un amministratore ha problemi la risposta sarà “supportiamo solo quella standard”. Quello è stato il vero motivo per cui l’ho abbandonata.
Due container diversi sono una soluzione. O almeno mantengono il downtime molto breve. Ci sono troppi avvertimenti a riguardo, quindi sono un po’ spaventato ad intraprendere quella strada.
Oppure possiamo aggiornare solo a volte, informare gli utenti prima che accada e chiudere l’accesso pubblico. Sì, questa è una soluzione, ma… ora siamo nell’anno 2024 e solo il sistema bancario la usa nel mio ambiente 
Usare un server di staging è qualcosa che dovremmo fare. Beh, questa è una soluzione di livello aziendale, costosa e piuttosto difficile quando fatta bene, e ama il proprio team IT.
Quindi i nuovi piani trapelati 
sono davvero un miglioramento. Beh, se richiede container separati, allora è il momento di tuffarsi a capofitto, suppongo.
1 Mi Piace
È esattamente la stessa cosa tranne che raramente devi anche ricreare il container dei dati.
1 Mi Piace
Ma il tempo di inattività è molto più breve di 20 minuti, non è vero?
1 Mi Piace
La chat potrebbe contenere elementi diversi dalla visualizzazione normale del sito, poiché credo che abbia un accesso più in tempo reale rispetto alla possibilità di memorizzare le pagine nella cache.
D’accordo. La manutenzione pianificata e annunciata, a mio parere, è la migliore, come ai vecchi tempi dei BBS dial-up basati su DOS. C’era un’opzione per avere un messaggio di sistema che avvisava che la manutenzione pianificata era in arrivo e avrebbe disconnesso gli utenti all’ora stabilita. In quei giorni, si trattava tipicamente di pacchetti di posta tra BBS in rete.
1 Mi Piace
Sì. Il tempo di inattività è solitamente inferiore a un minuto, ma avrai bisogno di RAM o swap sufficienti per ricreare un container mentre l’altro viene ricreato.
1 Mi Piace