written by Arnaud Porterie, Docker Senior Engineering Manager



It’s here…



Never been more stoked before then when I started the docker daemon on Windows today eeeeeeeeeeeee — jessie frazelle (@frazelledazzell) August 11, 2015

As core engineer on the Docker Engine team, I naturally spend most of time in Linux. Recently that has been changing: in April, we released a Windows version of the Docker client. Through this process, we have been working closely with Microsoft developers and showing progress along the way, like what was demonstrated at the Build conference and DockerCon 2015.

One question I get a lot besides “When are you merging my PR?” is “When will Docker run on Windows?” The first question requires a blog post of it’s own… but the second question now has a rather exciting answer.

This week marks a huge leap forward as we release a tech preview of Docker Engine for Windows Server aka the Windows daemon available for download and testing. Windows Server 2016 Technical Preview 3 (TP3) and Docker Engine for Windows Server together makes the Docker experience available to many more developers — to build new software and to contribute back to the project.

Docker daemon for Windows Server in a nutshell

Many are confused by what it means to run Docker on Windows Server. Here are a few key points to help clarify the process and technical details:

• Docker Engine for Windows Server port is not a fork, nor a different project: it’s the same open source code base being built for Linux and Windows

• The Technical Preview of Docker for Windows Server isn’t feature complete yet (and taking into account that the feature sets will never be exactly identical given the differences of the underlying platforms), most of the Docker commands you already know will work as expected on Windows Server. For example, you can write a Dockerfile and docker build as you would on Linux.

• The Docker daemon for Windows Server doesn’t run Linux images! No virtualization is involved. The Windows Server Containers reuse the host kernel and create a sandboxed environment for the process, exactly like it does on Linux.

This means that Docker is becoming a platform-agnostic interface for running processes. For example, having a consistent API allows distributing workloads across a mixed cluster of Linux and Windows Server hosts orchestrated by Docker Swarm using a single Docker CLI and the same Docker commands! Without any new commands to learn the same developer now has more options when they build software.

Two Worlds Collide

Since the work started in November 2014, it has been and still remains quite unbelievable for us to interact with Microsoft on an Open Source project. And even if we confess a bit of skepticism in the early days, we have to admit now how impressed (and really, slightly overwhelmed) we have been by the pace of the Microsoft contributors, starting with Ahmet Alp Balkan with his work on the client, followed by John Howard, John Starks, and Stefan Wernli on the daemon side. Seriously, thanks for joining the Docker contributor community!

Hell freezes over as Jessie Frazelle is spotted using Notepad.

Overall, it’s about 180,000 lines of code that the Microsoft team has been modifying to make this happen, all out in the open and all going through the regular Docker project reviewing process.

Introducing Nyancat, our best ANSi Emulator stress test.

Porting Docker to Windows



Container runtime and kernel dependency



It is commonly understood that Docker makes extensive use of Linux kernel features (namely namespaces and cgroups. In a similar way, Microsoft has been adding containerization primitives to the Windows kernel, allowing any user code to execute a process in a sandboxed environment. Those feature are only available in the just released Windows Server 2016 Tech Preview 3 (TP3), which makes it the only Windows Server operating system that is capable of running the Docker daemon today.

In the Docker code base, the piece that does the execution of containers is called the execdriver , as a default implementation on Linux to calls out to libcontainer – and in the very near future will rely on runC . For Windows containers, the Microsoft team integrated into this architecture a Windows specific execdriver . Just like its Linux counterpart, this implementation rapidly calls out to kernel code and in this case to the Host Compute Service through the microsoft/hccshim package.

Anecdotally, I’ve been told that this is the first time in history the Microsoft Windows Base team contributed code to open source: how cool is that?

Continuous integration

Any long running effort to port software requires many incremental changes, and continuous integration is an essential piece to preserve any progress made. Indeed, the vast majority of our contributors run Linux and don’t necessarily have the environment or time to verify that their patch isn’t breaking the Windows build.

This is why a first and essential step was to get the build green (even with many pieces removed) in order to enable Windows Server compilation as a continuous integration job. As Microsoft’s teams were sending patches to push the Windows port forward, CI would ensure that no other contributions would add more non-portable code, or even worse, break code that had already been ported.

Try it yourself!

We are really excited to have you download and try Docker on Windows Server. Remember that this is a Technical Preview so there are some limitations and the command docker push is not supported in this release. Try it out and give us lots of feedback as we work towards the next release.

• Try Windows Server 2016 TP3

• Community Resources

• Discussion Forum



And if you are new to Docker, here are some things to check out to get you started:

• Get Started with Docker

• Register for a Webinar

• Free Online Training

• Docker and Microsoft Resource Center

Learn More about Docker