Docker Is Four Things

These days you can even build, and deploy a debuggable image from an IDE easily so you don't need to bridge the network.

Not sure I follow? Docker Compose in no way trys to replace a Dockerfile or docker images - every container you specify in one still has the exact same Dockerfile, compose can't replace this.

I also think Compose is a fantastic tool, but to start comparing to Dockerfiles and Kubernetes suggests not understanding what Compose is for.

The thing Compose does better than a bunch of loose dockerfiles especially is document in a runnable fashion the relationships between key containers in a given stack. This information alone can tell you a lot about how you would deploy in more complex environments, as well as giving you something you can usually deploy instantly with a docker compose up for local development work.

Without compose, you typically have to rely on loose documentation much more, which may be stale or outdated and obviously isn't "runnable" like docker compose is. I also find it far easier to understand what volumes are critical for persistence when its coded in the Compose yaml, vs a bunch of -v args in the documentation for a docker run command launch.

Setting up an N-node Cassandra cluster: https://docs.kurtosis.com/how-to-parameterize-cassandra#inst...

Idempotent runs documentation: https://docs.kurtosis.com/concepts-reference/idempotent-runs

That's why I said "personal projects".

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.

Edit: perhaps it is idiomatic somewhere in the world to say "builds X to Y", but not in the U.S., in my experience. Could be similar to British "different to" as compared to American "different than" or "different from".

As a trivial example, network access for RUN should be opt-in, not opt-out. The fact that the easiest ways to pull data in involve things like RUN wget is a design error.

A much better approach would be to have packages that install with as little script involvement as possible. Most Linux images are put together using rpm or deb packages and, other than pre/post-install scripts (which are not usually particularly necessary), package installation is fundamentally reproducible and does not require running the image. A good image building system IMO would mostly look more like:

INSTALLPACKAGES foo bar baz

And dependencies would get solved and packages installed, reproducibly.

If it corrupts your OS and it corrupts your files, that sucks, but it's not bricking unless it's impossible to install a working operating system.

A pedant might similarly go the other way and say "C isn't just a compiled language, because personally I use the Ch C interpreter".

I don't think it's a good enough reason to avoid reasonable simplifications in technical writing because "Well actually, advanced users have an edge case where that assumption doesn't strictly hold....". The only way for anyone to get a reasonable understanding of anything complex is by starting with small simplifications and generalizations.

But, yeah, if the article wanted to clarify instead of obscuring the functionality of Docker, the one we know and use, then saying that it runs the Dockerfile is misleading. I mean, it does run it to builds an image, that's how it build the image, but then readers need an explanation for why there are images and why do they need them, if all they do is running Dockerfiles, and that's where the "explanation" becomes worthless.

Acutally, come to think of it, since `RUN` may depend on any other Dockerfile statement (even `EXPOSE` might make a difference in code), does this mean that even a single imperative statement that is introduced in some language, makes the language imperative?

Dockerfile is intentionally bare-bones. It just gives you RUN straight up, no scary hidden option, but it’s up to you how to use it. If you want to write imperative, you can. If you don’t write imperative, pin everything to a hash, shell out only to Dhall and Prolog, it can get very declarative…

…at a cost. The fact that people do not tend to go this route means equally that 1) they are lazy, and 2) using RUN this way is pragmatic.

The alternative is to draw a clear line where there is none.

> One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly.

By that logic you can call every Nix program “imperative”. They are sequences of strings, the order of which matters. The horror!

A Docker image is a stack of layers. Every layer points to a preceding layer. It’s not a huge leap from that structure to a fairly elegant sugar of a string array, where each string is a declaration that applies to preceding layer thus describing the next one. I don’t see anything fundamentally imperative about it; it can be used in imperative ways, but anything can.

> But from the perspective of 'each line of code declares a new program', then we consider the code snippet a declaration of a program.

The critical difference is that each line in a Dockerfile yields (declares) a filesystem state which can be referenced and recreated. In contrast, in your example, I have no way to say "give me a snapshot of the system between the third and fourth instructions".

Dockerfiles have all sorts of rules and restrictions that make these semantics possible. You cannot create loops; there is nothing like a "function", at least within the context of one Dockerfile.

> One of the things which makes Dockerfiles imperative is the sequence of Dockerfile commands is significant; if you swap the order of a COPY, RUN to a RUN, COPY, the result changes significantly.

I reject this line of reasoning, simply because decalative languages are indeed order-dependent:

    let y = f(g(x))

    let x = g(f(x))

    FROM x AS y
    RUN g
    RUN f
   

    FROM x AS y
    RUN f
    RUN g

I find Docker an interesting example of a fundamentally elegant approach that, possibly to facilitate commercialisation, was documented in a way that, instead of imposing any particular culture (such as, say, Nix or Haskell), strongly aligned with the preexisting culture of operations and system administration—the resulting ease of adoption and popularity (and, I assume, broadly deserved financial well-being of the original creators), however, could not come without a variety footguns along the lines of which you have described.

A Dockerfile provides no guarantees that it will succeed, is what I was getting at- which is why people download Docker images to begin with, because the build product is guaranteed to work, since it's immutable at that point.

An image is an easy way to deliver an entire software package. A container is the place where your image will run.