Until recently, deploying containers on Windows (or on Microsoft’s Azure cloud) meant deploying them on a Linux/UNIX VM managed by a Windows-based hypervisor. Microsoft is a member of the Open Container Initiative, and has been generally quite supportive of such solutions, but they necessarily required the added VM layer of abstraction, rather than being native Windows containers. If you wanted containers, and if you wanted Docker, at some point, you needed Linux or UNIX. Microsoft’s much anticipated Technical Preview of the Docker Engine for Windows Server is out. Let’s look at some of the differences between Docker on Linux.
First, though, let’s look at the difference between a virtual machine and a container? If you’re reading this, you probably know the answer in detail, but we’ll do a quick run-through anyway.
Containerization From the Past
A virtual machine (or VM) is a complete computer hardware layer (CPU, RAM, I/O, etc.) abstracted to software, and running as if it were a self-contained, independent machine within the host operating system. A VM is managed by a hypervisor application (such as VirtualBox or VMware) running on the host system. The VM itself has an operating system that is completely independent of the host system, so a virtual machine with a Linux OS can run on Windows, or vice versa.
While a container may look like a virtual machine, it is a very different sort of device when you look under the hood. Like a VM, a container provides a self-contained, isolated environment in which to run a program. A container, however, uses many of the resources of the host system. At the same time, the applications within the container can’t see or act outside of the bounds of the container. Since the container uses so many of the host system’s basic resources, the container’s OS is essentially the same as the host OS.
While VM hypervisors are available for most operating systems (allowing an individual instance of a VM to be essentially machine-independent), containers developed largely out of the Linux/UNIX world, and have been closely tied to Linux and UNIX systems. Docker has become the de facto standard for deploying and managing containers, and Docker itself is native to the Linux/UNIX world.
Windows Server 2016 and the New Hyper-V
Enter Windows Server Containers, and Windows Server 2016. Windows Server Containers are native Windows containers running on Windows Server 2016, and they come with a Windows implementation of Docker. Now, if you want container and you want Docker, you can have them directly on Windows.
But what does this mean in practice? First and foremost, a Windows Server Container is exactly what the name implies — a Windows container. Just as a Linux-based container makes direct use of the resources of the underlying operating system and is dependent on it, a Windows Server Container uses Windows resources, and is dependent on Windows. This means that you can’t deploy a Windows Server Container directly on a Linux/UNIX system, any more than you can deploy a Linux container directly on a Windows system.
Note: Initially system resources used in a Windows Server Container instance must exactly match those used by the host system in terms of version number, build, and patch; since Windows Server Containers are still in the technical preview stage, however, this may change.)
Microsoft has added a bonus: along with Windows Server Containers, which are standard containers at heart, it is also offering a kind of hybrid container, which it calls Hyper-V. A Hyper-V container is more like a standard virtual machine, in that it has its own operating system kernel and memory space, but in other ways, it is dependent on system resources in the manner of a typical container. Microsoft says that the advantage of Hyper-V containers is that they have greater isolation from the host system, and thus more security, making them a better choice for situations where you do not have full control over what’s going to be going on within the containers. Hyper-V containers can be deployed and managed exactly like Windows Server Containers.
How they Compare
So, then, is Windows Docker really Docker? Yes, it is. Microsoft has taken considerable care to make sure that all of the Docker CLI commands are implemented in the Windows version; Windows Server Containers (and Hyper-V containers) can be managed either from the Docker command line or the PowerShell command line.
Now for some of the “mostly, but not 100%” part: Windows Server Containers and Docker containers aren’t quite the same thing. You can use Docker to create a Windows Server Container from an existing Windows Server Container image, and you can manage the new container using Docker. You can also create and manage Windows Server Containers from PowerShell, but if you provision a container with PowerShell it cannot be managed directly with the Docker client/server and vice versa. You must stick with one provisioning method. (Microsoft, however, has indicated that this may change.)
In many ways, these are the complications that you would expect when porting a conceptually rather complex and platform-dependent system from one OS to another. What’s more important is that you can now deploy containers using Docker directly on Windows. It may not be a threat to Linux, but it does keep Microsoft in the game at a time when that game has been shifting more and more towards open-source and generally Linux/UNIX-based DevOps tools.
So to answer the question, “Are Windows Server Containers really Docker?” — they are as much Docker as you could reasonably expect, and then some. They are also definitely Windows containers, and Microsoft to the core. If you’re interested in learning more about your containers running on Windows Server, check out the Docker Log Analyzer from Sumo Logic.
About Michael Churchman
Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the 90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.