Canonical images

[oliverbarnes]

Following up on an old issue @andreslucena pointed me to, still relevant to current discussions to improve decidim/docker: decidim/decidim#5405

Right now the image up on docker hub, generated from the main Dockerfile, is actually a Decidim app generator, so one can use it the following way:

docker run -it decidim/decidim my-new-decidim-app

I've updated #50 so the image published to the Github registry is descriptive of that: decidim-generator

Likewise, following the current decidim/docker Dockerfiles organization (with Dockerfile, Dockerfile-dev, Dockerfile-test and Dockerfile-deploy), it seems like we could have decidim-dev and decidim-ci images as well, and then, in principle, have Dockerfile-deploy produce an image for a runnable app, a decidim image where the name matches the expectation from a dev user.

This last one is tricky, of course - it can have many permutations based on which modules a given implementation will choose to use.

It's only viable for Decidim core to maintain a couple to a few of canonical app images supporting very common use cases and where it's clear it'll lower the bar for adoption of Decidim.

A low hanging fruit might be a basic app for new devs just kicking the tires of Decidim. I can think of a few possible names for it: decidim-basic, decidim-sandbox, decidim-minimal or even decidim-getting-started. I imagine it could include pre-seeded core features that listed on https://decidim.org/features/

A Dockerfile for this canonical basic image should also be easily forked for each Decidim implementor to add their own mix of features, if they choose to use dockerized Decidim for deployment.

Adding gem configuration to it might be useful to accomplish this, so it's transparent what gems are being included, and so the Dockerfile is a clear template and easily editable.

Update

So far there seems to be agreement around a decidim-generator image and a basic decidim app image, and then have a configurable build where modules can be defined over env vars, as @microstudi suggested.

[microstudi]

Having different "default" images would be nice, but i guess just one would sufice if we adopt a strategy like Etherpad for instance:
https://github.com/ether/etherpad-lite/blob/develop/doc/docker.md

They have a single image but provide a script that makes super easy to build a new image with custom plugins in it:

We could add a script to do the same with the Decidim modules, I'd even allow external plugins to be processed

[oliverbarnes]

I like it, it's clear and simple to maintain 👌 Great reference.

What's your take on the decidim-dev (for Dockerfile-dev) and decidim-ci (Dockerfile-test) images?

[microstudi]

well, there's been recently a new discussion about the need of having 2 separates environments for testing o development, they could be the same dev app.

I would have just one for local development, and I thing that a simple docker-compose.yml should be enough for that (simply fix what's broken on the current). I don't thing there's a real need for the "ci" image to be honest.

For the production one, I would try to delegate as much as possible to ENV variables (for instance, gecooder, etherpad, etc). This would require to modify some initializes (you need to modify them if you want some of these features). The merely presence or not of an env var should be enough to activate the extra service.

[oliverbarnes]

thanks, that all makes sense. Do you feel decidim/decidim's docker-compose.yml should be moved to decidim/docker?

And it'd be great to get your feedback on #50 as well, when you get a chance

[microstudi]

Sure, expect my feedback next week though 😅

I think the docker-compose.yml should stay there, it is a quick way to start developing. Documentation about how to use it could be improved.

[oliverbarnes]

No rush! 😄

Sounds good about docker-compose.yml, that makes sense.

[andreslucena]

For the production one, I would try to delegate as much as possible to ENV variables (for instance, gecooder, etherpad, etc). This would require to modify some initializes (you need to modify them if you want some of these features). The merely presence or not of an env var should be enough to activate the extra service.

+1000

A couple of weeks ago I was improving the docs and just by explaining how to configure Decidim at a high level, it was really clear that this is important to have less friction in the configuration process. Here's a preview of my changes for these sections of the documentation (Configure), you'll see that we have:

• config/database.yml
• config/secrets.yml
• Environment Variables
• Initializer

I think we should honor the 12Factor App's config guidelines and move all the configuration to ENV vars. For instance, now for enabling omniauth facebook configuration, it's weird as you have to change the config/secrets.yml file first (with the commit, release, etc), and that doesn't have any sense.

[andreslucena]

Related to this topic, as discussed offline with @oliverbarnes, I really enjoyed the installation process of Discourse. I think is the best experience that I had installing a Ruby on Rails application. There are some things to note though:

1. It's the final result of a probably years-long effort, so it's really mature.
2. It's an application (and Decidim is a framework). For instance HTML/CSS/plugins are all added in their UI.

Another good resource for studying how others resolve the installation issue is Open Source Rails, although I think is not maintained now and we also have the same issue of "app vs framework"

[oliverbarnes]

@andreslucena:

I think we should honor the 12Factor App's config guidelines and move all the configuration to ENV vars. For instance, now for enabling omniauth facebook configuration, it's weird as you have to change the config/secrets.yml file first (with the commit, release, etc), and that doesn't have any sense.

Agree - I've created an issue on decidim/decidim to get some feedback on it: decidim/decidim#6918

Related to this topic, as discussed offline with @oliverbarnes, I really enjoyed the installation process of Discourse. I think is the best experience that I had installing a Ruby on Rails application. There are some things to note though:

Agree a configurable installation script would be very nice. But as mentioned on the call, I think each of the docker images and builds we support ought to be good to use independently of a specific script or a given docker-compose file, so different workflows can be built on top of them. Really building blocks flexible enough for dev and deployment flows we haven't predicted.

And the installation script should be extracted from a common usage. Like you said about Discourse's launcher, it evolved from real experience and solving pain points they had.

There might even be room for different installation scripts. From a quick look at Discourse's seems to be geared towards cloud VMs. Heroku would be something different, as would dedicated or even shared servers.

To keep things as decoupled as possible, it might be interesting to have a separate decidim/deployment repo for deployment resources such as scripts, kubernetes manifests and helm charts, and docs (that could be imported into docs.decidim.org). What do you think?