So last week I had a cracking and informative conversation on Twitter about native Docker support on the next version of Windows Server. So I thought it only right to scribble down the good stuff here for anyone who didn’t get a chance to listen in and get involved.
It all started when Stu Miniman from Wikibon engaged with me over my previous post ESXi vs Hyper-V – Could Docker Support Be Significant. And to cut a long story short, Stu looped in Nick Weaver (formerly EMC, now at Intel), and Nick looped in Solomon Hykes (founder and CTO of Docker Inc). Anyway…. a bunch of stuff was discussed and the following is what interested me the most.
On the Topic of Native Docker Support on Windows
First up OK….. when I’m talking about native Docker support on Windows Server, I’m talking about Windows running the Docker daemon – the core Docker engine. Meaning we’ll be able to take Windows Server and launch Docker containers on it, all natively. That’s what I’m fully expecting Microsoft to ship at some point on the next version of Windows Server – whenever that happens to be!!!!
NOTE: Now of course…. these containers will be leveraging the Windows kernel, so Linux containers won’t run on a Windows Server running Docker. Let’s be clear about this, Docker containers share access to the kernel of the host machine they’re running on, meaning Windows apps/containers will only run on Windows Docker hosts, and Linux apps/containers will only run on Linux Docker hosts.
Anyway….. on to the interesting stuff….
Porting Docker to Windows is Non-trivial
First up, Solomon states that porting Docker to Windows is non-trivial – obviously the Windows and Linux kernels are very different. But he does point out that the core abstractions of processes, files, networking etc are all the same.
He also points out that the Windows guys have the luxury of starting from scratch, but also the extra requirements of the Windows Registry. No wonder Windows Server vNEXT has been pushed back to 2016….
Copy on Write and Union Mount Filesystems
Solomon then says that the copy-on-write/union mount filesystem approach that Docker images and containers currently rely on will be very different on Windows.
Obviously Windows isn’t anywhere near as rich as Linux when it comes to filesystems and union filesystems – my words not his. But, he does point out that the Docker storage backend is already pluggable. For example, a bunch of different back-end filesystems can be used by Docker. Some of these include AUFS, devicemapper, BTRFS, and recently Overlayfs.
So at the core of Docker 1.x is the need for a CoW filesystem/union mount backend – the way images are built, and the way containers are launched is all built on top of CoW and union mounts.
NOTE: I cover this in my Docker Deep Dive course. In particular in Module 6 – A Closer Look at Images and Containers.
However, Solomon stated that *changing this requirement* will help. And when I asked, he said that the v2 Image format will be taking a step in that direction.
The Docker Execution Driver
Now some other Linux goodness that’s core stuff for Docker containers are kernel namespaces, cgroups, and capabilities. The short and skinny of these is as follows –
- Namespaces let us carve up things like the process tree, the filesystem, networking etc so that each container gets its own unique and isolated view of each – basically making a container think its got PID 0 and the root filesystem (/) and not knowing about other containers on the system….
- croups let us control resource utilisation for containers
- Capabilities let us get very granualr with container privileges
All of these are vital to a solid container system like Docker, and all are native in the Linux kernel. So the question begs…. does the Windows kernel have anything similar up it’s sleeve?
Well your guess is as good as mine…. and apparently as good as Solomon’s.
There’s a bunch of talk in social media about whether things like App-V, ThinApp, Drawbridge etc might be able to provide some of this functionality. But it’s all speculation at the moment.
Microsoft and Open-source
Now then, on the topic of stuff like namespaces, cgroups and capabilities…… The way that Docker leverages these in a Linux environment is through a pluggable component called the execution driver.
And when Docker started out in life, it used LXC as its execution driver. However, this wasn’t ideal, as it was central to providing Docker with access to vital kernel features, and it was essentially borrowed technology. So in order to give themselves more control over core Docker components, Docker Inc chose to implement their own execution driver called libcontainer.
NOTE: Again, this is all covered in my Docker Deep Dive course
Anyway, the fact that Solomon says most of the work in this area is on the shoulders of the Windows guys, suggests – at least to me – more of an LXC based approach to the execution driver on the Windows platform (where Docker Inc are at least in part reliant on others – Microsoft in this case).
Also….. and this is nothing short of rash unsupported speculation from me here….. but if it were the case that MS own and not keep the native execution driver on the Windows platform closed-source…. would it give Microsoft the opportunity to “take the ball home” one they’ve sucked what they can from the Docker ecosystem???? But that’s just scandalous speculation from me – don’tread anything into it!
Docker and Open-source
Anyway…. the conversation sparked me to ask Solomon whether or not the Docker execution driver and storage driver for Windows would be open source – it’s well known that the guys at Docker are passionate about doing everything in the open. Solomon’s reply was that they won’t merge anything into Docker that isn’t open source. Cool!
But since the conversation, I’ve wondered…… does that mean the code will be open sourced…. or does it mean that they won’t be, and those particular pluggable components won’t be “merged”. Hmmmmm????
All in all a great informative conversation! I hope my thoughts and opinions haven’t munged the facts with too much speculation and outright fiction 😀