Maybe we just implemented the offline page because we started using the upgrade procedure »stop container, git pull, launcher rebuild« after being hit by things like [1,2,3] for a few times actually.
Maybe something changed on the robustness of killing PostgreSQL if it wouldn’t shutdown in time to run through the upgrade process smoothly.
Either way, the online upgrade (again) worked well for us when giving it another shot right now. So, nevermind and sorry for the noise.
È un po’ confuso, dato che quanto segue è una guida per installare e configurare nginx al di fuori del contenitore.
In ogni caso, oggi ho notato un ulteriore vantaggio di questa configurazione di nginx esterna: se hai l’abitudine di vedere indirizzi IP 127.0.0.1 o il tuo indirizzo Docker (probabilmente che inizia con 172.) come indirizzo IP di registrazione o accesso, potrebbe essere stato perché il traffico IPv6 inoltrato nel contenitore non trasportava il proprio indirizzo IPv6, a differenza di IPv4. Con questa configurazione, ora vedrai indirizzi IPv6 corretti invece di indirizzi locali.
In altre parole, questa configurazione è essenzialmente necessaria per il corretto funzionamento di uno strumento amministrativo utile sull’internet sempre più basato su IPv6. (Negli Stati Uniti, questo include molto traffico mobile.)
Grazie per questa guida molto utile! Alcuni commenti:
Penso che sudo apt-get install letsencrypt sia stato sostituito da sudo apt-get install certbot. Esecutando il primo, ricevo l’avviso Nota, selezione di 'certbot' invece di 'letsencrypt'
Un amico ha notato che la condivisione di Facebook del sito mostrava un’anteprima di “301 spostato permanentemente”.
Modifica: Inizialmente avevo sostituito la sezione location / del blocco del server sulla porta 80 con la sezione location / del blocco del server sulla porta 443. Ma penso che sia ridondante. Invece, ho semplicemente eliminato il blocco del server sulla porta 80, che fungeva da blocco di reindirizzamento, e aggiunto:
listen [::]:80;
listen 80;
nella sezione appropriata del blocco del server principale.
Ho anche abilitato il reindirizzamento HTTPS (non sono sicuro che sia necessario) dalle impostazioni di Discourse.
Questo ha risolto il problema con la condivisione su FB e sembra che le richieste HTTP normali vengano reindirizzate a HTTPS. Se esiste un altro metodo o uno migliore, fatemi sapere.
Grazie per il tutorial, è fantastico. Ora la mia pagina 502 appare molto meglio.
Nel mio caso pratico devo aggiungere la configurazione di nginx al file /etc/nginx/sites-enabled/discourse.conf.
Ho installato con successo Discourse dopo che nginx ha avviato WordPress.
Ho incontrato il problema per cui nginx non era a conoscenza del certificato rinnovato perché non è stato riavviato dopo l’installazione seguendo questa guida. Per me, la soluzione è stata:
Grazie per il tutorial, che funziona molto bene per me.
Mi chiedevo solo: se per esempio Googlebot vede quella pagina di errore, saprebbe che si tratta di una pagina temporanea? O dobbiamo inviare un codice di errore di qualche tipo per renderlo consapevole della natura temporanea della modifica?
Preferirei non vedere Google cancellare tutto l’indicizzazione del mio forum a causa di una pagina di errore più elaborata…
Google dovrebbe interpretare gli errori 500/502 come un segnale per ‘tornare più tardi’. Finché il tuo sito non viene ricostruito troppo frequentemente, non dovresti avere problemi.
Gestisco il mio forum dietro nginx da molto tempo e ciò non ha avuto un impatto negativo sul posizionamento.
Questo significa: "Quando si incontra (o si genera) un codice di risposta 502 Bad Gateway, inviare il contenuto del file /errorpages/discourse_offline.html con un codice di risposta 502 Bad Gateway. Il simbolo = indica quale codice di risposta HTTP inviare.
Tutto a posto!
E concordo con @ashs; un minuto o meno di errori 502, una o due volte al mese, non ha danneggiato la ricerca. Spesso vedo post recenti restituiti nei risultati di Google.
Un errore 502 indica probabilmente che Nginx non si sta avviando, molto probabilmente a causa di un errore di configurazione. Eseguire nginx -t per verificare se il file di configurazione è corretto. Se non ci sono errori, eseguire systemctl status nginx.service per controllare lo stato del servizio Nginx.
Sono riuscito a far funzionare nginx, ma ho ottenuto solo errori 404, anche se ho posizionato tutto correttamente e avrebbe dovuto essere visualizzato.
La mia domanda è direttamente correlata al titolo dell’argomento, ma non al metodo utilizzato in questo argomento, quindi spero sia corretto mantenerla in questa discussione.
Ho configurato qualcosa di molto semplice per risolvere questo problema e ho una domanda specifica.
Ho creato un droplet separato su DigitalOcean e ho installato un server LAMP tramite il marketplace. Successivamente, ho caricato una pagina HTML di base con alcune immagini per indicare che il server era in manutenzione. In seguito, avrei spostato un indirizzo IP tra il mio server Discourse regolare e questo server di manutenzione, a seconda delle necessità.
Ecco la domanda: affinché il server di “manutenzione” venisse caricato correttamente, ho dovuto ottenere un certificato tramite certbot per quel server (oltre a quello che avevo già per l’istanza principale di Discourse). In altre parole, due certificati per lo stesso dominio su server diversi. Ha funzionato, ma sono sempre stato preoccupato che ciò potesse causare problemi in futuro. Le letture che ho fatto online suggeriscono che sia accettabile, ma volevo sapere se qualcuno abbia avuto esperienze dirette in merito.
Questo è perfettamente lecito. Tuttavia, a seconda di come hai eseguito la convalida, il rinnovo dei certificati potrebbe non funzionare: ad esempio, se il tuo server di “manutenzione” utilizza una convalida basata su HTTP, questa fallirà finché il dominio non è puntato su di esso, il che probabilmente vanifica lo scopo. Potrebbe avere senso che il server di manutenzione copii occasionalmente l’ultimo certificato dal server principale invece di richiederne uno a Let’s Encrypt.
Grazie per la tua risposta e il tuo suggerimento, Felix.
Ammetto di non avere idea se il mio server stia utilizzando la validazione basata su HTTP (ho semplicemente fatto tutto tramite quel fantastico certbot), ma la tua preoccupazione è assolutamente logica. Ho cercato un po’, ma non riesco a trovare risorse su come copiare i certificati come suggerisci. Inoltre, suppongo che dovrei configurare un lavoro cron. Se hai ulteriori suggerimenti, sarebbe ottimo. Altrimenti, grazie ancora per il tuo aiuto.
Per copiare file direttamente da server a server, scp o rsync sono ottimi strumenti da utilizzare – questo può essere un buon punto di partenza.
Il mio suggerimento sarebbe effettivamente quello di impostare un job cron per copiare il certificato dal server principale al server di manutenzione regolarmente
Ah, e per spiegare il contesto della validazione basata su HTTP: per verificare che il dominio ti appartenga realmente, Let’s Encrypt richiederà un file specifico dal tuo server e si aspetterà una determinata risposta. Certbot può gestire ciò automaticamente (configurando temporaneamente il tuo server per restituire questo file alla richiesta di validazione), ma ovviamente, questo funziona solo se la richiesta raggiunge effettivamente il tuo server. Se il tuo DNS non punta al tuo server, o hai spostato l’IP altrove, la richiesta andrà al server sbagliato, Let’s Encrypt non riceverà la risposta attesa e rifiuterà di firmare il certificato.
Se desideri una pagina “in costruzione” mentre il sito viene ricostruito, dovrai eseguire i passaggi onerosi sopra descritti. Raccomando di passare a un’installazione a 2 container, che è un po’ più complicata da mantenere (devi sapere quando ricostruire il container dei dati), ma ha solo circa 30 secondi di inattività quando il nuovo container si avvia, ma richiede una discreta quantità di RAM al momento (2 GB potrebbero non essere sufficienti, ma non ne sono del tutto sicuro).
