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