Sie können mehrere eigenständige Discourse-Installationen auf einem einzelnen Server betreiben (getrennte Container / getrennte Ports / separate app.yml), ohne die Discourse-Funktion „Multisite
eine zusätzliche Anmerkung, die direkt mit dem oben genannten HAProxy-Teil des Setups zusammenhängt.
Es gibt ein häufiges Verhalten bei HAProxy + Discourse, bei dem das Neuerstellen eines Web-Containers (z. B. mit ./launcher rebuild app1) kurzzeitig 503 Service Unavailable-Antworten zurückgibt, da HAProxy weiterhin Traffic an dieses Backend sendet, während es neu startet. Dies ist kein Fehler in Discourse selbst – es geschieht, weil das Backend während des Neuerstellungsvorgangs vorübergehend nicht verfügbar ist.
Die empfohlene Umgehung besteht darin, den HAProxy-Admin-Socket zu verwenden, um:
\t1.\tden Server in HAProxy vor dem Neuerstellen zu deaktivieren und
\t2.\tden Server nach Abschluss des Neuerstellens wieder zu aktivieren
Dies verhindert diese vorübergehenden 503er-Fehler.
Es gibt eine bestehende Meta-Diskussion, die dieses Verhalten und die Erklärung der Umgehung dokumentiert:
Wenn jemand hier HAProxy für Rolling Rebuilds verwendet, bietet dieser Thread nützlichen Kontext dafür, warum die Admin-Socket-Befehle in das Runbook aufgenommen wurden.
Ich mache etwas Ähnliches, mit einem einzigen Container im reinen Web-Stil pro Site und Traefik (obwohl ich auch eine Einrichtung mit nginx-proxy habe) als Reverse-Proxy. Ich habe eine Weile HAproxy ausprobiert (es ist das, was CDCK meines Wissens verwendet), fand es aber umständlich.
Ich bin mir ziemlich sicher, dass Sie einen Redis pro Discourse-Server benötigen.
Ich denke, hier liegt ein kleines Terminologieproblem vor.
Wenn Sie von „einem Redis pro Discourse-Server“ sprechen, stimme ich zu, wenn mit Server eine logische Discourse-Site gemeint ist.
In meinem Fall:
- HAProxy wird nur für Failover / Fronting verwendet
- Es gibt keine Multisite-Konfiguration
- Es gibt nur eine einzige Discourse-Site (einzelner Hostname, einzelne Postgres-Datenbank)
- Es gibt zufällig zwei App-Container, die in der Lage sind, dieselbe Site zu bedienen
Dies ähnelt also eher einem Multi-Web-/HA-Layout und nicht zwei unabhängigen Discourse-Installationen.
In diesem Setup ist das Teilen von Redis erwartet und erforderlich – andernfalls verlieren Sie:
- gemeinsame Sitzungen
- MessageBus-Zustellung
- Ratenbegrenzung
- Koordination von Hintergrundjobs
Dies ist dasselbe Muster wie beim Ausführen mehrerer web_only-Container oder beim horizontalen Skalieren von Web-Workern:
mehrere App-Container → eine Postgres + eine Redis.
Redis darf nicht geteilt werden, wenn zwei separate Discourse-Sites vorhanden sind (unterschiedliche Hostnamen/Datenbanken). In diesem Fall benötigt jede Site ihre eigene Redis-DB (oder Instanz), um Schlüsselkollisionen zu vermeiden.
Ich denke also, wir sind uns konzeptionell einig – es ist nur:
eine Redis pro Discourse-Site
nicht eine Redis pro individuellem App-Container
Gerne erkläre ich dies weiter, falls ich etwas missverstanden habe – ich wollte nur die Topologie klarer darlegen.
Oh. Das ist das Gegenteil von dem, worüber ich dachte, wir sprächen. Der Titel lautet „Ein Server für 2 Discourse-Communities“. Sie sprechen von „zwei Servern für eine Discourse-Community“.
Sie haben recht – ich habe zwei verschiedene Topologien vermischt, und der Thread-Titel ist der Hinweis darauf.
In diesem Thema geht es um „einen Server für 2 Communities“ (zwei unabhängige Websites).
Mein früherer Kommentar zu „externem Redis (Einzelinstanz)“ beschrieb ein anderes Muster: „zwei App-Container für eine Community“ (HA / Multi-Web für eine einzelne Website).
Um es also klar zusammenzufassen:
A) Zwei unabhängige Discourse-Seiten auf einem Server (was der OP fragt)
- Behandeln Sie diese als zwei separate Installationen
- Sie sollten separate Postgres-Datenbanken und separate Redis-Instanzen haben (oder zumindest eine Isolierung, die für MessageBus Pub/Sub ausreicht, was der Knackpunkt ist, den Sie zitiert haben)
B) Eine Discourse-Seite mit mehreren Web-/App-Containern (was ich beschrieben habe)
- Sie müssen sich dieselbe Postgres-Datenbank und dasselbe Redis für diese Seite teilen
(Sitzungen, Ratenbegrenzung, MessageBus usw.)
Also: Ihre Redis-Warnung gilt für A (zwei Communities / zwei Websites).
Mein Hinweis auf „gemeinsames Redis“ gilt nur für B (eine Community, die über mehrere Container skaliert wird).
Danke für die Korrektur – ich werde die beiden Fälle in allen zukünftigen Runbooks/Beiträgen explizit getrennt halten.