AxisOps Harbour
Labs

Insights

Docker 1.0, and what we actually adopted

Docker 1.0 was announced at DockerCon on 9 June 2014 (LWN). The reaction was immediate. The useful question for a lab is narrower: what is actually new?

Not the isolation. Control groups were merged in Linux 2.6.24, January 2008 (kernel.org). Namespaces arrived incrementally over roughly a decade, with the user namespace the last to be completed, in 3.8 in February 2013 (LWN). LXC has been using both since 2008 (LKML). Everything Docker 1.0 isolates with, the kernel already did.

What is new

Three things, and none of them a kernel feature:

  • A layered image format. Copy-on-write filesystem layers, so a base layer is fetched once and then shared.
  • A registry. docker pull against a default public index. This is the one that will matter most and gets discussed least.
  • A one-line build description. A Dockerfile is a worse build system than almost any build system you could name. It is also one anybody can write in five minutes, which is why it is winning.

That is a distribution story, not an isolation story.

Why the distinction matters

Because what is getting adopted at scale is weaker than what it replaces, and the reason is ergonomics.

A VM gives you a hypervisor boundary. A container gives you a kernel-shared boundary: one kernel, with the guest separated by namespaces, cgroups and whatever the seccomp and capabilities posture happens to be that week. Those are real mechanisms. But a kernel vulnerability is a shared-fate event across every container on the host in a way it simply isn't across VMs. Flats with a party wall against houses on separate plots; both are homes, and only one of them lets you hear next door's plumbing.

The industry is making that trade knowingly at the top and largely unknowingly in the middle. Today the default docker run is root in the container, with no seccomp filtering and no user namespace remapping at all. Both get talked about, and neither has shipped.

Here at AxisOps we will take the bet that the packaging problem is the one that was worth solving, and that it is now largely solved. Nobody is going to argue about tarballs again.

Which leaves the isolation bill outstanding, and it will be paid. The shape we expect: something that puts a real boundary back underneath the container without giving up docker run. A thinner hypervisor, a syscall interposition layer, a kernel that can be convinced to lie to a process more thoroughly than namespaces currently manage. We do not know which of those wins and we would not bet on one. We will bet that the next five years of container engineering is mostly this, because the ergonomics are already settled and the security posture plainly isn't.

If you are putting containers into production now, that is the thing to plan for: the boundary you are running today is the weakest one you will run. Build as though it is going to be replaced, because it is.

Who ends up owning the registry

One thing in the list above is not like the others, and it is the one nobody is arguing about.

A layered image format is a specification; anybody can implement it. A Dockerfile is a text file. But docker pull redis resolves against a single default public index operated by one company, and that default is doing an enormous amount of work. It decides what "the" Redis image is. It sees every pull, which over an estate is a rather good map of what you are building and when you are deploying it. And it is the point at which a free service can later become a metered one, because by then every Dockerfile, CI pipeline and runbook in the industry has the unqualified name baked into it.

Here at AxisOps we think the registry, not the runtime, is the part to watch. Run your own, mirror what you depend on and write image references that name the registry explicitly so that moving is an afternoon's work rather than a project. The format being open is what makes that possible; the default being convenient is what will stop most people doing it.

The same question will arrive for every layer of this. Whoever runs the index everybody defaults to is the one collecting the rent, and conveniences are how defaults get set.

The plain version

Containers are winning because docker run works on a laptop and in production and the difference stops mattering. That is a real engineering achievement and we should say so plainly rather than retrofitting a security story onto it afterwards.