Erstellen Sie ein einheitliches Offline-/Wartungsstatus- und Seiten-Tool für Discourse

Derzeit gibt es bei jeglicher Art von Wartungsarbeiten (abgesehen von reinen Updates) keine Möglichkeit, Besuchern eine Nachricht darüber zu geben, was gerade passiert, oder eine Schätzung dafür abzugeben, wie lange das System voraussichtlich nicht verfügbar sein wird, wenn die Seite offline geschaltet oder auf Nur-Lese-Modus gesetzt werden soll.

Ich habe bereits eine Offline-Seite erstellt, und zwar über die hier beschriebene Nginx-Methode (die ich mit Schritten von hier und hier) verbessert habe, aber…

Es wäre schön, einen umfassenden Offline-Modus zu haben, der es der Administration ermöglicht, während dieser Ausfallzeiten Status-Updates und Mitteilungen an ankommende Besucher zu senden, um die Erwartungen zu steuern und den Besuchern ein gutes Gefühl für die Situation zu vermitteln, anstatt dass sie sich fragen, was eigentlich los ist.


Hier zur Nachwelt der ursprüngliche Kommentar, der diese Aufspaltung ausgelöst hat, wie von @jomaxro erwähnt:

Was hier wirklich notwendig ist, ist ein integrierter Offline-/Wartungsmodus, der diese Methodik einbezieht und die Möglichkeit bietet, benutzerdefinierte Nachrichten an Nutzer zu senden, während sich das System im Offline- und/oder Wartungsmodus befindet.

Das könnte etwas sein, das in den Upgrade-Manager integriert wird (den Upgrade-Manager in „Discourse System Manager

6 „Gefällt mir“

Docker Manager, das offizielle Plugin, das wir für Upgrades unterstützen, verursacht keine Ausfallzeiten. Es sollte keine Notwendigkeit für Änderungen am Plugin geben, da es bereits upgrades ohne Ausfallzeiten unterstützt. Das Problem, das dieses howto behandelt, sind Upgrades (Neuerstellungen), die über die Kommandozeile durchgeführt werden. Diese sind nur selten erforderlich, ein paar Mal pro Jahr, wenn wir eine zugrunde liegende Abhängigkeit aktualisieren müssen, wie z. B. die Ruby-Version oder Postgres.

Es ist nicht möglich, Docker Manager so zu gestalten, dass er solche Upgrades verarbeitet, da Docker Manager – wie ganz Discourse – während einer Neuerstellung heruntergefahren ist. Jede Lösung muss außerhalb von Discourse liegen, wie die Nginx-Proxy-Lösung, die dieses Thema bereitstellt.

7 „Gefällt mir“

Hmm, ich denke, es gibt hier andere Optionen, die besser zur Natur von Discourse passen. Anstatt dieses Konzept abzuwürgen, lass uns über Wege sprechen, das Gesamterlebnis in dieser Hinsicht zu verbessern – besonders wenn ein Admin den Standort aus irgendeinem Grund für Wartungsarbeiten herunterfahren muss.

Ein Gedanke, der mir einfällt: Warum nicht die Nginx-Proxy-Lösung gemäß dem Originalbeitrag (OP) in die Docker-Umgebung integrieren? So wird sie für Discourse-Nutzer und -Administratoren sowie für den Support (Leute wie du hier im Forum) vorhersehbarer, besser verwaltbar und konsistenter, anstatt mit entkoppelten Lösungen wie der hier vorgestellten Option umzugehen.

1 „Gefällt mir“

Ich beabsichtige nicht, das Konzept abzulehnen, sondern stelle nur fest, dass die Verwendung eines Discourse-Plugins, um dies zu lösen, nicht funktionieren wird. Lassen Sie mich diese Diskussion in ein eigenes #feature-Thema für eine ordnungsgemäße Diskussion verschieben.

@mreach, bitte bearbeiten Sie den Eröffnungspost, um zu erläutern, wonach Sie suchen und wie es funktionieren soll. Sie können den Titel bei Bedarf ebenfalls bearbeiten.

1 „Gefällt mir“

Wenn Sie während ./launcher rebuild app minimale Ausfallzeiten wünschen, benötigen Sie ein Multi-Container-Setup.

Dies ist bereits dokumentiert. Es handelt sich um ein komplexeres Setup.

Um im Einzelcontainer-Modus eine „offline“-Seite für launcher rebuild bereitzustellen, müssten wir den Container gegen einen speziellen, dedizierten Container mit der Meldung „Die Seite ist offline“ austauschen. Dies ist nicht unmöglich, würde jedoch etwa zwei Wochen Entwicklungszeit erfordern, um es perfekt zu machen. Ich denke nicht, dass wir uns dies derzeit leisten können, da das Neuaufbauen eines Containers so selten vorkommt und wir bereits eine dokumentierte Methode für störungsfreie Neuaufbauten haben.

9 „Gefällt mir“

Ich stimme Sam zu: Wenn Sie die Mittel haben, um eine Art „Seite ist offline“-Seite zu erstellen, sollten Sie Ihre Zeit lieber damit verbringen, dafür zu sorgen, dass die Seite einfach nicht offline ist. Aber vielleicht möchten Sie Add an offline page to display when Discourse is rebuilding or starting up.

Die Installation mit zwei Containern ermöglicht in den meisten Fällen Upgrades mit minimaler Ausfallzeit. Manchmal führt das Erstellen des neuen Containers eine Migration durch, die die laufende Seite abstürzen lässt. Es gibt einen Umweg, aber dieser ist ziemlich kompliziert, und solche Updates treten eher selten auf.

Sie könnten auch Ihre DNS-Einträge umleiten (oder eine elastische IP verwenden oder wie auch immer Digital Ocean das nennt) und eine Droplet-Instanz (oder wie auch immer AWS das nennt) mit einem Webserver starten, der Ihre Statusnachricht enthält.

2 „Gefällt mir“

Übrigens @jomaxro, wie hast du meinen Beitrag in dieses neue Thema hier ausgelagert? Welche Schritte hast du dabei befolgt? Das wäre ziemlich praktisch und nützlich zu wissen… Ich sehe in Discourse ohne Anpassungen keine Methodik dafür.

1 „Gefällt mir“
5 „Gefällt mir“

Oh, toll, ich muss das 5-mal übersehen haben, während ich danach in diesem Thema herumgestöbert habe.

1 „Gefällt mir“