Hacker News Reader

Comment by jimbokun | Hacker News Reader

That was the Docker manifesto.

> That was the Docker manifesto.

It essentially still is.

Unless the Dockerfiles are kept secret, any container can be replicated from the given Dockerfile. Barring extreme (distro/system/hardware)-level quirks, a Docker container should be able to run anywhere that Linux can.

A container can very rarely be reproduced by a dockerfile.

I imagine with a lot of discipline (no apt update, no “latest” tag, no internet access) you can make a reproducible docker file…. But it is far from normal.

Well sure, making a 100% reproducible build is hard - but Docker makes it easier, not harder. If 100% reproducible is the goal, what's easier than docker?

Tools that have been designed with reproducibility in mind. Like Guix.

Beware, I am definitely not claiming those are easy to use in general. Just that you can get to reproducibility using them more reliably and maybe easier than with docker.

> but Docker makes it easier, not harder

Incorrect. Step one of reproducibility is "disable unconstrained downloading from the internet". Docker does the opposite.

Presumably if your goal is a reproducible build you just wouldn't do any unconstrained downloading in the process of designing the dockerfile and building the image. Making a choice to use a tool poorly for you requirements isn't a problem with the tool.

The claim the parent was addressing was that Docker helps with reproducibility. It doesn't. Docker does nothing at all in this regard.

If you want a reproducible Docker image, you're on your own. For example, the most common problem is that many build scripts out in the wild download stuff willy nilly without verifying anything. I've seen NPM package post install scripts do the craziest things. Catching all of that is harder than most would give credit for at first glance, considering that tons of build scripts are written in Turing complete languages. Help from tooling is essential.

When you have to fight the tool to achieve reproducibility, not choosing to do so isn't "using a tool poorly." It's simply using the tool as is. Especially when the vast majority of Dockerfiles out there happily run something along the lines of `apt install foo`, again, without verifying anything.

Ok, so what tools are less work to create a reproducible build than using docker carefully?

The Nix package manager. It forces all inputs to a package be specified precisely. Files either have to come from the build recipe or have its hash verified. Builds are properly sandboxed and can't freely access the network. Dependencies are completely static and no "resolution" ever takes place. The tool catches sources of irreproducibility for you.

Vagrant creates reproducible VMs. Not quite the same thing of course.

https://developer.hashicorp.com/vagrant

Full reproducibility isn't easy, there is a cost to it.

However the payoff is rather significant so if you can temper that cost a bit and make it less inconvenient to achieve then you have a winning solution.

I have cooked this up based on Bazel, rules_oci and rules_distroless: https://github.com/josephglanville/images Specifically this file is a busybox based image with some utilities included from a Debian snapshot: https://github.com/josephglanville/images/blob/master/toolbo...

More difficult than Dockerfile? Sure. However better in pretty much every way otherwise including actual simplicity.

A Dockerfile is essentially a shell script with access to the outside world. It has unconstrained network access. It can access local hardware and filesystem if instructed to. However, it doesn't verify that whatever stuff it took from the outside remains the same across builds. Docker doesn't care if the same Dockerfile builds Apache httpd in one build and Nginx in another. It literally can't get more irreproducible than that.

But mysteriously, people say that Docker is reproducible because, uh, you can download gigabyte-sized binary blobs from the Docker registry. I wonder, what's not reproducible by that metric?

Docker images may be portable compared to binaries targeting traditional FHS distros. But it's not reproducible whatsoever.

People rarely mean 100% build reproducibility, but simply within a reasonable limit, Dockerfiles are mostly "run stable" and provide the same OS abstraction and process encapsulation.

You are mixing build time reproduction with run time ones.

Docker images (not files) help with the run time consistency .

Docker (files) barely scratch the surface of build reproducibility. Most applications depend on the distribution package manager ( apt, apk etc) and language package manager (npm, cargo, etc), both sets of them have various challenges in consistent dependency resolution.

In addition build steps might have ordering challenges RPC calls to remote services no longer running and so on.

Anyone trying to to build a docker image from 10 years back experiences this problem

You're right in the absolute form, but I've yet to see a Dockerfile where (with a little thinking and elbow grease) I couldn't "easily" port it or update it, even after years.

It's basically the best and easiest "I am documenting how it works now" thing without any arcane "works on my machine" quirks I have yet found.

So I'm still agreeing here that it's a very good approximation of this idea.

Real reproducability is miles better, but usually cannot be formulated in a ~20 line single file "recipe". (and before anyone mentions Nix.. no, there's so much inherent complexity involved, that doesn't count like "apt-get install docker && docker build ."

Reply on news.ycombinator.com