Convert the Dockerfiles into just one and pass only the database driver as argument

[MindTooth]

Hi,

I've been toying with rewriting the whole Dockerfile setup using just one file instead of four today.

Some of the differences and ideas:

• DATABASE_URL
• Database driver for both regular and dev
• Environment (private/production)
• Configure Bundler for environment
• RAILS_SERVE_STATIC_FILES
• Sensible way of passing different drivers to e.g. docker build --build-arg DRIVER=sqlite.

My current problem is the bundler configuration. Current way of solving this is private = without production, vice versa. If this could be solved somehow into private = private, production = production. It would solve a lot. Also, how to change the properties inside the build for picking the correct package, etc.

@pglombardo is this changes that you would accept? I have a fully working copy locally, only the issues above that remains.

[pglombardo]

Apologies - this was left in draft 🤦 for a week

Hi @MindTooth - I'm all for the changes. I think a possible move would be to instead of have pwpush-ephemeral, pwpush-mysql and pwpush-postgres that we have just one slightly larger pwpush container that has support for all 3 backend types.

If we went that route, then the private environment would disappear and we would only use production.

I need to give this some thought though. With this change and your Dockerfile improvements I think it would be a big improvement for simplicity and speed.

[MindTooth]

I’m toying with it more this weekend. 😅

Quick question, is even node_modules used? I’m trying to understand the precompile step, but find only reference to vendor.

[pglombardo]

Hi @MindTooth -

node_modules is used. The front end uses a bunch of npm packages. They are installed with yarn install and the Javascript bundle is built using esbuild (this last part isn't and doesn't need to be part of the build process though). See package.json for the commands that I run in dev.

When I update the front end with new javascript, I build the javascript into app/assets/javascripts/application.js which is then checked into git. app/assets/javascripts/application.js references node_modules.

As for precompile - that rebuilds and fingerprints images, logos and CSS.

[pglombardo]

BTW not sure if it's helpful but Rails works off of the DATABASE_URL environment variable. Based on the prefix, it will try and look up the DB adapter (sqlite3://, postgresql://, mysql://, mysql2://).

If the adapter isn't found, error and container dies. If we bundle all three...

Removing private might need some careful attention though...

[MindTooth]

So, from my understanding, we have two processes:

• Development
• Production

Development

1. You update static files manually
2. Do stuff locally

Semi-production

1. You manually update app/assets from npm packages
2. Push these changes as static

Production

1. Needs only bundle install to update Gems
2. Does not need yarn install because they are already bundles as part of semi-prod

---

So what it boils down to, what are the minimal steps required to create a production ready container. Is it steps that can change in a new procedure, etc. Cause now it's many steps, but can they be improved.

I'm still learning the Rails/Rake and how stuff is connected. So I don't have all answers yet. 🙃

[pglombardo]

That's mostly it. There's a lot of knowledge in the existing Dockerfiles since they have been built up over the years. Dependent OS packages etc.. We should try not to lose any of that.

This is the project that is proposed for the next minor release of Rails: a Dockerfile generator specifically for Rails. There may be some valuable info there but I doubt there will be things like multistage builds and cached layers...

Apologies that I don't know more.

Much of the Dockerfile improvements were contributed by @sirux88 and @sfarosu originally.

If either of you have input to support @MindTooth - it would be much appreciated.

We are aiming to move to a single container image with all DB drivers bundled, multistage and with cached layers for quicker builds. Not all required immediately of course. Nothing wrong with incremental improvements.

@MindTooth has been a big help in adding Docker tag support and build caching recently.

[sirux88]

Well I think there will be some topics to be taken into respect:

1. If there's only a single docker container users need the option to configure which database backend to use. e.g.: DBBACKEND="sqlite" or DBBACKEND="mariadb",... and it will be started by using default DATABASE_URL string (which can be overwritten aswell right now) within entrypoint.sh
2. The ruby/rails part needs to support all database backends in production (we had some problems with sqlite being neccessary private within some of my latest improvements)
3. The container will grow in size but I think this might be ok since we shrinked them a lot
4. In my eyes this is the most important one and hasn't to do with coding: you need to inform the users about this mayor change and how to migrate

I'll do some tests and maybe create a draft for this

[MindTooth]

Nice.

Created a basic start here: https://gist.github.com/MindTooth/3b7382722ff83ba119ed37ff10cecc2d

Seeing as things take ages compile, I feel that one of the priorities should also be how to build stuff efficiently and using the tools provided by the dockfile spec.

[sirux88]

@MindTooth: What you did seems like abstracting the current dockerfile to reuse them for multiple database backends. This would result in multiple images. But @pglombardo wrote that the goal is to get one image for all database backends.

[sirux88]

I startet off the PR #1369 as a draft for this discussion. Maybe both of you could take a look at it.

@MindTooth: Please don't feel blamed. I didn't want to take over your job. But while testing I realized that it won't be that hard to create an universal image.

[MindTooth]

Not at all. My initial work was based on three images and converting existing setup.

Having just one image is even better. And I would have gone down the same route. 😊

I’ll leave some feedback on your pull request later. I see improvements that can be made.

Good job. 👍🏻

[pglombardo]

Yeah I kind of threw the container unification at @MindTooth last minute on top of everything else. Apologies.