Hallo, ist es normal, dass die Website bei der Installation/Aktualisierung von Themes und Plugins offline ist?
1 „Gefällt mir“
Es ist normal, dass die Website bei einem Rebuild offline ist.
Lösungen sind die Verwendung einer Zwei-Container-Installation, die es Ihnen ermöglicht, einen neuen Container zu erstellen, sodass die Ausfallzeit weniger als eine Minute beträgt, oder die Erstellung einer “Wir sind gleich zurück”-Seite, die angezeigt wird, während die Website offline ist. Dies ändert die Ausfallzeit nicht, aber jeder weiß, dass Sie sich bewusst sind, dass Ihre Website offline ist.
Jeder denkt, dass mindestens eine dieser Lösungen zu schwierig und den Aufwand überhaupt nicht wert ist.
4 „Gefällt mir“
Um noch hinzuzufügen, im Gegensatz zu Plugins benötigen die Installation oder Aktualisierung von Themes und Theme-Komponenten keine Offline-Zeit. 
4 „Gefällt mir“
Gibt es Dokumentationen zu der von Ihnen erwähnten Methode? Außerdem scheint es ironisch, wenn man bedenkt, dass es in Bezug auf den Diskurs sehr gut für SEO geeignet ist, aber es gibt eine Unterbrechung beim Laden und Google-Bots können die Website nicht crawlen.
Wie oft erwarten Sie, ein neues Plugin zu installieren? Dies ist normalerweise ein sehr seltenes Ereignis.
Sie können Plugins online mit minimaler Unterbrechung des Dienstes aktualisieren, während Container ausgetauscht werden.
2 „Gefällt mir“
Vielen Dank für die Antworten. 
1 „Gefällt mir“
Schau dir Add an offline page to display when Discourse is rebuilding or starting up an, wenn du dich mutig fühlst.
2 „Gefällt mir“
Hallo 
Ich bin mir nicht sicher und vielleicht irre ich mich (ich habe es noch nicht ausprobiert), aber ist das jetzt ein Kernbestandteil? Es gibt eine neue Vorlage seit ein paar Monaten in discourse/templates namens offline-page.template.yml, und darin wird GitHub - discourse/discourse-offline-page: offline page for discourse ausgelöst. Dies ist die statische HTML-Seite während des Discourse-Ladevorgangs. Es gibt auch eine PR dazu in discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 „Gefällt mir“
Das würde anscheinend nur die Hälfte davon treffen? Es würde beim Start angezeigt werden, aber nicht beim Neuerstellen, wenn ich Neuerstellungen richtig verstehe:
Füge eine Vorlage hinzu, um statische HTML-Dateien von GitHub - discourse/discourse-offline-page: offline page for discourse abzurufen und bereitzustellen, wenn nginx verfügbar ist, aber Rails nicht.
^ Der GitHub PR
2 „Gefällt mir“
Aber ein Schritt in die richtige Richtung, danke @Don (und @featheredtoast ! )
Ja @Firepup650, ich habe mich gefragt, warum ich es nicht gesehen habe, und ich glaube, du hast den Grund genannt!
Hier gibt es einige gute 
! 
Ich frage mich, ob dies ein Vorläufer für ein permanentes Standard-Zwei-Container-Setup ist, bei dem ein Nginx-Container separat erstellt wird?!??! 
2 „Gefällt mir“
Sie haben mich erwischt – es gibt Bestrebungen, das Ausliefern von Offline-Seiten weiter zu verbreiten. Die erwähnten Commits und Repos sind die Grundlage dafür, aber es ist (noch) nicht so weit.
5 „Gefällt mir“
Aus irgendeinem Grund sehen meine Benutzer dies nicht unter “Rebuilding”. Nun, zumindest im Chat, und deshalb gab es einige Vorfälle, bei denen ein Benutzer gerade geschriebene Nachrichten verloren hat.
Meiner Meinung nach ist die Situation, in der wir bereits eingeloggten Benutzern keinerlei Ausfallzeiten mitteilen, das größte einzelne UX-Problem in Discourse. Sicher, ich kann Erklärungen verstehen, woher es kommt, aus der Natur dieser Anwendung heraus, und die Entwickler haben sich von Anfang an selbst in die Ecke gedrängt (ähnliche Situationen wie bei Entwürfen und einigen anderen Dingen), aber das löst das Problem selbst nicht.
Wir haben einige Workarounds. Nginx als Reverse-Proxy vor Discourse zu verwenden und eine angepasste Fehlerseite anzuzeigen, ist eine davon. Und wenn ein Administrator Probleme hat, lautet die Antwort: “Wir unterstützen nur die Standardversion”. Das war der eigentliche Grund, warum ich diese aufgegeben habe.
Zwei verschiedene Container sind eine Lösung. Oder zumindest halten sie die Ausfallzeit sehr kurz. Es gibt zu viele Warnungen dazu, daher bin ich etwas besorgt, diesen Weg einzuschlagen.
Oder wir können nur manchmal aktualisieren, die Benutzer vorab informieren und den öffentlichen Zugriff sperren. Ja, das ist eine Lösung, aber… jetzt ist das Jahr 2024 und nur das Bankensystem nutzt das in meiner Umgebung 
Die Verwendung eines Staging-Servers ist etwas, das getan werden sollte. Nun, das ist eine Lösung auf Unternehmensebene, teuer und ziemlich schwierig, wenn sie richtig gemacht wird, und liebt das eigene IT-Team.
Daher sind neue durchgesickerte Pläne 
wirklich eine Verbesserung. Nun, wenn es separate Container benötigt, dann ist es wohl Zeit, sich ins kalte Wasser zu stürzen.
1 „Gefällt mir“
Es ist genau dasselbe, außer dass Sie manchmal auch den Datencontainer neu erstellen müssen.
1 „Gefällt mir“
Aber die Ausfallzeit ist viel kürzer als 20 Minuten, oder?
1 „Gefällt mir“
Chat kann Dinge enthalten, die sich von der normalen Website-Ansicht unterscheiden, da ich glaube, dass es sich um einen Echtzeitzugriff handelt, im Gegensatz zur Möglichkeit, Seiten zu cachen.
Zustimmung. Geplante angekündigte Wartung ist meiner Meinung nach am besten, wie in den alten Tagen von DOS-basierten Dial-up-BBSes. Es gab eine Option, eine Systemnachricht zu erhalten, die vor der geplanten Wartungsschließung warnte und Benutzer zur angegebenen Zeit abmeldete. Damals ging es typischerweise darum, Mailpakete zwischen vernetzten BBSes zu versenden.
1 „Gefällt mir“
Ja. Die Ausfallzeit beträgt normalerweise weniger als eine Minute, aber Sie benötigen genügend RAM oder Swap, um einen Container neu zu erstellen, während der andere erstellt wird.
1 „Gefällt mir“