Oui, je le ferai par étapes :
si à ce stade tu es satisfait, arrête-toi ici, ou :
Haha, je suis ravi que tu aies posé la question, car je n’avais pas pris le temps d’expliquer cette partie (j’aurais dû – il y a beaucoup de choses à expliquer et Cloudflare est complexe !)
Lorsque la page de route des workers est configurée, chaque chargement d’image et chaque consultation de page sur le forum est acheminé via ce worker.
Le plan CDN gratuit de Cloudflare inclut une limite de 100 000 requêtes/jour sur une route de worker.
Ainsi, si vous avez un forum relativement actif, afin d’éviter d’atteindre la limite de votre offre gratuite en une seule journée, il est judicieux de ne pas la laisser activée en permanence. Il s’agit uniquement de la route du worker, et non de la page de maintenance – vous pouvez laisser la page de maintenance en place en permanence – elle n’est sollicitée que si vous avez activé la route du worker. Il s’agit simplement de l’étape 2 où vous avez assigné la route (ce qui est facile à configurer et à supprimer). À moins que vous n’utilisiez un plan payant de Cloudflare, il est donc de bonne pratique de ne l’activer que lorsque vous effectuez votre propre maintenance.
remove pour détacher la page du worker de la route.Si vous utilisez un plan payant Cloudflare, alors vous n’avez rien à craindre. Cependant, dans ce cas, vous pouvez utiliser les pages d’erreur Cloudflare au lieu d’une page de worker… (ai-je déjà mentionné que Cloudflare est assez complexe ? LOL)
configuration avancée pour administrateur ci-dessousSi l’on souhaite automatiser complètement ses mises à jour sur le plan gratuit, il faut utiliser un jeton API Cloudflare, son identifiant de zone et une commande curl pour obtenir l’identifiant de la route du worker. Ensuite, modifiez le script /root/update-web.sh avec quelques fonctionnalités supplémentaires pour activer et désactiver automatiquement la route du worker :
#!/bin/bash
cd /var/discourse
CF_TOKEN="votre_vrai_jeton_ici" #<---Jeton API Cloudflare
ZONE_ID="xxxx" #<---Depuis votre page de profil Cloudflare
ROUTE_ID="xxxx"
WORKER_NAME="ma-page-de-maintenance-site"
echo "➡️ Téléchargement des derniers scripts Docker Discourse..."
git pull
echo "➡️ Initialisation du nouveau conteneur web en arrière-plan..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Initialisation réussie !"
# Activer le Worker de Maintenance Cloudflare
echo "🚧 Activation de la page de maintenance..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*votre-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null
# Échanger les conteneurs (Fenêtre d'indisponibilité de 30 secondes)
echo "🔄 Échange des conteneurs..."
./launcher destroy web_only && ./launcher start web_only
# Désactiver le Worker de Maintenance Cloudflare
echo "🌍 Désactivation de la page de maintenance..."
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/workers/routes/$ROUTE_ID" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"pattern":"*votre-site.com/*","script":null}' > /dev/null
echo "🚀 Terminé ! Site mis à jour avec une indisponibilité invisible.
else
echo "❌ Échec de l'initialisation ! Abandon de l'échange pour garder le site actuel en ligne."
fi
J’utilise la version précédente du script car je ne souhaite pas tout automatiser et j’aime être présent lors des mises à jour / reconstructions. J’ajoute simplement la route du worker juste avant de faire une mise à jour, puis je la supprime ensuite. Cela ne prend que quelques secondes.
Mes étapes générales sont :
sudo apt update && sudo apt upgrade -y, puis redémarrer le serveur si nécessaire)./update-web.shJe ne connais rien au codage et au monde du développement, si ce n’est que j’ai fait un petit programme « Hello World » avec Visual Basic il y a très longtemps. Mais je peux faire certaines choses, car je sais mieux administrer mes serveurs WordPress et Mastodon/Pixelfed, et d’une manière ou d’une autre, mon instance Discourse. Par ailleurs, il existe cet outil nommé IA (qui n’est pas aussi simple pour un débutant que ce qu’on en dit dans la publicité).
Je ne sais pas si c’est même possible avec Discourse à cause de Docker, mais dans l’univers classique Nginx-Varnish-WordPress, j’ai mis en place un système où un serveur Plesk reçoit les informations sur les erreurs 50x et affiche une page d’erreur. En réalité, j’ai trois configurations : le frontend Nginx affiche le contenu d’une capture générée si Varnish est hors service ; Varnish utilise la capture pour le contenu non mis en cache lorsque le backend lié à WordPress est hors service ; et la troisième est une page d’erreur si le frontend Nginx ne répond pas.
Les manipulations avec Varnish ne sont pas possibles pour Discourse, mais je ne vois aucune raison pour laquelle on ne pourrait pas construire une telle toile d’araignée dans l’univers Docker, où toute erreur 50x afficherait une page d’erreur.
Ce système pourrait toutefois être très sujet aux erreurs. Et je n’ai aucune idée de ce qui se passerait s’il y avait plus qu’une poignée d’utilisateurs.
Il y a aussi la réponse la plus évidente, bien sûr : placer par exemple Nginx devant Discourse. J’utilisais cette configuration avant de passer à deux conteneurs.