HN Explorer

Show HN: Dockerfile Generator (github.com)

5 points by deiu ↗ HN
While it's not hard to write a Dockerfile, I think it's hard to write a good one.

Every language has its own quirks, and every framework has a special way of building things.

I was looking for a collection of well-written and well-maintained Dockerfiles, but I couldn't find one.

Thus, I thought of creating one!

I realized it's not enough to have a simple Dockerfile. Sometimes you need other files for your build: nginx.conf, php.ini, my.cnf, etc.

I also realized that people have different preferences. In Node, some use NPM, some use YARN, some use PNPM. In PHP, some use Apache, some use FPM with Nginx.

So I build a set of "builders", Dockerfile generators. You define a form using JSON Schema, and then define a function "generate" that returns an array of files.

In the future, I can make a CLI tool that will generate prompts, similar to how the form is generated on the web.

For now, I only implemented a builder for Next.js based on their official Dockerfile example.

Source-Code: https://github.com/easypanel-io/builders

Playground: https://easypanel-builders.netlify.app/

---

1. Do you have any feedback for this project?

2. Can you link some good Dockerfiles that I should include?

5 comments

[ 4.4 ms ] story [ 27.5 ms ] thread
linkdd
I have 3 dockerfiles that I reuse for every project, adjusting only little things:

They are all multi-stage dockerfiles to benefit heavily from caching layers and avoid running needlessly intensive steps.

[1] - Elixir: https://gist.github.com/linkdd/0a8d6e2019586d07c6587e42946a7...

This one suppose there is a Phoenix webapp, but most of the time I don't, so I remove the asset related steps.

[2] - Python/Django: https://gist.github.com/linkdd/4aac2c2efc4a51af6ca4b05f395de...

This one uses poetry and poethepoet (link in gist's readme) and other common libs that I use in every django project.

[3] - NodeJS backend: https://gist.github.com/linkdd/2a19e51f6158e53e89ff525544ac3...

This one uses yarn, I adjust the config files I add to the first stage depending on the project (quasar, vue3, typescript, ...)

---

They all use the same principle:

  - copy the config files into an empty layer (context)
  - copy the source code into an empty layer (src)
  - copy the test suite into an empty layer (tests)
  - copy the context layer files into a base image stage, install the production dependencies
  - copy the previous stage, and install the dev dependencies
  - copy the context layer, the dev dependencies, and the source code into a base image stage, run the CI steps (linting, etc...)
  - copy the context layer, the dev dependencies, the source code and test suite into a base image, run the test suite
  - eventually build the source code if the language needs it
  - build a final artifact from the built code (or the source code), the context layer and the production dependencies
If the Docker build passes completely, then the whole CI pipeline has been validated and the final docker image is guaranteed to be valid (according to your CI at least).

This works very well, and when i don't touch the yarn.lock, or poetry.lock or mix.lock for weeks, it speeds up drastically the builds on my machine and on the CI/CD pipeline.

Also, it allows me to migrate from one CI/CD solution to another (Jenkins, Gitlab CI, Github Actions, ...) without any hassle, as long as I can run docker build.

deiu
Oh, that's really nice! What if we can standardize this process in some way?

We could have sh scripts for different phases: install-prod-deps.sh, install-dev-deps.sh, run-tests.sh, build.sh, etc.

Also, we could have a configuration schema where people define the base images, copy glob patterns, etc.

linkdd
> What if we can standardize this process in some way?

Surely, this would be useful as part of a platform similar to Heroku where you plug your git repository and it would fetch such scripts and generate the Docker image.

It could be developed as a standalone tool that you integrate in your `git push my-heroku` hook, but I would not use it outside of that use case. Nothing beats copy/paste + some edits :)

> Also, we could have a configuration schema where people define the base images, copy glob patterns, etc.

Yes, copying files from stage to stage is quite a pain at the moment, that is why I have such a Dockerfile for every language I use, the copy glob pattern has already been done for 99% of my use cases.

You need to understand well your toolchain to know what to copy. For example, I did not yet write such a Dockerfile for Rust or Go, where I just do the usual "build + copy binary" multistage. No caching of dependencies :(

deiu
That's my main challenge. You need to be an expert in a language/framework to be able to develop a good Dockerfile. Hopefully, I can get more contributors to join my efforts.

I will draft something and get back to you for feedback.

Btw, I'm building easypanel.io and this is one of my attempts to simplify building docker images. I currently support Cloud Native Buildpacks, but it's quite a black box and people have a hard time using them.