Hacker News Re-Imagined

Show HN: Dockerfile Generator

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 points
  • 4 days ago

  • @deiu
  • Created a post

Show HN: Dockerfile Generator


@linkdd 4 days

Replying to @deiu 🎙

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.

Reply


About Us

site design / logo © 2022 Box Piper