Ce que je veux faire, c’est afficher une page disant « ce site est en maintenance » lorsqu’il est hors ligne pendant, par exemple, le processus de reconstruction.
Ce sujet correspond essentiellement à ce que j’aimerais faire, mais semble nécessiter une configuration non standard. Existe-t-il un moyen plus simple de le faire pour une installation standard ? Merci !
Non, il n’y a rien de tel pour le moment.
En réalité, cette procédure utilise ce qui est considéré comme une « installation standard » (c’est-à-dire en utilisant le guide officiel de Docker pour Discourse), auquel Nginx est redéployé à l’extérieur du conteneur.
La procédure peut sembler effrayante au début, mais elle ne l’est pas vraiment, je peux vous aider si vous le souhaitez.
Ce n’est pas la réponse que je voulais entendre, mais j’apprécie néanmoins la réponse sans ambiguïté.
Je ne suis pas trop inquiet du processus, plutôt de savoir si cette configuration nécessitera des considérations supplémentaires lors de tâches simples à l’avenir, comme l’installation d’un nouveau plugin. Ou est-ce principalement quelque chose dont, une fois configuré, je n’ai plus à m’en soucier ?
Depuis que j’ai ajouté NGINX pour cela en 2020, j’ai dû modifier la configuration deux fois. Les deux fois, il s’agissait d’ajuster les paramètres liés au téléchargement de gros fichiers après avoir mis à jour la limite dans Discourse.
Utiliser NGINX externe pour fournir la page statique et agir comme un proxy inverse pour Discourse ne nécessite normalement aucun changement une fois que vous l’avez correctement configuré.
Notez que le nginx externe apporte quelque chose d’autre de précieux en plus de la page d’erreur statique : l’attribution correcte des adresses IP source pour les utilisateurs IPv6. Si votre forum est accessible via IPv6 et que vous n’utilisez pas la configuration nginx externe, toute personne accédant à votre site via IPv6 apparaîtra comme provenant d’une adresse locale 172.x.y.z. Cela n’aide pas lorsque vous essayez de traiter avec des utilisateurs malveillants du site comme les spammeurs !
C’est exactement la même chose pour l’ajout de nouveaux plugins.
Je pense que cela facilite la mise à jour car vous savez que vos utilisateurs seront informés de la maintenance et attendront simplement qu’elle se termine.
La seule chose à laquelle je pense et dont vous voulez être sûr, c’est que vous avez correctement configuré certbot pour renouveler vos certificats. C’est intégré à la configuration par défaut qui n’utilise pas de nginx externe, mais si vous utilisez un nginx externe, vous devez également utiliser un certbot externe et vous assurer qu’il est configuré pour renouveler votre certificat. Et toutes les méthodes d’installation de certbot ne gèrent pas cela.
Notez que la documentation que vous avez demandée dit :
Si vous avez installé certbot à partir de votre dépôt de paquets, les renouvellements se font généralement automatiquement. Sinon, définissez un rappel pour exécuter
letsencrypt renew && systemctl reload nginx.serviceavant l’expiration de votre certificat !
Définir un rappel n’est cependant pas une bonne façon de faire. Vous oublierez inévitablement, et si vous manquez un e-mail de letsencrypt vous avertissant de l’expiration du certificat, votre site cessera de fonctionner. Heureusement, c’est facile à contourner.
Si les renouvellements automatiques ne sont pas configurés, voici comment faire.
Créez le fichier /etc/systemd/system/certbot.service avec le contenu suivant :
[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
Créez le fichier /etc/systemd/system/certbot.timer avec le contenu suivant :
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true
[Install]
WantedBy=timers.target
Ensuite, informez systemd des nouveaux fichiers.
# systemctl daemon-reload
# systemctl enable --now certbot.timer
Si vous utilisez une configuration à deux conteneurs, le temps d’arrêt est inférieur à une minute et vous n’avez pas vraiment besoin d’une telle page.
Après quelques recherches, il est clair que la maintenance de deux conteneurs est un travail beaucoup plus exigeant que Nginx. Du moins, à mon niveau de compétences.
Ah. Je vois. De mon point de vue, c’est presque la même chose, sauf qu’il faut faire attention à quand le conteneur de dates doit être mis à jour, ce qui est rare, mais il faut y prêter attention. Et quand cela se produit, le site est hors service pendant un certain temps.
C’est vrai aussi. C’est toujours un compromis — le temps pendant lequel un forum sera indisponible en raison de mises à jour/améliorations par rapport au temps que nécessite la maintenance de conteneurs séparés (et surtout quand on (c’est-à-dire moi) gâche tout et commence à chercher des solutions et que le forum est indisponible en même temps 
)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.