Quello che voglio fare è mostrare una pagina che dica “questo sito è in manutenzione” quando va offline durante, ad esempio, il processo di ricostruzione.
Questo argomento è fondamentalmente quello che vorrei fare, ma sembra richiedere una configurazione non standard. Esiste un modo più semplice per farlo per un’installazione standard? Grazie!
Al momento non c’è niente del genere.
In realtà, questa procedura utilizza quella che è considerata una “installazione standard” (cioè utilizzando la guida ufficiale di Discourse Docker), a cui Nginx viene ridistribuito al di fuori del container.
La procedura sembra spaventosa all’inizio, ma in realtà non lo è, posso aiutarti se vuoi.
Non è la risposta che volevo sentire, ma apprezzo comunque la risposta inequivocabile
Non sono troppo preoccupato per il processo, piuttosto se questa configurazione richiederà ulteriori considerazioni quando farò cose semplici in futuro come l’installazione di un nuovo plugin. O è principalmente qualcosa di cui, una volta configurato, non devo più pensarci?
Da quando ho aggiunto NGINX per questo nel 2020, ho dovuto modificare la configurazione due volte. Entrambe le volte si è trattato di regolare le impostazioni relative al caricamento di file di grandi dimensioni dopo aver aggiornato il limite in Discourse.
L’utilizzo di NGINX esterno per fornire la pagina statica e fungere da proxy inverso per Discourse normalmente non richiede modifiche una volta che è stato configurato correttamente.
Si noti che l’nginx esterno porta qualcosa di prezioso oltre alla pagina di errore statica: la corretta attribuzione degli indirizzi IP di origine per gli utenti IPv6. Se il tuo forum è accessibile tramite IPv6 e non utilizzi la configurazione nginx esterna, chiunque acceda al tuo sito tramite IPv6 apparirà come proveniente da un indirizzo locale 172.x.y.z. Questo non aiuta quando si ha a che fare con utenti malintenzionati del sito come gli spammer!
È esattamente la stessa cosa per l’aggiunta di nuovi plugin.
Penso che renda più facile l’aggiornamento perché sai che i tuoi utenti saranno informati sulla manutenzione e aspetteranno che finisca.
L’unica cosa a cui penso che tu voglia essere sicuro è che tu abbia certbot che rinnova correttamente i tuoi certificati. Questo è integrato nella configurazione predefinita che non utilizza nginx esterno, ma se utilizzi nginx esterno, devi anche utilizzare certbot esterno e assicurarti che sia configurato per rinnovare il tuo certificato. E non tutti i modi di installare certbot gestiscono questo.
Si noti che la documentazione che hai chiesto dice:
Se hai installato certbot dal tuo repository di pacchetti, i rinnovi avvengono solitamente automaticamente. Altrimenti, imposta un promemoria per eseguire
letsencrypt renew && systemctl reload nginx.serviceprima che il tuo certificato scada!
Impostare un promemoria non è un buon modo per farlo, però. Inevitabilmente dimenticherai, e se perdi un’email da letsencrypt che ti avvisa della scadenza del certificato, il tuo sito smetterà di funzionare. Fortunatamente, questo è facile da aggirare.
Se i rinnovi automatici non sono impostati, ecco come farlo.
Crea il file /etc/systemd/system/certbot.service con questi contenuti:
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true
Crea il file /etc/systemd/system/certbot.timer con questi contenuti:
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true
[Install]
WantedBy=timers.target
Quindi informa systemd dei nuovi file.
# systemctl daemon-reload
# systemctl enable --now certbot.timer
Se si utilizza una configurazione a due container, il tempo di inattività è inferiore a un minuto e non è realmente necessaria una pagina del genere.
Dopo alcune ricerche qui è abbastanza chiaro che la manutenzione di due container è un lavoro molto più impegnativo di Nginx. Almeno al mio livello di competenze.
Ah. Capisco. Dal mio punto di vista è quasi la stessa cosa tranne che devi prestare attenzione a quando il contenitore delle date deve essere aggiornato, cosa che accade raramente, ma devi prestare attenzione. E quando ciò accade, il sito è inattivo per un po’.
È vero anche questo. È sempre un compromesso: il tempo durante il quale un forum sarà inattivo a causa di aggiornamenti/upgrade rispetto al tempo che richiede la manutenzione di container separati (e specialmente quando tu (leggi: io) combini un pasticcio e inizi a cercare delle soluzioni e il forum è inattivo nello stesso momento 
)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.