Multisite vs multiple containers

Installation
1

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?

2

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 Likes
3

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 Likes
4

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:

5

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 Likes
6

Hi. Is it possible to combine users from a multisite so that a user can be registered on all multisites at the same time by registering on one of the sites (as in magento). Or a supervariant of using discourse, similar to federation. So that the alerts work synchronously and the user of site number 1 can receive alerts from site number 2? The same is true for the chat.
I have 4 communities of the same big direction, but different topics, and I would like these communities to be closely integrated with each other

7

You can make one site be the discourse connect authentication server and have all the rest authenticate against it.

2 Likes
8

I’m trying to figure out if I need a multi-site setup, multiple containers or something else.

I currently have 3 independent communities, two of them similar (both about college sports but for two separate schools) and the third about cooking and baking.

I’d like these to all be on the same server (because of IP address limitations by my ISP), but at separate URLS, sort of like this:

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

team1.bar.com redirecting to foo.bar.com/team1, etc, or to separate virtual servers, would be OK, too. (I know Apache can do that, so I assume nginx can as well, either directly or with a proxy server in front.)

Ideally foo.bar.com itself would serve as a gateway to these independent communities, explaining what they are and how to reach them. Some categories in each community might be publicly readable and accessible by web crawlers so they show up in web searches.

Is this a multi-site setup or a multi-container setup, or something else entirely?

9

Are there any known plugin design gotchas when running Multisite?

It looks as though my Chatbot doesn’t support Mulitsite (so is a known issue), but I’d like to understand why?: it is working fine on the standard install.

Specifically, it seems like there are problems with the setup db task and potentially this job.

1 Like
10

Thought I would give an update on my situation.

After some study, I decided I needed a multisite setup (one container at this point) with an ‘outside’ nginx site to explain the setup and direct people and traffic to the separate discourse sites. That way I could make both sites open for read-only access (and web crawlers) without the folks on list1 having to deal with the content from list2. I may have to fiddle with robots.txt to make the web crawlers happy.

The multisite setup examples were instructive, but I could not get it to work with a unix socket (gateway error), so I wound up forwarding them to another port and redirecting that port to 443 inside the container.

In my app.yml file I enabled the SSL template but not the letsencrypt one.

I did get the testbed site working, now I’m looking for any issues that might arise when I convert the production site, hopefully later this month or next.

I’m taking care of the certificate issue on the outside server side, but I ran into the ‘not secure’ issue that I fixed by requiring https in the container. I have a task that I will run via cron to copy the latest certificate and key to the container’s /shared/ssl directory (as ssl.crt and ssl.key). Not sure if I will need to force a reload of nginx inside the container to make sure a new certificate is loaded when it changes (in July, I think).

I did run into one discourse gotcha:

In the container /etc/nginx/conf.d/discourse.conf file there is this code fragment (domain name changed):

if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}

This was causing site2.my.domain to be redirected to site1.my.domain, so I had to comment it out.

NOTE: Rebuilding the container requires redoing this edit, is there a way to avoid that?

And this led to a browser gotcha, because now firefox had flagged that redirect as permanent, so I had to delete the browser cache. (That took me far too long to figure out!)

I did come up with one other strange thing.

On my testbed site, the parameter to require https was not checked for either site. On my production site that parameter isn’t even present in the settings file. I’m guessing that has something to do with differences between the two sites.