3 ms·

> First, the Dockerfile file format for declaratively describing a machine (operating system, installed packages, processes, etc). I have a hard time calling D

by bhawks 3y ago

> 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)

danielvaughn 3y ago
In my book, if the order of statements influenced the order operations, then it’s imperative. So I think Dockerfiles count.
sverhagen 3y ago
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>...
- sdf4j 3y ago
  add COPY to the list of keywords we rather ignore so we can call Dockerfiles declarative.
  - dharmab 3y ago
    And ADD (which you should almost never use instead of COPY because it does extra stuff you don't need)
- diarrhea 3y ago
  Abuse, how? What does not abusing it look like? Not using it is not an option either; it would make for very boring containers.
  - dharmab 3y ago
    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.
deleted 3y ago
[deleted]
Jka9rhnDJos 3y ago
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.
pydry 3y ago
There are no loops or conditionals.

by bhawks 3y ago

danielvaughn 3y ago

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

sverhagen 3y ago

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>...

sdf4j 3y ago
add COPY to the list of keywords we rather ignore so we can call Dockerfiles declarative.
- dharmab 3y ago
  And ADD (which you should almost never use instead of COPY because it does extra stuff you don't need)
diarrhea 3y ago
Abuse, how? What does not abusing it look like? Not using it is not an option either; it would make for very boring containers.
- dharmab 3y ago
  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.

deleted 3y ago

[deleted]

Jka9rhnDJos 3y ago

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.

pydry 3y ago

There are no loops or conditionals.