[quote=“pfaffman, Beitrag: 47, Thema: 29413”]
Meine Sorge war schon immer, dass die Unterstützung schwierig sein würde, da Personen, die es nicht verstehen, versuchen werden, es zu nutzen, und dann keine Dokumentation verwenden können, da „rebuild app
Ja. Der bestehende Web-Container läuft weiter, während der neue Container erstellt wird. Die Ausfallzeit beschränkt sich dann nur auf die Zeit, die zum Starten des neuen Webservers benötigt wird – in der Regel weniger als eine Minute, ist aber keineswegs eine Lösung ohne Ausfallzeit. Wenn Sie eine unterbrechungsfreie Verfügbarkeit erreichen möchten, benötigen Sie einen Reverse-Proxy davor, der es dem neuen Container erlaubt, hochzufahren und die Arbeit aufzunehmen, bevor Sie den alten herunterfahren. (Und wenn die Datenbank-Migrationen für den neuen Container Probleme für den alten Container verursachen, entsteht dort ebenfalls Ausfallzeit, es sei denn, Sie ergreifen andere Maßnahmen).
Bei der Wiederherstellung aus einem Backup gibt es keinen Unterschied.
4 „Gefällt mir“
Danke Jay @pfaffman,
Du bist definitiv eine erstklassige und wertvolle Ressource hier!
Was hältst du von dieser vielleicht verrückten Idee (basierend auf meinem noch begrenzten Verständnis):
Richte nginx als Reverse-Proxy im Frontend ein; gemäß diesem Tutorial:
Richte dann zwei Verzeichnisse bzw. Instanzen mit discourse_docker (Standalone) ein, zum Beispiel:
- /var/discourse1
- /var/discourse2
Richte in beiden Instanzen discourse_docker (Standalone) so ein, dass es auf einem anderen Socket lauscht, indem du in jeder Instanz diese Vorlage änderst:
- "templates/web.socketed.template.yml"
Kurz gesagt: Wir haben die Produktion (zu einer ruhigen Zeit) einfach so neu aufgebaut, dass sie in einem anderen Container läuft und auf einem anderen Socket lauscht (nginx.https.sock2). Dadurch gibt es keine Socket-Konflikte; dies kann ebenfalls im Standalone-Modus aufgebaut werden (mit dem Ziel, die Notwendigkeit für zwei Container, data und web-only, zu eliminieren).
Zum Beispiel (zur Diskussion/Veranschaulichung) in web.socketed.template.yml in discourse1:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock ssl http2;
set_real_ip_from unix:;
und in discourse2:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock2;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock2 ssl http2;
set_real_ip_from unix:;
Anstatt jedoch, dass die Discourse-Vorlage die Magie übernimmt, schalten wir einfach manuell die Sockets in /etc/nginx/conf.d/discourse.conf um und starten nginx neu. Dazu würden wir die Direktive replace: in der Vorlage web.socketed.template.yml entfernen.
In dieser vorgeschlagenen (vielleicht verrückten) Konfiguration können wir zwei Standalone-Container haben, die auf zwei verschiedenen Sockets lauschen (ohne Konflikt), und wir konfigurieren einfach nginx, um sich mit dem gewünschten Socket zu verbinden und nginx neu zu starten.
Das scheint klar, einfach und möglicherweise nützlich zu sein (während einer ruhigen Phase ohne neue Beiträge in der Live-Instanz) für diejenigen, die die Komplexität von zwei Containern (data und web-only) pro einzelner Discourse-Instanz (App) nicht wollen (oder benötigen).
Natürlich wäre die robusteste Konfiguration (aus Datensicht) jedoch für Perfektion bei stark frequentierten Seiten die “Zwei-Container”-Lösung, da wir sowohl die data- als auch die web-only-Instanz (die nun auf zwei verschiedenen Sockets lauschen, sock und sock2) benötigen würden.
Bei der “Zwei-Container-Lösung” mit dem nginx-Frontend ist die “Standardkonfiguration”, dass beide web-only-Container auf demselben Socket lauschen, sodass sie nicht gleichzeitig laufen können. Wenn wir sie jedoch (nur als Beispiel) auf verschiedenen Sockets lauschen lassen, könnten beide gleichzeitig laufen, und wir könnten einfach die nginx-Konfigurationsdatei (und einen nginx-Neustart) verwenden, um zwischen den beiden zu wechseln.
Ist das das richtige Verständnis?
Beginne ich langsam, aber hoffentlich sicher, dies zu verstehen?
Danke!
Nur ein Nachtrag: Ich habe die “Zwei-Container”-Konfiguration auf einem meiner Desktop-Macs zum Laufen gebracht:
Der einzige Haken bei unserer Installation war die Notwendigkeit, diese Verzeichnisse manuell zu erstellen (und Besitzrechte sowie Berechtigungen festzulegen), da diese Verzeichnisse aus irgendeinem Grund nicht von den Skripten erstellt werden:
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
Und natürlich habe ich zunächst versucht, mit einem leeren Passwort für die Datenbank zu arbeiten, was nicht funktionierte (die Anweisungen sagen zwar, ein Passwort festzulegen, aber ich habe nur experimentiert).
Als Nächstes werde ich das nginx-Frontend einrichten und versuchen, mit websocket für die web-only-App zu dieser Konfiguration zu wechseln.
Das ist viel auf einmal. Aber es gibt keinen Grund, zwei Discourse-Verzeichnisse zu haben. Erstellen Sie einfach mehrere YAML-Dateien im containers-Verzeichnis. Benennen Sie sie wie immer Sie möchten.
2 „Gefällt mir“
Danke für die Bestätigung. Genau so haben wir uns nach den heutigen Tests eingerichtet (einzelnes Verzeichnis).
Mit der Konfiguration für zwei Container (2CC) lief alles reibungslos, aber ich habe Probleme mit dem Einrichten des Nginx-Reverse-Proxys auf macOS.
Ich bekomme keine funktionierende Verbindung zum Unix-Domain-Socket im Verzeichnis /shared, obwohl der Socket außerhalb des Containers erreichbar ist. Ich habe es mit Nginx, Python und Socat (zum Testen) versucht. Immer Fehler 61: Verbindung verweigert. Hmmmm.
Den ganzen Tag schon an der “Verbindung verweigert”-Meldung gescheitert!!
Morgen ist ein neuer Tag.
Ich habe eine kurze Frage.
Wenn wir nur eine Container-Konfiguration hätten (nur app.yml) und den Befehl ./launcher bootstrap app ausführen würden, würde dann unsere Website/Frontend gestoppt oder nicht?
Wenn ja: Warum stoppt bootstrap web-only unsere Website dann nicht?
Wenn nein: Welchen Vorteil bietet das Zwei-Container-Setup in Bezug auf Zeitersparnis beim Neuaufbau unseres Containers? Mit anderen Worten: Wenn wir unsere Website auch dann laufen lassen können, während wir unseren einzelnen Container bootstrappen, warum benötigen wir dann zwei separate Container?
1 „Gefällt mir“
Nein, wenn du eine neue .yml-Datei erstellst, nenne sie beispielsweise new_image.
Beim Bootstrapping werden, sofern korrekt konfiguriert, keine Dienste gestartet oder gestoppt. Gebootete Images werden nicht ausgeführt. Deshalb heißen sie „gebootet
2 „Gefällt mir“
Um die Wahrheit zu sagen, habe ich nichts verstanden. Ich habe es versucht. Aber ich habe versagt.
Meine Frage war einfach.
Wenn wir ein Setup mit zwei Containern haben und unseren „nur-Web“-Container „bootstrapen“ (nicht neu aufbauen), bleibt unser aktueller Web-Container funktionsfähig (weil unsere Website als funktionsfähig/OK angezeigt wird).
Und wenn wir ein Setup mit einem einzelnen Container haben, wie z. B. „app.yml“, und dann diesen „app“-Container bootstrapen, funktioniert unsere Website dann weiterhin?
Und wenn die Erklärung einfach ist, warum ist das dann so?
1 „Gefällt mir“
Vielleicht solltest du jemanden einstellen, der dir hilft?
1 „Gefällt mir“
Kein Problem.
Es war nur eine kleine Unklarheit. Ein Teil davon könnte vielleicht auch mit „Ja/Nein
1 „Gefällt mir“
Mein Vorschlag ist, es einfach selbst auszuprobieren.
Es dauert tatsächlich weniger Zeit, es in deinem eigenen Testumfeld selbst auszuprobieren, als eine Frage zu stellen und auf eine Antwort in einem Forum zu warten.
Du bekommst die Antwort auf deine Frage, wenn du es ausprobierst. Deshalb solltest du diese Dinge in einem Test-Szenario ausprobieren, damit du deine Produktions-App nicht beschädigst 
Discourse ist Open Source und kann dank der Großzügigkeit der Mitbegründer kostenlos heruntergeladen und konfiguriert werden. Das bedeutet, dass du diese Open-Source-Software nutzen und frei Test-Apps erstellen, löschen, neu erstellen und wieder löschen kannst (so oft du möchtest).
Wenn du nicht bereit bist, etwas Mühe in grundlegende Systemverwaltungsaufgaben zu stecken, hatte @codinghorror einen großartigen Vorschlag, lokale Talente hier zu engagieren.
1 „Gefällt mir“
Ja. (Es sei denn, das Booten migriert die Datenbank so, dass der laufende Container sie nicht mehr verwenden kann). Es gibt eine Ausfallzeit, während der alte Container heruntergefahren wird und der neue hochfährt.
Nein. Es können nicht zwei Datenbankprozesse gleichzeitig auf dieselben Dateien zugreifen.
3 „Gefällt mir“
Oh!!
Danke, dass du das geklärt hast.
1 „Gefällt mir“
Wenn die Datenbank nicht im von Ihnen erstellten Container liegt, können Sie einen neuen Web-Container erstellen, der mit der Datenbank interagiert, während der andere Web-Container weiterhin funktioniert.
1 „Gefällt mir“
Schnelle Frage zu diesem Ansatz: Wie würde man bei dieser Einrichtung mit Rebuilds verfahren?
Angenommen, wir starten mit dem von @pfaffman hinzugefügten Zwei-Container-Setup, dann haben wir zwei Container: „data
Wir verwenden „drei Container
2 „Gefällt mir“
Sie müssen den Datencontainer nur neu aufbauen, wenn es ein Upgrade für PostgreSQL (wie gerade geschehen) oder Redis (was in den letzten etwa 6 Monaten geschehen ist) gibt.
Meistens ersetzen Sie in den Anweisungen einfach web_only durch app. Ich habe Notizen unter Managing a Two-Container Installation - Documentation - Literate Computing Support.
5 „Gefällt mir“
[quote=“neounix, Beitrag: 63, Thema: 29413”]
IMHO ist dies (im Allgemeinen) der „richtige Weg
[quote=“Iceman, Beitrag: 65, Thema: 29413”]
Also haben Sie bei diesem Ansatz zwei Web-Instanzen und nutzen die inaktive, um Dinge mit denselben Daten zu testen? Das ist interessant, ich werde es definitiv ausprobieren, sobald ich mich mit dieser ganzen Strategie des „Platzsparens
1 „Gefällt mir“
Danke für die Details. Ich habe es gerade in einer Testumgebung ausprobiert, zwei „App-Container