Discourse: Docker and Multiple Containers vs Multisite, Single Container

It is important to share a few technical facts to anyone interested or making a decision about going with:

• A single Discourse container with multiple sites per container, or
• Multiple containers for each instance.

If you use the "single container, multisite" approach, and you have 5 Discourse sites up and running (or even 10), when you rebuild your container, or have a problem with the container for any reason, you will have 5 (or 10) Discourse sites failing (or down) at the same time. This is because you have one container supporting all the "sites".

If you use the "multiple container" approach, and you have 5 Discourse sites up and running (or 10), when you rebuild a container for one of your sites, or have a problem with a site container for any reason, you will have 1 Discourse site failing (or down). This is because you have one container supporting one "site" (or two if you are running separate data and app containers, per site, like we do).

In addition, because how Docker overlays and shares all of the read-only layers for each container (when using the Discourse recommended Docker storage driver, overlay2) between containers; only a thin read-write overlay layer is unique per container (for log files, the cache, etc), using multiple containers does not take very much additional disk space due to how the OverlayFS works.

For more on this interesting topic of how the Docker overlay driver works (and shares libs between containers), kindly refer to:

Obviously, the choice is up to each sys admin which approach to take. Based on our analysis, we have chosen to always go with the multi-container approach; for the reasons outline above (and some reasons yet discussed).

HTH

The container way would be decoupling as much as you can.
So, containers per discourse instance/site.
Or any other app/service you are running using docker or kubernetes.

You can have a common postgres cluster running one database instance / user per discourse site, having one database container.

And another pg container to test upgrades, just by exporting the specific database linked to one site, import and create same user/password used by that site.

The DB is SPOF for all sites, option has its advantages and disadvantages, but i would go separation here as well.

Regards
Peasant

The "multisite" in one container a bit like in the old days when people try to build multiple LAMP forums using the same code base and a single database; and then prefixing the DB tables with a string which designates the "site".

This becomes unbearable to manage; and the DB becomes a major single point of failure; and it is really quite complicated to maintain.

Honestly, I have no idea why anyone would go the "multi-site" route, when the "multi-container" approach is so clean and easy.

I guess it is just a matter of "sys admin style" and I always like to go for "simple, reliable and easy to maintain".... versus "fancy, single-point-of-failure, and really a lot of work to maintain ".