Ja, ich würde es in Etappen tun:
Wenn du an diesem Punkt zufrieden bist, kannst du hier aufhören, oder:
Haha, ich bin froh, dass du gefragt hast, denn ich habe mir die Zeit gespart, diesen Teil zu erklären (ich hätte es tun sollen – es gibt viel zu erklären und Cloudflare ist komplex!).
Wenn die Worker-Route-Seite eingerichtet ist, wird jeder einzelne Bildladevorgang und jede Seitenaufruf im Forum durch diesen Worker geleitet.
Das kostenlose CDN-Paket von Cloudflare umfasst ein Limit von 100.000 Anfragen pro Tag für eine Worker-Route.
Wenn du also ein relativ stark frequentiertes Forum hast, ist es sinnvoll, die Route nicht dauerhaft aktiv zu lassen, um zu verhindern, dass du das Limit deiner kostenlosen Stufe innerhalb eines Tages erreichst. Dies betrifft nur die Worker-Route, nicht die Wartungsseite – du kannst die Wartungsseite jederzeit aktiv lassen; sie wird nur angesprochen, wenn die Worker-Route darauf verweist. Es geht also nur um Schritt 2, in dem du die Route zugewiesen hast (was einfach einzurichten und zu entfernen ist). Sofern du keinen bezahlten Cloudflare-Plan nutzt, ist es daher gute Praxis, die Route nur während deiner eigenen Wartungsarbeiten aktiv zu haben.
remove, um die Worker-Seite von der Route zu trennen.Wenn du einen bezahlten Cloudflare-Plan hast, brauchst du dir keine Sorgen zu machen. Allerdings kannst du in diesem Fall die Cloudflare-Fehlerseiten anstelle einer Worker-Seite verwenden… (habe ich schon erwähnt, dass Cloudflare ziemlich komplex ist? LOL)
erweiterte Admin-Konfiguration untenWenn man seine Updates auf dem kostenlosen Plan vollständig automatisieren möchte, sollte man ein Cloudflare-API-Token verwenden, seine Zone-ID und einen curl-Befehl nutzen, um die route id des Workers zu erhalten. Dann bearbeite das Skript /root/update-web.sh mit ein paar weiteren nützlichen Befehlen, um die Worker-Route automatisch ein- und auszuschalten:
#!/bin/bash
cd /var/discourse
CF_TOKEN="your_actual_token_here" #<---Cloudflare api token
ZONE_ID="xxxx" #<---from your Cloudflare profile page
ROUTE_ID="xxxx"
WORKER_NAME="my-site-maintenance-page"
echo "➡️ Pulling latest Discourse docker scripts..."
git pull
echo "➡️ Bootstrapping new web container in the background..."
./launcher bootstrap web_only
if [ $? -eq 0 ]; then
echo "✅ Bootstrap successful!"
# Turn ON the Cloudflare Maintenance Worker
echo "🚧 Enabling Maintenance Page..."
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":"*your-site.com/*","script":"'$WORKER_NAME'"}' > /dev/null
# Swap the containers (The 30-second downtime window)
echo "🔄 Swapping containers..."
./launcher destroy web_only && ./launcher start web_only
# Turn OFF the Cloudflare Maintenance Worker
echo "🌍 Disabling Maintenance Page..."
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":"*your-site.com/*","script":null}' > /dev/null
echo "🚀 Done! Site updated with zero visible downtime."
else
echo "❌ Bootstrap failed! Aborting swap to keep current site online."
fi
Ich verwende die vorherige Version des Skripts, weil ich nicht alles automatisieren möchte und gerne bei Updates/Neuaufbauten anwesend bin. Ich füge die Worker-Route einfach kurz vor dem Update hinzu und entferne sie danach. Das dauert nur ein paar Sekunden.
Meine allgemeinen Schritte sind:
sudo apt update && sudo apt upgrade -y) und den Server bei Bedarf neu starten./update-web.sh ausführenIch kenne mich mit Programmierung und der Entwicklerwelt überhaupt nicht aus, abgesehen davon, dass ich vor langer Zeit mal eine Hello World-Anwendung mit Visual Basic erstellt habe. Aber ich kann einige Dinge tun, weil ich besser weiß, wie ich meine WordPress- und Mastodon/Pixelfed-Server administriere, und irgendwie auch meinen Discourse-Server. Außerdem gibt es da noch diese Sache namens KI (die für einen Anfänger nicht so einfach ist, wie sie beworben wird).
Ich weiß nicht, ob das mit Discourse aufgrund von Docker überhaupt in irgendeiner Form möglich ist, aber in der gewöhnlichen Nginx-Varnish-WordPress-Welt habe ich ein System aufgebaut, bei dem ein Plesk-Server Informationen über 50x-Fehler erhält und eine Fehlerseite anzeigt. Tatsächlich habe ich drei Konfigurationen: Wenn Varnish ausfällt, zeigt der Frontend-Nginx generierte Snapshot-Inhalte an; wenn das WordPress-bezogene Backend ausfällt, beginnt Varnish, Snapshots für nicht gecachten Inhalt zu verwenden; und die dritte Option ist eine Fehlerseite, falls der Frontend-Nginx nicht antwortet.
Varnish-spezifische Dinge sind für Discourse nicht möglich, aber ich sehe keinen Grund, warum man so ein Netz nicht auch in die Docker-Welt einbauen könnte, sodass jeder 50x-Fehler eine Fehlerseite anzeigen würde.
Das könnte zwar ein sehr fehleranfälliges System sein. Und ich habe keine Ahnung, was passieren würde, wenn mehr als ein paar Handvoll Benutzer vorhanden sind.
Natürlich gibt es auch die offensichtliche Antwort: Man nutzt z. B. Nginx vor Discourse. Das habe ich früher gemacht, bevor ich auf das 2-Container-Modell umgestiegen bin.