Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2 Mi Piace
Ciao,
Introduzione
Grazie per quella soluzione, @fefrei! L’abbiamo implementata su https://community.hiveeyes.org/ e funziona alla perfezione.
Ulteriori riflessioni
Tuttavia, vorremmo fare riferimento alla domanda correlata di @mlinksva su Site maintenance mode during rebuilds?, poiché risuona anche con noi e non viene risolta dalla soluzione /errorpages. Si tratta di migliorare il testo generico “Ci scusiamo, non siamo riusciti a caricare quell’argomento, probabilmente a causa di un problema di connessione.”. Cercheremo di descriverlo in modo più dettagliato.
Fornire discourse_offline.html
È perfetto quando gli utenti arrivano per la prima volta al sito.
Fornire un testo diverso “Ci scusiamo per questo”
Tuttavia, quando si naviga all’interno di Discourse, ti rimprovera in questo modo:
senza rivelare nulla sulla causa.
Dato che ti conosciamo già, probabilmente esisterà una funzione di personalizzazione per modificare quel testo, vero? Forse l’abbiamo solo saltata. Non abbiamo inoltre verificato se la funzione Admin » Backup » Abilita sola lettura risolva già il problema, come descritto su Maintenance Mode?.
Tuttavia, ci è sembrato sensato riproporre questo argomento qui e speriamo che non ti dispiaccia se fosse stato inutile.
Cordiali saluti,
Andreas.
P.S.: @staff: Poiché questa discussione è in qualche modo uscita fuori controllo riguardo ai dettagli appropriati sulla configurazione di Nginx o del server web, suggerirei una completa ristrutturazione dividendo questi post in un argomento con un nome appropriato come “Configurazione del server web per la pagina offline”. Sono sicuro che troverai un buon titolo. Grazie in anticipo se ti piace questo suggerimento e lo ritieni degno di essere seguito.
In realtà, ci sentiamo proprio stupidi dopo averlo trovato subito come un blocco di testo del sito personalizzabile:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
Abbiamo modificato il testo predefinito js.topic.server_error.description in modo che reciti:
Grazie per l’ascolto ;].
3 Mi Piace
Mmh. Non siamo sicuri che la modifica di quel testo funzioni davvero per noi. Dobbiamo considerare qualcosa di speciale qui quando apportiamo modifiche a questo elemento?
Inoltre, vorremmo segnalare che, durante un determinato intervallo di tempo in cui il sito era fuori servizio, mostrava un messaggio diverso come
Avete qualche idea su come potremmo modificare anche quello?
1 Mi Piace
Lo uso, ma voglio una pagina web offline personalizzata e non riesco a farcela.
Guida meravigliosa.
Ma sarebbe stato perfetto se avessi incluso anche alcuni comandi per il rinnovo automatico di questo certificato. Sarebbe stata una guida completa.
Ho visto il link menzionato qui, ma indica solo come installare il certificato da zero o come rinnovarlo.
Non ho però trovato indicazioni su come impostare il ‘rinnovo automatico’.
Grazie.
1 Mi Piace
Ottimo punto! Ho aggiornato questa sezione qui sopra nel post originale 
1 Mi Piace
Qualcun altro ha notato di vedere un errore 500 più generico durante l’aggiornamento? Forse l’ho colto in un momento sbagliato?
1 Mi Piace
Quando il contenitore viene arrestato durante una ricostruzione, non c’è nulla in esecuzione che possa generare un errore 500.
4 Mi Piace
Qualcuno ha provato a utilizzare un altro contenitore Docker per evitare tutti questi passaggi manuali, come suggerito all’inizio?
Sì, molti lo hanno fatto. Consulta Move from standalone container to separate web and data containers. Tieni presente che l’installazione con container separati è più complessa e molte delle guide presenti su Meta presuppongono un’installazione in un singolo container (standalone). Prima di passare a container separati, assicurati di comprendere le funzioni dei due container e come interagire con essi in futuro. L’aspetto più importante da notare: app non sarà più un target valido per il comando ./launcher.
5 Mi Piace
hm, per qualche motivo questo argomento menziona ancora “nginx davanti” in due post…
a proposito, quello che voglio davvero è:
- avere la pagina offline discussa qui
- reindirizzare http → https e il dominio radice → www sul mio server web. Non voglio usare Cloudflare per questo perché alcuni dei suoi IP sono bloccati in Russia.
Quindi, come ho capito, devo solo capire come farlo solo nel contenitore web 
Ora sono confuso.
Nessuno di questi obiettivi richiede una configurazione di container separata. Stai cercando di configurare entrambi i passaggi sopra e, in modo indipendente, stai cercando container separati? O stavi pensando a container separati credendo che fossero necessari per completare quanto sopra?
Come ho capito, la gestione della pagina offline (ricostruzione) non può avvenire nello stesso container, poiché non sarà in esecuzione. Quindi, la soluzione proposta nell’argomento corrente è aggiungere nginx davanti. Ma come discusso in questo argomento, ciò richiede molte procedure manuali e specifiche del sistema operativo, quindi ho pensato che utilizzare un altro container Docker per questo nginx frontale sarebbe più affidabile e più facile da mantenere.
Ah, ora ho capito. In tal caso, ignora l’argomento che ho collegato in precedenza. Si trattava di separare il server web Discourse dal database, cosa che qui non è necessaria.
Installare Nginx in un contenitore Docker, invece che direttamente sul sistema operativo, è sicuramente possibile, ma non sono a conoscenza di guide specifiche per Discourse su come farlo. Se scegli questa strada, assicurati di comprendere l’OP di questo argomento (le modifiche necessarie per creare la pagina offline e installare un proxy nginx davanti) e di avere una buona conoscenza del funzionamento di Docker, in particolare della configurazione della rete tra due contenitori Docker. Tieni inoltre presente che probabilmente saremo limitati nel supporto che possiamo offrire, poiché non abbiamo esperienza in questo tipo di configurazione.
Ho anche notato che questo non funziona più.
A inizio novembre avevo implementato l’approccio di @fefrei e all’epoca funzionava sicuramente. Forse è perché fermavo manualmente il contenitore ed eseguivo un git pull invece di utilizzare /admin/upgrade.
1 Mi Piace
4 post sono stati spostati in un nuovo argomento: Aggiungi il supporto per una pagina offline nativa durante la ricostruzione
Abbiamo fatto esattamente quello di recente e la pagina offline ha funzionato correttamente.
Al momento, abbiamo appena effettuato l’aggiornamento online tramite /admin/upgrade e abbiamo scoperto che Discourse non è andato offline affatto! Indipendentemente dal fatto che ciò sia stato migliorato di recente o meno, o se questa volta siamo stati semplicemente fortunati, è fantastico vedere un aggiornamento online che avviene senza sperimentare alcun comportamento significativo di downtime.
Discourse non dovrebbe mai andare offline quando si eseguono aggiornamenti tramite Docker Manager (/admin/upgrade). Succede solitamente a te? In tal caso, dovremmo aprire un argomento di supporto Support a riguardo.