Docker and Containers (Part 3) – Containers and Windows Server

If you would like to read the other parts in this article series please go to:


In Part 1 of this series we learned about containers, an operating system (OS) virtualization technology that allow application code to be virtualized into isolated “containers” that share the operating system kernel and libraries of the underlying host system. Then in Part 2 we learned about Docker, a collection of open source tools, solutions and cloud-based services that provide a common model for packaging or “containerizing” application code into images that can be easily deployed on host machines running in Docker’s own cloud.

Docker started out as a Linux-only solution since container virtualization itself was first developed for the Linux operating system. But as administrators of Windows Server-based networks however, our real interest is in how container technologies can be implemented, deployed and used with the Windows Server operating system, and that takes us to the frontiers of the next version of the Windows Server platform which should reach RTM and GA later this year. That’s because starting with the currently available Technical Preview 4 release Windows Server 2016 now includes Windows Containers, a built-in container virtualization technology that will allow multiple isolated applications to run on a single computer. We will begin our look at Windows Containers in this article and then we’ll dig deeper into this technology in the articles that follow.

Two types of Windows Containers

The first thing we need to understand about Windows Containers is that there are two “flavors” of this technology coming in Windows Server 2016. These two flavors are:

  • Windows Server Containers
  • Hyper-V Containers

Let’s start by examining each of these briefly. Note that the explanations provided here are based on preliminary documentation as of Windows Server 2016 Technical Preview 4, so if anything significant changes we’ll update this article after RTM.

Windows Server Containers

Windows Server Containers are similar to Linux containers. In other words, with Windows Server Containers you can have multiple applications each isolated in its own container but sharing the operating system kernel of the container host system which is running Windows Server 2016. Windows Server Containers supports the Docker APIs and includes a Docker client, which means you also can use the Docker toolset to manage containers on Windows Server 2016 host machines, and we’ll examine how this can be done later in this series.

Unlike traditional Windows desktop applications, the kind of application you would put in a container on a Windows Server 2016 host should be stateless (doesn’t try to store any state data in its container) and GUI-less (Windows containers don’t expose a GUI). So you probably won’t be running your accounting package or favorite game in a container–you’ll need at least a virtual machine (the more well-known virtualization technology) for such purposes. Stateless, GUI-less web applications and similar code are the most likely candidates for utilizing the Windows container technologies coming in Windows Server 2016, and we’ll see how that’s done soon.

Figure 1 below illustrates how Windows Server Containers are implemented in Windows Server 2016. This container technology is suitable for a single-tenant environment.

Figure 1: Windows Server Containers

Hyper-V Containers

Now let’s look at the other flavor of container technology that was introduced with Technical Preview 4 of Windows Server 2016. The main difference between this and Windows Server Containers is the level of isolation they provide.

With Windows Server Containers, the container and its application run in user-mode on the physical host system which must be running Windows Server 2016. All of the containers created on the container host share the kernel of the host system. This type of isolation should be fine in a single tenant environment where all of the applications are trusted as for example when the applications are all developed and maintained by a single enterprise. But what if your organization is a very large enterprise with multiple independent subsidiaries, or if you are a cloud service provider that needs to offer container services to multiple tenants? In this case, you wouldn’t want two tenants to use containers that share the same kernel because if malware from (or malicious attack by) one tenant compromised the kernel of the container host it would cause serious problems for the other tenant(s) with containers on the same host.

The solution in this case (for multi-tenant environments) that want to use Windows Containers is to implement Hyper-V Containers instead of Windows Server Containers. In this scenario the containers you create for your applications are deployed onto a Windows Server 2016 virtual machine that is running on a Windows Server 2016 Hyper-V host. So with Hyper-V Containers the container host is a virtual machine; contrast this with Windows Server Containers where the container host must be a physical machine.

Hyper-V Containers can thus be useful for example to cloud hosting providers who want to offer containers as a service for customers who want to use such technology. In a typical usage scenario, the service provider would have a cluster of Hyper-V hosts running Windows Server 2016 for a portion of their cloud. This Hyper-V host cluster would host a group of virtual machines, and each virtual machine would have Windows Server 2016 installed as its guest operating system. By using Windows Container technology, each of these virtual machines would assume the role of a container host. Each container host (virtual machine) would then be assigned to a different customer or tenant, and the customer or tenant could then create as many containers as they need on their dedicated container host. If one container host (virtual machine) should somehow be compromised by malware or through a malicious attack, the other virtual machines belonging to other customers would be unaffected.

Figure 2 below illustrates how Hyper-V Containers are implemented in Windows Server 2016. As you can see from the diagram, this container technology is suitable for a multi-tenant environment where each customer uses a different container host virtual machine (VM) for greater isolation from other tenants. Note that as of Windows Server 2016 TP4 it’s not clear whether a VM container host can host multiple or only one container (and containerized application) as the documentation on this matter is unclear at this point, so we may need to update this information after RTM.

Figure 2: Hyper-V Containers

The key to making Hyper-V Containers work is a new functionality in Windows Server 2016 called Nested Virtualization that allows you to install and run the Hyper-V role within a virtual machine–provided that the guest operating system of the virtual machine is Windows Server 2016 and the operating system of the underlying physical host is also Windows Server 2016. You can learn more about Nested Virtualization in Windows Server 2016 on MSDN here though this is early documentation that has not yet been updated.

One other scenario where Hyper-V Containers may be useful even in a single-tenant environment is where one or more of the applications you want to run in a containerized fashion have some sort of dependency upon the operating system version level or patch level of the underlying container host. If this is the case, then instead of provisioning and configuring several physical systems as container hosts and using the Windows Server Containers approach, you might prefer to provision a single Hyper-V physical host (or host cluster) and using the Hyper-V Containers approach instead to save on physical hardware costs.

To Be Continued

Now that we have an understanding of the broad differences between the two Windows Container technologies coming in Windows Server 2016, the next few articles in this series will take a closer look at how these container technologies are implemented.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top