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.
C’est un peu déroutant, car ce qui suit est un guide pour l’installation et la configuration de nginx en dehors du conteneur.
En tout cas, aujourd’hui, j’ai réalisé un avantage supplémentaire de cette configuration externe de nginx : si vous avez l’habitude de voir les adresses IP 127.0.0.1 ou votre adresse Docker (probablement commençant par 172.) comme adresse d’inscription ou de connexion, cela peut être dû au fait que le trafic IPv6 acheminé vers le conteneur ne transportait pas son adresse IPv6 avec lui, contrairement à IPv4. Avec cette configuration, vous verrez maintenant les adresses IPv6 correctes au lieu des adresses locales.
Autrement dit, cette configuration est essentiellement nécessaire pour le bon fonctionnement d’un outil d’administration utile sur l’internet de plus en plus IPv6. (Aux États-Unis, cela inclut beaucoup de trafic mobile.)
Merci pour ce guide très utile ! Quelques commentaires :
Je pense que sudo apt-get install letsencrypt a été remplacé par sudo apt-get install certbot. En exécutant le premier, j’obtiens l’avis Note, selecting 'certbot' instead of 'letsencrypt'.
Un ami a remarqué que le partage du site sur Facebook affichait un aperçu de « 301 moved permanently ».
Édité : J’avais initialement remplacé la section location / du bloc de serveur du port 80 par la section location / du bloc de serveur du port 443. Mais je pense que c’est redondant. Au lieu de cela, j’ai simplement supprimé le bloc de serveur du port 80, qui servait de bloc de redirection, et ajouté :
listen [::]:80;
listen 80;
dans la section appropriée du bloc de serveur principal.
J’ai également activé la redirection HTTPS (je ne suis pas sûr que ce soit nécessaire) depuis les paramètres de Discourse.
Cela a résolu le problème de partage sur FB, et il semble que les requêtes HTTP normales soient redirigées vers HTTPS. S’il existe une autre méthode ou une méthode meilleure, faites-le-moi savoir.
Merci pour le tutoriel, c’est excellent. Ma page 502 a maintenant une bien meilleure apparence.
Dans mon cas pratique, je dois ajouter la configuration nginx au fichier /etc/nginx/sites-enabled/discourse.conf.
J’ai installé Discourse avec succès après que nginx ait été configuré pour exécuter WordPress.
J’ai rencontré le problème où nginx ne connaissait pas le certificat renouvelé car il n’avait pas été redémarré après l’installation, comme indiqué dans ce guide. Pour moi, la solution était :
Merci pour le tutoriel, qui fonctionne très bien pour moi.
Je me demandais simplement : si, par exemple, Googlebot voit cette page d’erreur, saura-t-il qu’il s’agit d’une page temporaire ? Ou devons-nous envoyer un code d’erreur spécifique pour lui faire prendre conscience du caractère temporaire de la modification ?
Je préférerais éviter que Google ne supprime tout l’indexation de mon forum à cause d’une page d’erreur plus élaborée…
Google devrait interpréter les erreurs 500/502 comme un signal pour « revenir plus tard ». Tant que votre site n’est pas en reconstruction trop fréquemment, vous ne devriez rencontrer aucun problème.
Je fais tourner mon forum derrière nginx depuis longtemps, et cela n’a eu aucun impact négatif sur le classement.
Cela signifie : « Lorsqu’un code de réponse 502 Bad Gateway est rencontré (ou généré), envoyer le contenu du fichier /errorpages/discourse_offline.html avec un code de réponse 502 Bad Gateway. Le symbole = indique quel code de réponse HTTP envoyer.
Tout est en ordre !
Je rejoins également l’avis de @ashs : une ou deux minutes de 502 par mois n’ont pas nui au référencement. Je vois souvent des publications récentes apparaître dans les résultats Google.
Une erreur 502 indique probablement que Nginx ne démarre pas, sans doute en raison d’une erreur de configuration. L’exécution de nginx -t vous indique si le fichier de configuration semble correct. S’il n’y a pas d’erreur, exécutez systemctl status nginx.service pour vérifier l’état du service Nginx.
J’ai réussi à faire fonctionner nginx, mais depuis, je n’obtiens que des erreurs 404, même si j’ai tout placé au bon endroit et que cela aurait dû s’afficher.
Ma question est directement liée au titre du sujet, mais pas à la méthode utilisée dans ce sujet, j’espère donc qu’il est acceptable de la garder dans cette discussion.
J’ai configuré quelque chose de très simple pour résoudre ce problème et j’ai une question précise.
J’ai créé un droplet séparé chez DigitalOcean et installé un serveur LAMP via la marketplace. J’ai ensuite téléchargé une page HTML de base avec quelques images pour indiquer que le serveur était en maintenance. J’ai ensuite fait flotter une adresse IP entre mon serveur Discourse habituel et ce serveur de maintenance selon les besoins.
Voici ma question : pour que le serveur « maintenance » se charge correctement, j’ai finalement dû obtenir un certificat via Certbot pour ce serveur (en plus de celui que j’avais déjà pour l’instance Discourse principale). Autrement dit, deux certificats pour le même domaine sur des serveurs différents. Cela a fonctionné, mais j’ai toujours été inquiet à savoir si cela pourrait causer des problèmes à l’avenir. Les lectures que j’ai faites en ligne suggèrent que c’est acceptable, mais je voulais voir si quelqu’un a une expérience directe à ce sujet.
C’est tout à fait valide de le faire. Cependant, selon la méthode de validation utilisée, les renouvellements de certificat peuvent échouer. Par exemple, si votre serveur de « maintenance » utilise une validation basée sur HTTP, cela échouera tant que le domaine n’est pas pointé vers lui, ce qui va probablement à l’encontre de l’objectif. Il pourrait être judicieux que le serveur de maintenance copie occasionnellement le certificat le plus récent depuis le serveur principal plutôt que d’en demander un à Let’s Encrypt.
Je dois avouer ne pas savoir si mon serveur utilise une validation basée sur HTTP (j’ai tout fait via ce formidable certbot), mais ton inquiétude est tout à fait logique. J’ai un peu cherché, mais je n’ai trouvé aucune ressource expliquant comment copier des certificats comme tu le suggères. De plus, je suppose qu’il faudrait mettre en place un cron. Si tu as d’autres suggestions, ce serait super. Sinon, merci encore pour ton aide.
Pour copier des fichiers directement d’un serveur à un autre, scp ou rsync sont d’excellents outils à utiliser – ce lien peut être un bon point de départ.
Ma suggestion serait effectivement de configurer une tâche cron pour copier régulièrement le certificat du serveur principal vers le serveur de maintenance
Oh, et pour expliquer le contexte de la validation basée sur HTTP : afin de vérifier que le domaine vous appartient bien, Let’s Encrypt demande un fichier spécifique à votre serveur et attend une réponse précise. Certbot peut gérer cela automatiquement (en configurant temporairement votre serveur pour renvoyer ce fichier lors de la demande de validation), mais bien sûr, cela ne fonctionne que si la demande atteint effectivement votre serveur. Si votre DNS ne pointe pas vers votre serveur, ou si vous avez déplacé l’adresse IP ailleurs, la demande sera envoyée au mauvais serveur, Let’s Encrypt ne recevra pas la réponse attendue et refusera de signer le certificat.
Si vous souhaitez une page « en construction » pendant la reconstruction du site, vous devrez effectuer les étapes fastidieuses ci-dessus. Je recommanderais de passer à une installation à 2 conteneurs, qui est quelque peu plus difficile à maintenir (vous devez savoir quand reconstruire le conteneur de données), mais qui n’a qu’environ 30 secondes d’interruption lorsque le nouveau conteneur démarre, mais qui nécessite actuellement une quantité considérable de RAM (2 Go pourraient ne pas suffire, mais je ne suis pas entièrement sûr).
