Se esegui gli aggiornamenti dall’interfaccia utente, alla fine riceverai un messaggio che dice che devi eseguire un aggiornamento da riga di comando. Non dipende da Debian, ma dall’immagine base di Discourse.
2 Mi Piace
E con il metodo a 2 contenitori non ci sarebbe alcun pulsante di aggiornamento dell’interfaccia grafica, corretto?
L’aggiornamento dell’interfaccia grafica proviene dal plugin discourse_docker. Se hai quel plugin, hai l’aggiornamento dell’interfaccia grafica.
Quando vengono scoperte vulnerabilità negli strumenti di manipolazione delle immagini, in passato si è verificata un’eccezione di codice remoto, il che significa che sei a un caricamento di immagini di distanza da un sistema compromesso.
Clear Linux ha stabilito lo standard per la velocità di avvio su Linux. È un lavoro fantastico, lo approvo di tutto cuore.
1 Mi Piace
Oh, questo cambia un po’ le cose allora. Per qualche motivo pensavo che l’aggiornamento dell’interfaccia grafica non avrebbe funzionato con un’installazione non standard a 2 container. In tal caso, finché l’amministratore è tecnicamente competente, sembra che non ci siano molti svantaggi in un’installazione a 2 container. Voglio assolutamente avere aggiornamenti dell’interfaccia grafica, ad esempio se sono in viaggio solo con il mio telefono ed esce un importante aggiornamento di sicurezza di Discourse, posso almeno applicarlo senza accesso SSH.
1 Mi Piace
Questa è la mia convinzione. Devi solo prestare abbastanza attenzione per sapere quando c’è un aggiornamento di Postgres o Redis che richiede la ricostruzione del container dati. Devi anche sapere come eseguire ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, ma non è così difficile. Puoi semplicemente eseguire ./launcher rebuild web_only, ma questo mette offline il sito mentre viene ricostruito.
2 Mi Piace
Per completezza: la build dell’interfaccia web normalmente non ha tempi di inattività; il bootstrap/destroy/start ha tempi di inattività minimi e lo farei solo normalmente con una pagina di manutenzione fornita esternamente come con nginx esterno come documentato qui. Ma questa è comunque una buona prassi, anche solo per inserire gli indirizzi IPv6 nel container.
Molto bene, grazie. E con un’installazione a 2 container si ricevono ancora le notifiche della dashboard di Discourse quando il container deve essere ricostruito? E in quel caso potrei determinare se ricostruire solo l’app o anche il container dei dati?
1 Mi Piace
Sì. Lo vedo adesso perché non ho applicato l’aggiornamento “è cambiata solo la versione” 3.1.0.beta1. 
1 Mi Piace
Questo è un caso di “va tutto bene finché non va più bene” — le persone vanno nel panico quando l’aggiornamento fallisce nell’interfaccia utente e non sanno di dover eseguire git pull; ./launcher rebuild app per aggirare il problema. Questo accade ogni volta che c’è una modifica che invalida l’aggiornamento dell’interfaccia grafica, credo. È successo di nuovo:
Ritengo che questo panico metta in evidenza il valore di avere un meccanismo di aggiornamento coerente e normale che eviti questa esperienza.
Allo stesso tempo, ho riscontrato il caso, anch’esso infrequente, in cui il bootstrap rompe il sistema in esecuzione: gli aggiornamenti con tempi di inattività quasi nulli occasionalmente si rompono in questo modo, una o due volte all’anno forse in media? Quindi non ritardare tra il bootstrap e il destroy/start.
Dovrei aggiornare il testo per renderlo chiaro, quindi lo farò dopo.
Non ho ancora distribuito LibreTranslate, ma sto pensando di farlo per rendere il mio sito più disponibile a livello internazionale.
Se ci riuscirò, ho intenzione di inserirlo nel post principale. 
2 Mi Piace