Inside Docker's “FROM scratch”

A new sysadmin doesn't need to learn that custom way your hand-rolled deployment system handles dependencies, how to see what's supposed to be running on a box, etc. A security person who's wondering whether something is supposed to be listening on a port can at least see that it's something someone went to the trouble of exposing. That QA team or the person who inherited your maintenance coding can avoid learning a new way to ensure they have a clean CI build.

(That doesn't mean that Docker's always the right answer — maybe you've identified an area like networking where there's a reason not to use it — but in most cases the differences are below the threshold where it's worth caring)

There are plenty of ways to create reproducible minimal images (such as using the nix package manager to create the rootfs), but the official docker images don't use those techniques and the docker tooling and ecosystem actively fight against it.

Docker is clearly focused on usability / first-user-experience at the expense of reproducibility and immutability. They encourage the use of the 'latest' tag, they encourage the use of procedural network-heavy build steps, and they have made not attempt to promote or create alternative tooling which tackles reproducibility correctly.

Edit: I really should have read the article first. It uses Go binaries as the example. Good to know Haskell folks are also using it.

For example I created a cntlm base image (linked in another comment)

From there I can do

FROM my_base_image COPY whatever

and then add layers of services

first one is proxy

second one could be queue service (for example http://nsq.io)

then a message server, that just sends notifications

etc. etc. etc.

The same could be achieved downloading and configuring the static binaries, but Docker packaging, security and network separation makes evrything a little bit easier