Hacker News Reader

Comment by bhawks | Hacker News Reader

> First, the Dockerfile file format for declaratively describing a machine (operating system, installed packages, processes, etc).

I have a hard time calling Dockerfile declarative when the RUN statement literally runs a sequence of user provided shell commands in a container. Is a shell script declarative or imperative?

It is structured and mostly results in an easy to understand set of instructions to create a container image. But it is a set of instructions and you can shoot yourself in the foot (especially with reproducibility)

View on HN

Which is funny because Moby split the Dockerfile format from Docker, so you no longer need the Dockerfile format to make Docker images. At the top of a “Dockerfile” is

    # syntax=docker/dockerfile:v1

Which is a Docker image that translates the declarative syntax into the commands sent to the low-level builder. That syntax is pointing to a Docker image name and tag (`docker/dockerfile:v1`) that Buildkit pulls down and feeds the passed commands into. Technically, that could be anything. If you wanted to put in the work, you could write a Buildkit frontend for Ansible or Chef and use that to configure the image.

So, on the list of “4 things Docker is”, they were wrong on the first one.

In my book, if the order of statements influenced the order operations, then it’s imperative. So I think Dockerfiles count.

There are no loops or conditionals.

RUN is the escape hatch that everybody (understandably) abused. And because we do, it's maybe the first thing you think of when thinking of a Dockerfile. But in the context of the other Dockerfile keywords I can probably live with calling it declarative. I'm a Java guy, I'd definitely call Maven declarative, but it surely has some escape hatches too. And what about <fill in your example>...

add COPY to the list of keywords we rather ignore so we can call Dockerfiles declarative.

And ADD (which you should almost never use instead of COPY because it does extra stuff you don't need)

Abuse, how? What does not abusing it look like? Not using it is not an option either; it would make for very boring containers.

With RUN you want to:

1. Be as reproducible as possible. e.g. if you're using RUN to download a file, check the hash to ensure that someone building the image in the future gets the same file. Lock your dependency versions wherever possible. Sometimes this is impractical, e.g. OS packages in most Linux distros expect other packages to be mostly up to date.

2. Separate RUN commands so that more frequently changed content is created later in the Dockerfile, to maximize caching.

Reply on news.ycombinator.com