Einverstanden, die Anweisungen könnten eine Anpassung vertragen. Es erscheint seltsam, dass der Daten-Teil nicht mehr funktionieren würde.
Längere Ausfallzeiten etwa einmal im Jahr sind nicht so schlimm…
Nein, keine Probleme außer denen, die ich durch meine fehlerhafte Bearbeitung von web_only.yml mit der bestehenden app.yml-Konfiguration verursacht habe.
Ich freue mich, berichten zu können, dass dies für dieses Zwei-Container-Setup jetzt zu funktionieren scheint!
Das einzige verbleibende Problem ist der Website-Text, der Ihnen sagt, wie Sie über die Befehlszeile neu erstellen können („app“), aber das ist eine sehr kleine Sache.
cc: @pfaffman
Das kann niemals funktionieren. Entschuldigung, dass ich das vorher übersehen habe. Ich habe den OP aktualisiert. Wenn Sie die Daten neu erstellen müssen, dann müssen Sie
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
Nein. Das ist genau das, was erwartet wird. Sie können postgres nicht neu erstellen, während ein anderer postgres auf die Dateien zugreift. Wenn ein neuer Datencontainer erstellt wird, müssen Sie einen neuen web_only-Container zerstören und starten, da Docker irgendwie mit dem exakten Container verknüpft ist und nicht mit einer Referenz auf den mit data benannten.
Werde ich verrückt oder enthält das discourse-install-Skript kein Argument mehr für --two-container? Ich habe es direkt von dem empfohlenen Ort (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) auf einem frischen Ubuntu 24.04 VPS bei Hetzner ausgeführt, und es hat nur ein reguläres Ein-Container-Setup mit einer app.yml installiert. Ich dachte vielleicht, ich müsste das discourse-setup-Skript ausführen, das daraus resultiert, aber das hat wieder dasselbe getan.
Verwenden Sie die manuelle Installationsmethode und ./discourse-setup --two-container. Das hat beim letzten Mal, als ich es verwendet habe, gut funktioniert.
Oder installieren Sie mit dem netten Installationsskript und konvertieren Sie dann in zwei Container, wie im ursprünglichen Beitrag erwähnt.
@Falco und @pmusaraj Denkt ihr, es wäre nützlich, wenn Teile der alten INSTALL-cloud.md irgendwo aufbewahrt und in der aktuellen INSTALL-cloud.md referenziert würden?
Zwei Container-Installationen, die von Personen durchgeführt wurden, die nicht tief mit Docker vertraut sind, verursachten viel zu viel Supportaufwand. Es handelt sich um eine fortgeschrittene Installationskonfiguration, die Personen vorbehalten sein sollte, die sich damit auskennen.
Sie machen es uns, die diese Funktion nutzen, also schwer. Haben Sie jemanden im Voraus nach der Änderung gefragt? Es scheint, als hätten Sie sie beibehalten können, da man die OP-Methode falsch anwenden und sich trotzdem einige Probleme bereiten kann.
Aufwand für wen? In diesem Thread? Der Support wurde von Freiwilligen/Nutzern geleistet, nicht so sehr vom Team.
Sie lassen also web_only und data in den Samples und Leute, die zwei Container verwenden möchten, müssen sie manuell kopieren und konfigurieren? Die einzige zusätzliche Unterstützung, die es vorher erforderte, war, Leuten zu helfen, die sich nie die Mühe gemacht haben, den Datencontainer zu aktualisieren.
Jetzt müssen wir einer ganzen Reihe von Leuten sagen, wie man cp und nano benutzt. Man könnte argumentieren, dass man, wenn man cp und nano nicht kennt, kein Zwei-Container-Setup betreiben sollte. Jeff argumentierte, dass man Discourse nicht installieren sollte, wenn man cp und nano nicht kennt, aber ich konnte ihn umstimmen, als ich discourse-setup schrieb.
In der nächsten Zeit werde ich mein dashboard.literatecomputing.com umschreiben, um keine Standardinstallationen mehr durchzuführen (da es keine Antworten mehr an discourse-setup weiterleiten kann) und werde dort weiterhin eine 2-Container-Installation als Option anbieten.
Ich bin kein Fan davon. Das fühlt sich wie ein Schritt näher an der vollständigen Einstellung der Unterstützung für zwei Container an, und das wäre sehr schade.
Und genau das ist das Tolle an Open Source; die Leute haben die Wahl, ihr eigenes Abenteuer zu wählen!
Dutzende von Leuten, die vergessene, veraltete Container betreiben, sind nicht gut und verursachten jedes Mal große Verwirrung, wenn PostgreSQL ein großes Update benötigte, was wiederum dazu führte, dass unser PostgreSQL seltener aktualisiert wurde, was das Gesamtprodukt verschlechterte.
Ich stimme zu
Es ist nicht möglich, die Unterstützung für Zwei- (oder N-) Container-Installationen wirklich einzustellen; Discourse verbindet sich nativ mit externen Datenbanken, wie in Configure Discourse to use a separate PostgreSQL server dokumentiert.
Es wurde keine Flexibilität entfernt, aber analog zu The Power of Defaults wird jede Option in dem von uns erstellten Tooling zu etwas, das berücksichtigt werden muss.
Das Entfernen von Tausenden von Skriptzeilen und die Straffung des Installers, um den weitaus häufigeren Anwendungsfall abzudecken, war eine bewusste Entscheidung, aber Discourse unterstützt immer noch alle gleichen Anwendungsfälle, und die Leute sind frei, ihren eigenen Weg zu gehen, wenn sie sich dafür entscheiden.
Der Komfort für diejenigen, die die entfernte Methode verwenden, wurde geopfert, um allen einen Weg aufzuzwingen. War dies eine Entscheidung einer einzelnen Person oder waren andere beteiligt?
Von codinghorror „Standards sind wohl die wichtigsten Designentscheidungen, die Sie als Softwareentwickler jemals treffen werden. Wählen Sie gute Standards, und die Benutzer werden das Lob für Ihre Software und deren einfache Bedienung aussprechen. Wählen Sie schlechte Standards, und Sie werden sich mit Benutzerfrustration über die Konfiguration auseinandersetzen müssen, und wahrscheinlich auch mit einer Reihe von technischen Supportanrufen.“
Meiner bescheidenen Meinung nach wurden schlechte Standards gewählt, und die Wahl/Änderung erfolgte ohne Beteiligung, Diskussion oder Berücksichtigung der Benutzergruppe, die die Änderung beklagt.
Noch einmal die Frage: eine bewusste Entscheidung von wem?
Dieser Benutzer empfindet diesen Kommentar als Arroganz und Respektlosigkeit. Es fühlt sich so an, als würde man herablassend behandelt und ignoriert. Ich bezweifle, dass die Absicht war, eine solche Reaktion hervorzurufen, aber hier sind wir nun.
Insgesamt ist diese Episode konsistent mit dem, worüber ich mich vor ein paar Wochen in einer privaten Nachricht mit @nat beschwert habe. CDCK/Meta hat zwei ungleiche Klassen von Kunden: diejenigen, die für das Hosting bezahlen, und diejenigen, die selbst hosten. Der Ansatz in dieser Episode ist das jüngste und vielleicht krasseste Beispiel für dieses Zwei-Klassen-System.
Mit all dem gesagt…
Ich lobe den neuen Installer. Er leistet gute Arbeit bei der Bewältigung von Installationsproblemen und den daraus resultierenden Supportanforderungen seit Tag eins.
Was die Änderung betrifft, so hat CDCK das Recht, nach eigenem Ermessen zu entwickeln/zu ändern. Da gibt es keine Diskussion. Meine Hoffnung ist, dass sie dies auf eine Weise tun können, die niemanden entfremdet.
Zuletzt brachte das erneute Lesen des Beitrags von codinghorror mich dazu, darüber nachzudenken, wie die Dinge oft waren, wenn Jeff sich in einen Beitrag einmischte. Seine Beiträge wirkten oft wie Missachtung, Respektlosigkeit und leichte Arroganz. Glücklicherweise war ich nie das direkte Ziel davon, aber einige dieser Beiträge waren schmerzhaft zu lesen. Meine jüngste Interaktion mit dem Personal bezüglich der Bearbeitung eines Beitrags und diese Episode fühlen sich sehr ähnlich an. Vielleicht bilde ich es mir nur ein.