Can Discourse ship frequent Docker images that do not need to be bootstrapped?

[featheredtoast (Jeff Wong)]

@wojtek

discourse could provide such pre-build image

That was a note for why the compose sample I posted wasn’t using the generic PG image.

[wojtek]

@merefield

This “admin upgrade interface” is a plugin (called “docker manager”). You don’t need to include it if you have another way of doing online updates.

Hmm… but wouldn’t you say this makes other ways more complex?

@featheredtoast

That was a note for why the compose sample I posted wasn’t using the generic PG image.

got it!

[merefield (Robert)]

@wojtek

Hmm… but wouldn’t you say this makes other ways more complex?

As a docker guru this should all be very easy for you?

[wojtek]

@merefield

As a docker guru this should all be very easy for you?

As I’m trying to explain for the past couple of days, with the current provided solution it makes it everything but easy

tl,dr;
Simple Discourse image (akin to bitnami one) with bunch of env vars to configure basic stuff (like access to redis, database) would be more than enough but for some reason this is a complete no-go…

[featheredtoast (Jeff Wong)]

@wojtek

Simple Discourse image

I’m sharing proof of concepts here to do exactly that.

@wojtek

How those are “build” in the context of Ruby

For a simple plugin sure, but we cannot assume a plugin is going to look a certain way - some plugins need additional setup, extra gems to install, or extra gem dependencies or external programs requiring an apt-get install. That should get baked into a custom image.

It’d be great to see this done, but it is non trivial.

---

re: Web updating, Discourse operators are also not expected to know CLI or docker at all.

[pfaffman (Jay Pfaffman)]

@wojtek

Simple Discourse image (akin to bitnami one) with bunch of env vars to configure basic stuff (like access to redis, database) would be more than enough but for some reason this is a complete no-go…

You just need to build your own image with launcher (which you can get github actions to do), push it to a repo, and start up with the ENV variables. You still need to migrate the database, precompile assets, and push them to S3. You can migrate the database and skip_post_deployment_migrations so that the old container can keep working until the new one is up and running, and then shut it down and run the rest of the migrations. But that’s way too complicated for someone who doesn’t know a lot more about Discourse than I think you want to know. And there are many, many things that can go wrong, which is why the current solution, which is horrible for all of the reasons you outline, is the best solution for thousands of people who don’t know what bash is.

For the most part, you only ever need to ./launcher rebuild app, except once every couple of years when you need to upgrade the database, so you have to do that twice. You just can’t get that level of simplicity with docker-compose. There’s a chance that if docker-compose were usable when they started, they could have it instead of having to make their own, but that’s not the way things worked out.

If you want to use the bitnami image, you can, but you can’t get much help with it here. I bet it works for lots of people too.

[wojtek]

@featheredtoast

For a simple plugin sure, but we cannot assume a plugin is going to look a certain way - some plugins need additional setup, extra gems to install, or extra gem dependencies or external programs requiring an apt-get install. That should get baked into a custom image.

hmm… for a language/environment that should be universal and platform independent, relying on underlying OS package manager seems quite odd…

@featheredtoast

re: Web updating, Discourse operators are also not expected to know CLI or docker at all.

This is what referred to previously, that Discourse seems to be quite firmly set in the “old” way of managing PHP software/forums

@pfaffman

But that’s way too complicated for someone who doesn’t know a lot more about Discourse than I think you want to know. And there are many, many things that can go wrong, which is why the current solution, which is horrible for all of the reasons you outline, is the best solution for thousands of people who don’t know what bash is.

For the most part, you only ever need to ./launcher rebuild app, except once every couple of years when you need to upgrade the database, so you have to do that twice. You just can’t get that level of simplicity with docker-compose. There’s a chance that if docker-compose were usable when they started, they could have it instead of having to make their own, but that’s not the way things worked out.

So, to sum up the whole discussion (and possibly put that in the first message to avoid going over it ad nauseum ):

1. Discourse is tailored and focused on “regular folks” and the whole setup is geared towards catering to their needs
2. Given how Ruby (enviroment) is kinda weird and (1) it’s virtually impossible to provide generic enough official docker images in official Discourse repository

correct?

[RGJ (Richard - Communiteq)]

I would say it a little differently

@wojtek

Discourse standard setup (launcher) is tailored and focused on “regular folks” and it is geared towards catering to their needs

[wojtek]

@RGJ

I would say it a little differently

Given there is no official image offering (by default) other way to setup Discourse than the luncher, which makes the launcher the default and basically only (recommended) way to setup Discourse, one could argue that the original statement is still valid

But those are just semantics.

At any rate - the topic is:

Can Discourse ship frequent Docker images that do not need to be bootstrapped

From the whole discussion it seems that: “No, Discourse can not/don’t want to ship frequent Docker images that do not need to be bootstrapped”, q.e.d.

Hence suggestion to add a comment right at the top, that such image will not be provided would save A LOT of hassle

[sam (Sam Saffron)]

@wojtek

From the whole discussion it seems that: “No, Discourse can not/don’t want to ship frequent Docker images that do not need to be bootstrapped”, q.e.d.

This is an incorrect assumption

We have not prioritized shipping an official image with a bundle of specific plugins yet

it is work we are considering, we have plenty ideas of how to do this, it simply has not been a company priority

[wojtek]

@sam

We have not prioritized shipping an official image with a bundle of specific plugins yet

it is work we are considering, we have plenty ideas of how to do this, it simply has not been a company priority

translation from a person working on another project: “it may happen in the future, but it may not… given it’s not a priority / it’s not on a roadmap the chances for it happening are slim to none”

Though, on a more serious note - such basic setup with bundled sensible set of plugins would be super cool!

Thanks for the input! <3

[justinm]

Fyi - I’ve set up a way for myself to build a Discourse image on a devbox and deploy that to a server in a way that eliminates the requirement to use the launcher script.
More discussion about that here in a pull request I created.

I set this up in a way that makes it fully compatible with Discourse’s official docker setup, so you don’t have to worry about this solution going out-of-support or breaking.
The TLDR on how this works is I made the Docker image responsible for executing bootstrap commands upon startup (instead of the launcher script).

[wojtek]

Cool approach.

Also: interesting launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)!