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

dev
114

What I find particularly striking about this entire discussion is that you appear to have never read through discourse_docker.

Looking at this file, is it really that hard to figure out how to change exposed ports? In fact our line there looks exactly the same as the ports line in compose.

The whole narrative here is, “I want to do super advanced things with docker, I already know how to cope with docker compose, don’t make me learn something new”

99% of our free installers just spin up a digital ocean instance and run the setup. They do not need to learn anything.

They do not need to learn about docker compose or figure out how to install it.

They don’t even need to figure out how to install docker.

So you are here, making a lot of noise about how we are not catering right for the 1% of free installers who both want to do something advanced and do not want to learn anything new. So, I am not sure I want to be in the business of helping these people.

As I said many times, Discourse docker can deploy fine in a kubernates or what have you. You just need to understand.

  • We ship a “naked fat image”

  • We have a custom process that runs docker build on that image adding in specific information that is only relevant to you, like the specific plugins you run.

  • The same step compiles our assets (cause plugins may introduce new ones) and migrates the database

  • At the end of this bootstrap you have an real docker image you can deploy anywhere that is capable of running Discourse.

The whole pain point I am trying to address here has almost nothing to do with particular tech.

Pain points I am interested in solving long term are

  • Faster bootstrap
  • Easier and more frequent base image updates
  • More consistent update process from web upgrader vs a full rebuild
  • Probably move default setup to 2 containers vs 1 container
9 Likes