Es ist besser als DigitalOcean und Konsorten, also ja, es ist eine gute Sache.
Es war in Ordnung, aber ich habe auch die Einschränkungen hervorgehoben, die Seiten hatten wirklich wenig Traffic und geringe Aktivität. Wenn Sie eine signifikante Aktivität auf diesen Seiten erwarten, benötigen Sie mehr Ressourcen, die Ressourcennutzung von Discourse steigt mit zunehmender Aktivität.
Das hängt wirklich davon ab, ob Sie die Notwendigkeit haben, einige Websites von anderen zu isolieren oder nicht. Kommerzielle Discourse-Hostings sind normalerweise nur große Multisite-Cluster mit etwas „Spezialsauce“ obendrauf, um ihr Abrechnungssystem usw. unterzubringen.
Nun, sofern Sie keine fortgeschrittene Konfiguration eingerichtet haben, teilen sich alle Websites die Anmeldeinformationen der übergeordneten Website. Das heißt, ohne eine fortgeschrittene Konfiguration wird, wenn die übergeordnete Website für noreply@example.com als ihre Keine-Antwort-E-Mail konfiguriert ist, diese auch von allen untergeordneten Websites verwendet. Sie benötigen eine zusätzliche Einrichtung, wenn Sie eindeutige E-Mails pro Website wünschen.
Hängt größtenteils davon ab, was Sie als „Probleme“ einstufen.
Eine einzelne app.yml für Multisite ist machbar, aber ich würde für eine Multisite zu einer 2-Container-Installation (separater Web- und Daten-Container) raten.
Sie müssen einige Herausforderungen meistern, Pfade in den yml-Dateien ändern und sie dann hochfahren. Im Wesentlichen hat /var/discourse-a seine eigene Konfiguration und /var/discourse-b seine eigene.
Nur zur Info, dies sind ziemlich technisch anspruchsvolle Konzepte. Sie benötigen wirklich Erfahrung mit Discourse und seinen internen Abläufen, um Multisite hosten zu können. Wenn Sie sich dabei unsicher fühlen, sollten Sie vielleicht ein Managed Hosting für Discourse in Betracht ziehen oder jemanden beauftragen, es professionell für Sie einzurichten. Das wird Ihnen auf lange Sicht erhebliche Kopfschmerzen ersparen. Erwägen Sie, im Bereich Marketplace zu posten, falls Sie ein Budget haben.
Ja, aber deshalb sagte ich ja, dass ich im Laufe der Zeit immer auf einen höheren Plan mit mehr Ressourcen umsteigen kann. Es war nie mein Plan, lange auf diesem … Plan … zu bleiben. Ich versuche nur, unnötige Kosten zu vermeiden, wenn ich die Lage ausloten, wissen Sie?
Können Sie mir ein paar Gründe nennen, warum ich sie getrennt haben möchte, abgesehen von den Serverressourcen? Im Moment sehe ich keinen guten Grund, sie auf separaten Servern zu haben, aber ich bin immer bereit, ein paar verschiedene Perspektiven zu Dingen zu lernen, die ich noch nicht weiß.
Das ist ein sehr interessanter Punkt, den ich nicht wusste. Es scheint also, dass dies tatsächlich etwas ist, das getan wurde und funktioniert. Gut zu wissen.
Was meinen Sie mit Eltern-Seite? Wäre nicht jede Installation unabhängig? Welche würde als Elternteil betrachtet werden?
Ich bin etwas verwirrt, denn wenn ich mir die Datei app.yaml ansehe, gibt es einen eigenen Bereich für die Brevo-E-Mail und die Anmeldeinformationen. Sie sagten, ich könne den Weg gehen, für jede Community eine eigene app.yaml-Datei zu haben. Würde das nicht bedeuten, dass jede Community ihre eigenen Brevo-Anmeldeinformationen hätte, einschließlich der Benachrichtigungs-E-Mail?
Dinge, die mich daran hindern, ordnungsgemäß Backups zu erstellen, oder Benachrichtigungs-E-Mails, die nicht richtig gesendet werden, solche Dinge. Wiederum, als Nicht-Experte und noch neu bei Discourse, gibt es Dinge, die andere Leute als Problem ansehen könnten, die ich aber noch nicht sehe.
Ja, das dachte ich auch. Das Einzige, was geteilt würde, wäre der Server selbst. Alles andere würde als separate Installation funktionieren, daher die Frage nach der E-Mail oben.
Ich denke, die schwierigsten Schritte für mich waren bereits getan, nämlich vor ein paar Monaten tief in die Installation von Discourse einzutauchen. Ich hatte null Ahnung davon. Ich wusste nicht einmal, was „Docker“ bedeutet. Im Moment habe ich eine viel klarere Perspektive, obwohl ich mich beim Self-Hosting immer noch als „Basis-Discourse-Benutzer“ betrachte. Und mit der Hilfe dieser Community und von ChatGPT/Claude konnte ich etwas mehr lernen und mir Notizen darüber machen, wie Dinge funktionieren und installiert werden. Ich komme mit Herausforderungen klar, und seien wir ehrlich: Das ist wirklich nur die Installation von Software. Es ist nicht so, dass ich eine Atombombe baue Wenn etwas schiefgeht, alles löschen, zurück zu einer einzigen Installation pro Server. Alles gut
Wie ich bereits erwähnt habe, habe ich meine eigene Community bereits installiert, daher denke ich, dass der schwierigste Teil bereits hinter mir liegt. Ich bin gut darin, Anweisungen zu befolgen und Fragen zu stellen. Wenn ich Dinge ausprobiere, kann ich jederzeit eine Pause einlegen und recherchieren, Notizen machen usw.
Mein Ziel ist es jetzt mehr, die Mechanik dahinter zu verstehen, die Vor- und Nachteile, was möglich ist und was nicht, damit ich gute Entscheidungen treffen kann, die ich später nicht bereuen werde und die mich zu viel Zeit mit der Behebung von Problemen kosten, wissen Sie?
All diese Informationen, die ihr heute teilt, sind also super wertvoll, weil sie mir eine gute Vorstellung davon geben, worüber ich nachdenken muss. Besonders als Sie erwähnten, dass das vom Discourse-Team angebotene Managed Hosting ein Multisite ist. Das hat mir wirklich gezeigt, dass dies möglich ist. Vielleicht sind ein paar zusätzliche Schritte erforderlich, aber alles ist machbar.
Sie müssen sich zuerst entscheiden, ob Sie eine einzelne Multisite oder einen einzelnen Server möchten, der mehrere eigenständige Websites hostet. Ich werde mit der Beantwortung Ihrer oben gestellten Fragen warten, bis Sie sich für das eine oder das andere entschieden haben. Es gibt viel zu verstehen, allein die Installation von Discourse auf einer VM macht Sie nicht automatisch für den Multisite-Aufwand berechtigt, zum Beispiel habe ich 3 Jahre gebraucht, um die Multisite-Installationserfahrung für mich selbst zu perfektionieren. Zugegeben, die Dokumentation war in vielen Dingen nicht sehr klar und ich musste viele Dinge selbst herausfinden, um es richtig zu machen. Und ich benutze Discourse seit 2016-17 (fast 9-10 Jahre zu diesem Zeitpunkt).
Nehmen Sie sich also bitte einen Schritt zurück und überdenken Sie, was Sie erreichen möchten, und dann können wir uns darauf konzentrieren, dies zu erreichen.
Denken Sie noch einmal daran, dass die Installation von Discourse nicht die größte Hürde ist, es gibt noch viel zu lernen, und selbst nach 9 Jahren der Nutzung und Bereitstellung von Discourse betrachte ich mich immer noch als jemanden, der jeden Tag neue Dinge lernt.
Das war schon immer mein Ziel. Ich sehe keinen Vorteil für das, was ich baue, in einer einzigen Multisite. Mein Ziel ist es, nur Kosten zu sparen, indem ich einen Server mit unabhängigen Installationen verwende.
Und ich verstehe, was Sie mit Komplexität meinen. Deshalb sagte ich, dass ich mich, obwohl ich es installieren konnte und jetzt einige der Konzepte verstehe, als grundlegenden Benutzer betrachte, wenn es um die Installation geht.
Nachdem ich fast 35 Jahre lang Musik gemacht habe, lerne ich immer noch jeden Tag neue Dinge, also ist das in Ordnung. Ich bin damit einverstanden, jeden Tag zu lernen, und ich erwarte nie, damit aufzuhören Deshalb bin ich hier in dieser Community. Um neue Dinge mit euch allen zu lernen.
Wenn Sie also einfach mehrere Discourse-Seiten auf demselben Server haben möchten, ohne dass diese sich den Code oder den Container teilen, können Sie Folgendes versuchen:
Lesen Sie die app.yml sorgfältig durch und verstehen Sie den Abschnitt mounts. Sie benötigen für jede Seite unterschiedliche, vorhersagbare Mounts. Mindestens müssen Sie diese Verzeichnisse manuell bearbeiten.
Das einzige Mal, als ich dies tat (und ich glaube, ich habe es auf die unergonomischste Weise getan), habe ich den Discourse-Code in zwei verschiedene Verzeichnisse geklont, was möglicherweise nicht notwendig ist, aber ich habe es nicht versucht, daher bin ich mir nicht sicher.
In jedem Verzeichnis habe ich ./discourse-setup mit einigen Flags ausgeführt, um die Konnektivitätsprüfung und das Neuerstellen zu überspringen. Das ergab mir Basis-app.yml-Dateien. Der nächste Schritt war, beide Dateien manuell zu bearbeiten. Ich habe die Mounts geändert, den Abschnitt auskommentiert, der Ports freigibt, und die web.socketed-Vorlage hinzugefügt, damit mein externer Nginx die SSL- und internen Weiterleitungen übernimmt.
Danach war es so einfach wie das Ausführen von ./launcher rebuild app in jedem Verzeichnis.
Ehrlich gesagt war ich kein großer Fan dieser Einrichtung, also habe ich nach ein paar Monaten des Herumspielens aufgegeben. Aber es zeigt, dass das, was Sie versuchen zu tun, tatsächlich machbar ist, nur dass Sie einiges herausfinden müssen.
Möglicherweise möchten Sie auch die Anzahl der Worker usw. reduzieren, damit alle Seiten eine faire Chance haben, die Ressourcen zu nutzen, aber das ist ein Gedankenexperiment für den Zeitpunkt, an dem Sie die anfängliche Grundlage geschaffen haben.
Vielen Dank für die detaillierten Informationen!
Ich überlege noch, welche die beste Option ist, und selbst wenn ich mich für diese Option entscheide, muss ich noch einige Dinge klären.
Meinen Sie diesen Bereich? Denn als ich nach dem Wort „mount“ gesucht habe, kam nichts, aber ich nahm an, es hätte etwas mit den Volumes zu tun?
Wenn ja, dann erstelle ich dort verschiedene Pfade wie
var/discourse/shared/website1
var/discourse/shared/website2
usw.?
Haben Sie also im Grunde eine normale Installation in einem der Pfade durchgeführt, zum Beispiel:
var/discourse/shared/website1
und dann diese Dateien kopiert nach
var/discourse/shared/website2
?
Wenn ja, warum ./discourse-setup ausführen? Würde das nicht Dateien überschreiben?
Wäre es nicht besser, einfach normale Installationen in beiden Pfaden durchzuführen? Wie zwei komplett separate Installationen? Für jemanden wie mich, besonders wenn Sie die „Flags“ und all das erwähnen, sind das weitere Dinge, um die ich mich kümmern müsste, und vielleicht wäre eine normale Installation besser, um dann die app.yaml-Dateien in jedem Pfad manuell zu bearbeiten?
EDIT: Vergessen Sie es. Ich habe etwas recherchiert und verstehe jetzt, was Sie mit „klonen“ in diesem Zusammenhang meinen. Sie haben die Repository-Dateien geklont. Ich dachte, Sie meinten, Sie hätten alles in einem „Pfad“ installiert und dann diese Dateien in einen anderen „Pfad“ kopiert.
Haben Sie bereits eine Discourse-Instanz am Laufen? Sie sind schon eine Weile in diesem Forum. Versuchen Sie, eine zweite Instanz auf einem Server einzurichten, auf dem bereits eine Instanz läuft?
Der beste Weg zu lernen ist, es einfach zu versuchen. Richten Sie einen günstigen VPS ein und probieren Sie es aus. Wenn Sie noch keine Instanz betreiben, richten Sie einfach eine reguläre selbst gehostete, unterstützte Installation ein und lernen Sie die Umgebung kennen. Sie werden keine wirklichen Besucher haben und keinen Grund, irgendetwas speichern zu müssen. Sie können die Installation einfach löschen und es immer wieder versuchen, bis Sie es beherrschen. Wenn Sie zwei oder sogar drei Instanzen einrichten, die alle auf einem einzigen VPS laufen und (virtuell) keinen Traffic erhalten, würde ich wetten, dass der billigste VPS da draußen sie wahrscheinlich betreiben könnte.
Wenn Sie es zum Laufen bringen, posten Sie ein Tutorial, damit wir alle davon lernen können!
Ja, das habe ich. Ich möchte zusätzliche Instanzen installieren.
Da diese Installation noch neu ist und sich noch keine Benutzer angemeldet haben, gibt es damit keine Probleme. Ich werde sie zuerst sichern und alles auf diesem Server ausprobieren. Es besteht noch kein wirkliches Risiko.
Das werde ich auf jeden Fall tun. Hoffentlich kann es anderen helfen.
@itsbhanusharma Ich habe sowohl ChatGPT als auch Claude einige weitere Fragen gestellt, weil ich überlegt hatte, den Pfad der aktuellen Instanz von „discourse“ in den Namen der Website wie „website-name“ umzubenennen, und beide wiesen auf einige gute Punkte hin. Einer davon ist, dass jede Installation 2 GB RAM benötigt. Wenn ich also beispielsweise 5 Installationen installiere, bräuchte ich 10 GB, oder?
Wenn das der Fall ist, wäre dieser Plan wahrscheinlich besser:
Immer noch ein sehr guter Preis für 5 Instanzen, anstatt $5 x 5 = $25.
Was denken Sie über die Notwendigkeit von 2 GB pro Instanz? Ist das in diesem Szenario korrekt? Glauben Sie, dass der von mir geteilte Plan gut geeignet wäre?
Ich habe mehrere Fälle, in denen Kunden ihren Discourse-Seiten mehr Schaden als Nutzen zugefügt haben, weil sie blindlings Ratschläge von ChatGPT befolgt haben.
Das ist etwas nuancierter und die Art von Sache, die nicht so einfach ist wie 2+2 zusammenzuzählen. Und das ist größtenteils der Grund, warum der Multisite-Ansatz eine bessere Idee ist.
Noch einmal: Ich würde sagen, hör auf, mach eine Pause, tritt einen Schritt zurück und überdenke deine Bedürfnisse. Hier im Meta-Forum gibt es gute Ressourcen, und der einzige KI-Bot, dem ich für Discourse-Ratschläge vertrauen würde, ist https://ask.discourse.org
Ich stimme zu, aber überprüfen Sie die Informationen, indem Sie die Quellen lesen, die der Bot angibt. Auf diese Weise stellen Sie auch sicher, dass er die Links nicht erfunden hat (es kommt vor!).
Das ist etwas extrem… Niemand folgt blindlings den Ratschlägen von ChatGPT (zumindest nicht ich), deshalb führe ich dieses Gespräch hier mit Ihnen allen.
Ich benutze diese Tools als Werkzeuge. Sie erwähnen Dinge, die mir erlauben, andere Blickwinkel zu sehen, dann recherchiere ich online oder stelle hier in der Community Fragen. Unterwegs zeigen sie mir auch andere Konzepte, die nicht streng mit Discourse zusammenhängen, was auch gut ist. Die Tools sind nur so gut wie die Person, die sie benutzt.
Und ich habe viel mit Tipps von ChatGPT und Claude erreicht. Wir können nicht alles, was sie sagen, verwerfen… blindlings
Könnten Sie mir das etwas genauer erläutern? Wenn die Informationen von ChatGPT / Claude ungenau sind, können Sie mich und andere, die dies in Zukunft lesen, vielleicht aufklären?
Nicht in meinem Fall, aus ein paar Gründen (und es sei denn, ich übersehe etwas, hier sind sie):
Ich möchte in der Lage sein, bei Bedarf benutzerdefinierte Änderungen an jeder Instanz vorzunehmen, ohne die anderen zu beeinträchtigen. Nicht, dass ich es tun werde, aber ich möchte wissen, dass ich es kann, wenn ich es möchte.
Bei einer Multisite stürzt alles ab, wenn die Hauptseite ausfällt, richtig?
Ich mag es einfach, wenn die Dinge unabhängig sind. Die Vorstellung, dass 4-5 Instanzen alle mit etwas verbunden sind, das irgendwann ausfallen kann, stört mich.
Auch hier gilt: Vielleicht ist meine Perspektive darauf, wie eine Multisite funktioniert, falsch, aber nach meinem Verständnis scheint es für mich keine gute Lösung zu sein.
Im Moment sind meine Bedürfnisse:
Alle Communities aufbauen, die ich brauche
So wenig Geld wie möglich ausgeben, weil ich nicht weiß, ob diese Entscheidungen zum Aufbau dieser Communities langfristig gut sind oder nicht (ich war schon oft dort und habe mehr Geld für “Experimente” ausgegeben, als mir lieb ist).
Ich wusste nichts von diesem Tool, also danke fürs Teilen. Habe es als Lesezeichen gespeichert.
Ich muss jedoch sagen, dass wir nicht blindlings (sorry, ich musste es noch einmal tun haha) alles verwerfen sollten, was ChatGPT oder Claude sagen, auch wenn der Discourse AI-Bot sachkundiger ist, was ich glaube, dass er angesichts der vielen verfügbaren Inhalte zu diesem Thema ist. Ich benutze auch ChatGPT und Claude, weil manche Dinge manchmal nicht nur mit Discourse zusammenhängen und ich immer gerne ein bisschen mehr über andere Dinge lerne.
Trotzdem weiß ich Ihr Feedback und Ihre Zeit zu schätzen. Es hat mir schon sehr geholfen.
Soweit ich das beurteilen kann, zerdenken Sie Ihr Setup bis ins kleinste Detail.
Grundsätzlich sollten Sie nicht versuchen, die 1000 brillanten neuen Community-Ideen, die Sie haben, alle gleichzeitig umzusetzen, indem Sie so viele neue Discourse- (und damit auch andere Software-) Instanzen hochfahren.
Community-Aufbau ist ein iterativer Prozess und erfordert Fokus. Wenn Sie Ihren Fokus auf mehr als eine Community gleichzeitig aufteilen, werden Sie mehr auf dem Tisch haben, als Sie bewältigen können.
Meine Vorschläge waren nur Denkanstöße, wie ich bereits erwähnte, als ich diese Experimente durchführte, waren es nur ein paar Freunde, die Dinge taten, weil sie es konnten.
Es gibt einen (oder zwei) Gründe, warum dies keine gängigen Praktiken sind? Diese bringen einen erheblichen Wartungs- und Verwaltungsaufwand mit sich, der Ihnen später viele Kopfschmerzen und schlaflose Nächte bereiten wird, Sie wurden gewarnt.
Angesichts Ihrer Ziele würde ich meinen Standpunkt mit dieser Aussage bekräftigen: Was Sie zu erreichen versuchen, ist nicht unmöglich, aber heute ist nicht der Tag, um alles zu erreichen, was möglich ist. Konzentrieren Sie sich auf das, was Sie gerade zur Hand haben, bauen Sie Ihre erste Community auf, der Rest kann folgen, wenn die Zeit reif ist.
Was das Lernen durch Experimentieren angeht: Wenn Kostensenkung Ihr Hauptziel ist, dann ist Multisite der richtige Weg, mit allen Kompromissen, die damit verbunden sind.
Ich verstehe, was Sie meinen, und glauben Sie mir, wenn ich alle Communities aufbauen müsste, die ich für alles brauche, woran ich beteiligt bin, würden wir nicht über 4-5, sondern eher über 15 sprechen.
Ich konnte bei 3 landen, die wirklich wichtig erscheinen und jetzt aufgebaut werden sollten. Zu diesem Zeitpunkt benötigen alle 3 ihren eigenen Bereich, um den Benutzern einen Ort für Diskussionen über ihre Erfahrungen mit Produkten und Dienstleistungen zu bieten, die ich habe oder gerade entwickle.
Wie ich bereits sagte, fühlt sich ein Multisite-System, bei dem alle voneinander abhängen, für mich nicht richtig an, und ehrlich gesagt sind die Kopfschmerzen und schlaflosen Nächte, die Sie erwähnen, in diesem Fall (zumindest nach meiner Erfahrung in anderen Bereichen, in denen Dinge voneinander abhängig waren) in einer Multisite-Konfiguration wahrscheinlicher. Ich weiß nicht … es ist einer dieser Fälle, in denen mein Bauchgefühl sagt: „Tu es nicht“, und ich vertraue ihm. Vielleicht liege ich falsch und werde im Laufe der Zeit eines Besseren belehrt, aber ich vertraue zuerst meinem Bauchgefühl.
Auf jeden Fall nochmals vielen Dank für Ihre Zeit und Hilfe. Ich weiß es zu schätzen
Dieses Thema ist für mich sehr aktuell, da ich gerade dabei bin, mein eigenes Setup anzupassen, um Zeit und Geld zu sparen. Ich habe drei kleine private Websites, die alle sehr wenig Traffic haben, aber sie sind mir alle wichtig. Außerdem möchte ich in der Lage sein, weitere Websites für das Testen neuer Ideen hochzufahren. Daher denke ich, dass Multisite für mich interessant sein wird.
Allerdings habe ich gerade eine meiner Websites von DigitalOcean zu Hetzner umgezogen und war überrascht über die Kosteneinsparungen. Es sind nur 3,49 /Monat für das kleinste cx23-Angebot, was für eine einzelne kleine Website so ziemlich ideal ist. Bei DigitalOcean habe ich für eine ähnliche Konfiguration 15,60 bezahlt.
Nachdem ich dies und andere verwandte Themen gelesen habe, ist mein größtes Hindernis bei Multisite, dass ich für alle meine Websites den direkten E-Mail-Versand nutzen möchte, wobei der Domainname der Website als E-Mail-Domainname verwendet wird, damit er von den Mitgliedern der Website leicht erkannt und vertraut wird. Die Anweisungen für die Einrichtung scheinen nicht sehr einfach zu sein.
Im Moment komme ich also zu dem Schluss, dass es für mich am besten ist, bei eigenständigen Websites zu bleiben und sie alle zu Hetzner zu migrieren. Ich werde Geld sparen, aber nicht so viel Zeit, wenn man bedenkt, wie viel Zeit mit dem Einrichten von eigenständigen Websites vertrödelt wird.
Das können Sie tun, aber nur, wenn alle dieselben SMTP-Anmeldeinformationen verwenden.
Da Ihr neues Hetzner so viel billiger ist, werden Sie mit drei Websites immer noch besser dastehen als mit nur einer zum alten Preis.
Ich würde Multisite mit nur 1 GB RAM nicht empfehlen, und es ist mehr Aufwand, sie zu konfigurieren, obwohl die neue Umgebungsvariable für Hostnamen-Aliase eines der größten Probleme löst.
Der cx23 hat 4 GB RAM. Ich verlege meine anderen beiden Websites auf ihre separaten cx23-Server, mal sehen, wie sich das entwickelt, aber ich habe das Gefühl, dass alles in Ordnung sein wird.
Das verwirrt mich, da es bei mail-receiver nur um den Empfang von E-Mails geht und keine SMTP-Anmeldeinformationen erforderlich sind.
Reden Sie über eingehende oder ausgehende E-Mails? Hat nicht jede Website für ausgehende E-Mails ihre eigenen in app.yml konfigurierten SMTP-Anmeldeinformationen?
Nein. Der Mail-Empfänger ist separat. Wenn Sie Multisite verwenden, gibt es nur eine YML-Datei, und dort werden die SMTP-Sende-Anmeldeinformationen festgelegt. Wenn Sie den Mail-Empfänger verwenden, haben Sie ein anderes Problem, da Sie für jede Seite einen Mail-Empfänger benötigen (zumindest ist das die einzige Lösung, die ich gefunden habe).
Wenn etwas schiefgeht, alles löschen, zurück zu einer einzigen Installation pro Server. Alles gut 
