Hi guys.
Something trivial I thought but I failed to find a clear answer, thus asking here.
With a web-only containers - how to make & use one image which such containers would/should share?
That surely must make sense - such “thin” discourse container with everything outside (particularly on poor man budget on XS vmses) each having it’s own docker image is… makes no sense in my mind, right?
I hope I’m missing some “obvious” doc/howto on such simple (& common/popular?) scenario?
many thanks.
Yes, you can use the single postgres for multiple Discourse sites, but unless you’re going to use multisite (see Multisite configuration with Docker), each needs its own redis.
You’d need to create another database, and configure the second web container to use that one instead o fth eone named Discourse.
Thanks for taking time, for trying, however… it’s not what I’m asking.
I’ll try again, pardon me if I fail… again
When I:
→ $ ./launcher bootstrap a.forum.xyz # or similar
then process creates:
-> $ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/a.forum.xyz latest d7a7b6509811 2 hours ago 4.19GB
and that happens with each & every launcher ran for a different/new forum.
So I end up with multiple image of the same discourse - is it only me & result should be different?
If not just me & that is desired & expected result, then that is - sure I am not devel and have no knowledge of the process(es) involved - rather really extremely wasteful (perhaps particularly with web-only container) - no?
What I was hoping for - when first tried discourse - what I expected was, pretty much what everything else, every other software which is dockerized does, namely - get that one image and run many containers off it. Is discourse not cap/able of doing that?
If you want to use the same container with different settings for different sites you can
./launcher start-cmd
To get the parameters to start it. You can change them for the other sites you want to run. You’ll still need a database and a redis for each.
It contains unique copies of your sites themes, which include JS, CSS and other types of assets.
Also the unique combination of your plugins and their dependencies.
It’s a long history, but Discourse and most of the tooling predates stuff like Docker compose.
We ship a fat container that contains the whole kitchen sink, and there are several trade-offs to that. As for one, the stateful container allows for features like our web based one-click updater.
Coming from a more modern approach to how containers are usually deployed today, it is indeed a big discrepancy. This is discussed at long in Can Discourse ship frequent Docker images that do not need to be bootstrapped? and is worth a read.
In the end, our current status quo works well for people who are only slightly tech-inclined, that can copy and paste commands in a SSH session and configure DNS, but aren’t masters of Linux containers.
And as for the Linux containers black-belts out there, we can tell then that they can take that bootstrapped image, ship it to a registry and re-use it on their favorite container orchestration software.
People between the two personas above tho, they feel the pain the most.
I did not find an explanation on how to use one Redis for multiple instances in that how-to, but this seems to work out of the box when multisite configuration is available?
Do I understand correctly ?
a) Multisite runs the same docker-image for multiple forums, using one redis and one postgres server.
b) Using one redis for multiple discourse instances (using the same image or not) is not possible, since without turning multisite on, no prefix will be added to the redis keys.
c) There is no other way to enforce a redis key prefix.
d) Enforcing different redis key prefixes for different discourse images would allow using one redis server.
e) General support for enforcing a general redis prefix would need several core changes.