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.