Multisite vs. mehrere Container

Does anyone know the pros and cons of multisite vs multiple containers?

I currently have three Discourse instances as separate containers, and am thinking about converting two, maybe three more forums to Discourse - they’ll be on the same server (64GB RAM, running SSDs) so I’m wondering what might be the best way forward.

I’d prefer them to be as independent as possible, so each can be upgraded individually, backed up and restored individually, and issues with one should not affect another.

What do you suggest? Any pros and cons to look out for?

You won’t be able to upgrade individually with multisite, nor will you be able to segment plugins used. All of that is defined by the root multisite. Settings, themes, and backups can all happen separately, though.

Generally you’ll need a proxy in front to help with SSL certs, too.

3 „Gefällt mir“

Actually, I’ve worked out a way to get let’s encrypt to get certs for multiple domains and not redirect to the primary domain. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, would you be interested in testing my howto? I’m 90% sure that it works, but it was some weeks ago that I last tested and I’m not entirely sure that the instructions “work” for someone who’s not me.

If you want all the sites to have the same plugins and be upgraded all at the same time, multisite is great.

3 „Gefällt mir“

I could just switch off any unused plugins via the ACP (and I think there’s only one that one of the forums won’t need) so I guess it depends on are there any benefits to doing multisite? Specifically, performance and/or stability?

I think I read @Blake once post that it’s insane not to run PG in it’s own container (is that different to multisite?) hence why I’ve been thinking about doing this. Btw don’t quote me on what Blake said I could have well dreamt it :rofl:

I use HAProxy which deals with our SSL certs so I ‘think’ that may be ok.

I think it will depend on the benefits Jay - if there’s not much difference then I don’t mind carrying on as I have been as it’s become relatively easy to set-up and manage, but if there are some big advantages to going multisite I would definitely be interested :sunglasses:

The other advantage is that you’re running just one more copy of rails and nginx, so the additional RAM required is much less. You’ve got lots of RAM, though, so going with what works already is starting to sound like the best idea.

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.