Hacker News Reader

Comment by viraptor | Hacker News Reader

Those 120 lines are not exactly representative. For example if I was writing this for a single service, I wouldn't bother making a new module and would inline it instead. Then, you've got many lines which would map 1:1 to an inlined systemd service description, so you're not getting rid of those whatever the system you choose. There's also a fancy way to declare multiple systems with an override.

This example is a "let's do a trivial thing the way you'd do a big serious thing". If you wanted to treat it as a one-off, I'm sure you could cut it down to 40 lines or so.

View on HN

So I can write a Dockerfile using 17 verbs (13, actually), and it's understandable language to a 4th grader... or I can write 120 lines of complete abstract nix code that means nothing to someone doing software for 20 years.

Hrmmmm...this is such a TOUGH decision.

I've used this app for like four different talks over the years, I could clean it up, but then I break code samples in my talks.

I would like to mention one pet peeve of mine wrt docker...

cramming everything into one RUN line to save space in a layer.

I really wish instead of:

  RUN foo && \
      bar && \
      bletch

You could do:

  LAYER
  RUN foo
  RUN bar
  RUN bletch
  LAYER

or something similar.

maybe even during development you could do:

  docker build --ignore-layer .

then at the end:

  docker build .

Cramming things into one layer can save gigabytes in size. Even if it saves a 100MB, it adds up between multiple CI runs and in deployment latencies.

Docker should address it one day, but until then, we just have to do it in real world scenarios.

Parent comment agrees with you, is just asking for more ergonomic syntax

I get it, just providing more context. Should've phrased it nicer.

An alternative solution... for some definition of the term... is to write a "naive" Dockerfile like

    RUN foo
    RUN bar
    RUN baz

and then just build it with something like... I think kaniko did this last I looked?... that smashes the whole thing into a single layer. Obviously that has other tradeoffs (no reuse of layers) but depending on your usecase it can be a good trade to make (why yes, I did cut my teeth in an environment where very few images shared a base layer, why do you ask?).

Docker itself can do that now too.

I think granular layering is still useful.

It's not always best or most efficient to squash everything into one giant layer.

Heredocs (described in the docs[1] under "shell form") was introduced 3 years ago[1]. The flag '--squash' has been in podman for quite a while[2]. It might be time for you to upgrade your tooling.

[0]: https://docs.docker.com/reference/dockerfile/#shell-form

[1]: https://www.docker.com/blog/introduction-to-heredocs-in-dock...

[2]: https://docs.podman.io/en/latest/markdown/podman-build.1.htm...

I addressed the 120 lines already and they're not completely abstract. You seem uncomfortable with an alternative approach and that's fine. But this is not a good intentions argument.

Dockerfile’s are absolutely not something a 4th grader would understand. It looks familiar to you, because you have already learnt it. They are definitely not trivial to understand before that, and the same is also true for Nix.

Reply on news.ycombinator.com