We’re so glad you’re here! Want to run your own community site? It’s easy to get started.
Bei einer Multisite-Installation können Sie nicht einzeln aktualisieren, noch können Sie verwendete Plugins segmentieren. All das wird durch die zentrale Multisite definiert. Einstellungen, Themes und Backups können jedoch separat erfolgen.
Im Allgemeinen benötigen Sie zudem einen Proxy davor, um SSL-Zertifikate zu verwalten.
3 „Gefällt mir“
Tatsächlich habe ich eine Möglichkeit gefunden, wie Let’s Encrypt Zertifikate für mehrere Domains ausstellen kann, ohne auf die primäre Domain umzuleiten. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
@AstonJ, hättest du Lust, meine Anleitung zu testen? Ich bin zu 90 % sicher, dass sie funktioniert, aber ich habe sie schon seit einigen Wochen nicht mehr getestet und bin nicht ganz sicher, ob die Anweisungen auch für jemanden außer mir funktionieren.
Wenn du möchtest, dass alle Sites die gleichen Plugins haben und gleichzeitig aktualisiert werden, ist Multisite eine hervorragende Lösung.
3 „Gefällt mir“
Ich könnte einfach alle ungenutzten Plugins über das ACP deaktivieren (und ich glaube, es gibt nur eines, das eines der Foren nicht benötigt). Ich vermute also, es kommt darauf an: Gibt es Vorteile, Multisite zu nutzen? Insbesondere in Bezug auf Leistung und/oder Stabilität?
Ich glaube, ich habe gelesen, dass @Blake einmal geschrieben hat, es sei verrückt, PG nicht in einem eigenen Container laufen zu lassen (ist das anders als Multisite?). Deshalb habe ich darüber nachgedacht, dies zu tun. Übrigens, bitte glaub mir nicht blindlings, was Blake gesagt hat – ich könnte es mir auch nur ausgedacht haben 
Ich verwende HAProxy, das unsere SSL-Zertifikate verwaltet, also sollte das meiner Meinung nach in Ordnung sein.
Ich denke, das hängt von den Vorteilen ab, Jay – wenn es nicht viel Unterschied gibt, macht es mir nichts aus, so weiterzumachen wie bisher, da die Einrichtung und Verwaltung mittlerweile relativ einfach ist. Wenn es jedoch erhebliche Vorteile gibt, Multisite zu nutzen, wäre ich definitiv interessiert 
Ein weiterer Vorteil ist, dass du nur eine weitere Kopie von Rails und Nginx ausführst, sodass der zusätzliche RAM-Bedarf deutlich geringer ist. Du hast zwar viel RAM, aber die Idee, bei dem zu bleiben, was bereits funktioniert, klingt zunehmend nach der besten Lösung.
2 „Gefällt mir“
Hallo. Ist es möglich, Benutzer von Multisites zu kombinieren, sodass ein Benutzer auf allen Multisites gleichzeitig registriert werden kann, indem er sich auf einer der Websites registriert (wie in Magento)? Oder eine Supervariante der Verwendung von Discourse, ähnlich wie bei der Föderation. Damit die Benachrichtigungen synchron funktionieren und der Benutzer von Website Nr. 1 Benachrichtigungen von Website Nr. 2 erhalten kann? Dasselbe gilt für den Chat.
Ich habe 4 Communities mit der gleichen großen Ausrichtung, aber unterschiedlichen Themen, und ich möchte, dass diese Communities eng miteinander integriert sind.
Sie können eine Website als Discourse Connect-Authentifizierungsserver einrichten und alle anderen dagegen authentifizieren lassen.
2 „Gefällt mir“
Ich versuche herauszufinden, ob ich ein Multi-Site-Setup, mehrere Container oder etwas anderes benötige.
Ich habe derzeit 3 unabhängige Communities, zwei davon sind ähnlich (beide über College-Sport, aber für zwei verschiedene Schulen) und die dritte über Kochen und Backen.
Ich möchte, dass diese alle auf demselben Server (wegen IP-Adressbeschränkungen durch meinen ISP) liegen, aber unter separaten URLs, so ähnlich wie hier:
foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking
team1.bar.com, das zu foo.bar.com/team1 weiterleitet, usw., oder zu separaten virtuellen Servern, wäre auch in Ordnung. (Ich weiß, dass Apache das kann, daher gehe ich davon aus, dass nginx das auch kann, entweder direkt oder mit einem Proxy-Server davor.)
Idealerweise würde foo.bar.com selbst als Gateway zu diesen unabhängigen Communities dienen und erklären, was sie sind und wie man sie erreicht. Einige Kategorien in jeder Community könnten öffentlich lesbar und für Web-Crawler zugänglich sein, damit sie in Websuchen erscheinen.
Ist dies ein Multi-Site-Setup oder ein Multi-Container-Setup oder etwas ganz anderes?
Gibt es bekannte Fallstricke beim Plugin-Design, wenn Multisite ausgeführt wird?
Es sieht so aus, als ob mein Chatbot kein Mulitsite unterstützt (also ein bekanntes Problem ist), aber ich möchte verstehen, warum: es funktioniert auf der Standardinstallation einwandfrei.
Insbesondere scheint es Probleme mit der Setup-Datenbankaufgabe und möglicherweise diesem Job zu geben.
1 „Gefällt mir“
Ich wollte ein Update zu meiner Situation geben.
Nach einiger Recherche habe ich beschlossen, dass ich ein Multisite-Setup (zu diesem Zeitpunkt ein Container) mit einer ‘externen’ Nginx-Site benötige, um das Setup zu erklären und Leute und Traffic auf die separaten Discourse-Sites zu leiten. Auf diese Weise könnte ich beide Seiten für den Lesezugriff (und Web-Crawler) öffnen, ohne dass die Leute von Liste 1 mit den Inhalten von Liste 2 umgehen müssen. Möglicherweise muss ich robots.txt bearbeiten, um die Web-Crawler zufriedenzustellen.
Die Beispiele für das Multisite-Setup waren lehrreich, aber ich konnte es nicht mit einem Unix-Socket zum Laufen bringen (Gateway-Fehler), also habe ich sie an einen anderen Port weitergeleitet und diesen Port im Container auf 443 umgeleitet.
In meiner app.yml-Datei habe ich die SSL-Vorlage aktiviert, aber nicht die letsencrypt-Vorlage.
Ich habe die Test-Site zum Laufen gebracht und suche nun nach möglichen Problemen, die auftreten könnten, wenn ich die Produktions-Site konvertiere, hoffentlich später in diesem oder im nächsten Monat.
Ich kümmere mich um das Zertifikatsproblem auf der Außenserverseite, bin aber auf das Problem ‘nicht sicher’ gestoßen, das ich behoben habe, indem ich HTTPS im Container erzwungen habe. Ich habe eine Aufgabe, die ich über Cron ausführen werde, um das neueste Zertifikat und den Schlüssel in das Verzeichnis /shared/ssl des Containers zu kopieren (als ssl.crt und ssl.key). Ich bin mir nicht sicher, ob ich einen Reload von Nginx im Container erzwingen muss, um sicherzustellen, dass ein neues Zertifikat geladen wird, wenn es sich ändert (ich glaube, im Juli).
Ich bin auf eine Discourse-Besonderheit gestoßen:
In der Containerdatei /etc/nginx/conf.d/discourse.conf befindet sich dieser Codefragment (Domainname geändert):
if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}
Dies führte dazu, dass site2.my.domain zu site1.my.domain umgeleitet wurde, daher musste ich es auskommentieren.
HINWEIS: Das Neuerstellen des Containers erfordert die Wiederholung dieser Bearbeitung. Gibt es eine Möglichkeit, dies zu vermeiden?
Und dies führte zu einer Browser-Besonderheit, da Firefox diese Umleitung als permanent gekennzeichnet hatte, sodass ich den Browser-Cache löschen musste. (Das hat mich viel zu lange gekostet, um es herauszufinden!)
Ich bin auf eine andere seltsame Sache gestoßen.
Auf meiner Test-Site war der Parameter zum Erzwingen von HTTPS für keine der beiden Seiten aktiviert. Auf meiner Produktions-Site ist dieser Parameter in der Einstellungsdatei nicht einmal vorhanden. Ich vermute, das hat etwas mit den Unterschieden zwischen den beiden Sites zu tun.