Cool good to know, thanks for your feedback
The first post says this
Is this the only way to do it? We don’t have nginx running outside docker
Yes, that’s the only way. The idea is to install a webserver (nginx recommended) to serve the request, if Discourse is up it routes it there. If not it does something else. All the installation process is explained step by step.
2 „Gefällt mir“
Hallo,
Einleitung
Vielen Dank für diese Lösung, @fefrei! Wir haben sie auf https://community.hiveeyes.org/ implementiert, und sie funktioniert einwandfrei.
Weitere Überlegungen
Wir möchten jedoch gerne auf die verwandte Frage von @mlinksva unter Site maintenance mode during rebuilds? verweisen, da uns das ebenfalls betrifft und durch die /errorpages-Lösung noch nicht behoben wird. Es geht dabei um die Verbesserung des generischen Texts: „Entschuldigung, wir konnten dieses Thema nicht laden, möglicherweise aufgrund eines Verbindungsproblems.
Nun fühlen wir uns tatsächlich dumm, nachdem wir es sofort als anpassbaren Website-Textblock gefunden haben:
– https://community.hiveeyes.org/admin/customize/site_texts/js.topic.server_error.description
Wir haben den Standardtext js.topic.server_error.description wie folgt geändert:
Danke fürs Zuhören ;].
3 „Gefällt mir“
Hm. Wir sind uns nicht sicher, ob die Änderung dieses Textes bei uns tatsächlich funktioniert. Müssen wir beim Ändern dieses Elements etwas Besonderes beachten?
Außerdem möchten wir erwähnen, dass die Seite während eines bestimmten Zeitraums, in dem sie nicht verfügbar war, eine andere Fehlermeldung ausgegeben hat:
Haben Sie eine Idee, wie wir das auch ändern könnten?
1 „Gefällt mir“
Ich benutze das, aber ich möchte eine benutzerdefinierte Offline-Webseite und kann das nicht umsetzen.
Toller Leitfaden.
Aber wenn du nur einige Befehle zur automatischen Verlängerung dieses Zertifikats erwähnt hättest, wäre es ein vollständiger Leitfaden.
Denn ich habe den hier genannten Link gesehen. Dieser Link enthält jedoch nur Anweisungen zur frischen Installation des Zertifikats oder zur manuellen Verlängerung.
Eine Anleitung zur „automatischen Verlängerung
1 „Gefällt mir“
Guter Punkt! Ich habe diesen Abschnitt oben im Originalbeitrag aktualisiert 
1 „Gefällt mir“
Hat jemand anderes bemerkt, dass beim Upgrade eine generischere 500-Fehlermeldung angezeigt wird? Vielleicht habe ich es nur zu einem ungünstigen Zeitpunkt erwischt?
1 „Gefällt mir“
Wenn der Container während eines Neubuilds gestoppt wird, läuft nichts mehr, das einen Fehler 500 auslösen könnte.
4 „Gefällt mir“
Hat das schon jemand mit einem anderen Docker-Container versucht, um all diese manuellen Schritte zu vermeiden, wie am Anfang vorgeschlagen?
Ja, viele haben das bereits getan. Siehe Move from standalone container to separate web and data containers. Beachten Sie bitte, dass die Installation mit separaten Containern komplexer ist und viele der Anleitungen hier auf Meta von einer Installation mit einem einzelnen Container (Standalone) ausgehen. Bevor Sie zu separaten Containern wechseln, stellen Sie sicher, dass Sie verstehen, was die beiden Container tun und wie Sie zukünftig mit ihnen interagieren werden. Wichtigster Punkt: app ist kein gültiges Ziel für den Befehl ./launcher mehr.
5 „Gefällt mir“
hm, aus irgendeinem Grund wird in zwei Beiträgen immer noch „nginx in front
Jetzt bin ich verwirrt.
Keines dieser Ziele erfordert ein separates Container-Setup. Suchst du nach einer Konfiguration für beide oben genannten Schritte und suchst unabhängig davon auch nach separaten Containern? Oder hast du separate Container in Betracht gezogen, weil du dachtest, sie seien für die oben genannten Schritte erforderlich?
Meines Wissens nach kann die Offline- (Neuaufbau-) Seitenbehandlung nicht im selben Container erfolgen, da dieser nicht ausgeführt wird. Die im aktuellen Thema vorgeschlagene Lösung besteht darin, Nginx davorzuschalten. Wie in diesem Thema diskutiert wurde, erfordert dies jedoch viele manuelle Schritte und ist betriebssystemspezifisch. Daher dachte ich, dass die Verwendung eines weiteren Docker-Containers für diesen vorderen Nginx zuverlässiger und wartungsfreundlicher wäre.
Ah, jetzt verstehe ich. In diesem Fall ignorieren Sie bitte das Thema, das ich zuvor verlinkt habe. Es ging dort um die Trennung des Discourse-Webservers von der Datenbank. Das ist hier nicht erforderlich.
Die Installation von Nginx in einem Docker-Container anstatt direkt auf dem Betriebssystem ist definitiv möglich, aber mir sind keine Discourse-spezifischen Anleitungen dafür bekannt. Wenn Sie diesen Weg gehen, stellen Sie bitte sicher, dass Sie den Eröffnungspost dieses Themas verstehen (die notwendigen Änderungen zur Erstellung der Offline-Seite und zur Installation eines Nginx-Proxy davor) und dass Sie sich gut mit Docker auskennen, insbesondere mit der Konfiguration der Netzwerkkommunikation zwischen zwei Docker-Containern. Beachten Sie auch, dass wir wahrscheinlich in der Lage sein werden, nur begrenzt Hilfe zu leisten, da dies etwas ist, mit dem wir keine Erfahrung haben.
Mir ist auch aufgefallen, dass dies nicht mehr funktioniert.
Ich habe Anfang November den Ansatz von @fefrei umgesetzt, und das hat damals definitiv funktioniert. Vielleicht liegt es daran, dass ich den Container manuell gestoppt und einen git pull durchgeführt habe, anstatt /admin/upgrade zu verwenden.
1 „Gefällt mir“
4 Beiträge wurden in ein neues Thema verschoben: Unterstützung für eine native Offline-Seite beim Neuaufbau hinzufügen
Wir haben kürzlich genau das Gleiche getan, und die Offline-Seite hat erfolgreich gegriffen.
Gerade eben haben wir das Online-Upgrade über /admin/upgrade durchgeführt und festgestellt, dass Discourse überhaupt nicht offline ging! Ganz gleich, ob dies kürzlich verbessert wurde oder ob wir diesmal einfach nur Glück hatten – es ist großartig zu sehen, dass ein Online-Upgrade ohne nennenswerte Ausfallzeiten abläuft.
Discourse sollte beim Durchführen von Upgrades über Docker Manager (/admin/upgrade) niemals offline gehen. Geht es bei dir normalerweise offline? Falls ja, sollten wir ein #support-Thema dazu eröffnen.