Q. What is the difference between Windows Containers and Hyper-V Containers in Windows Server 2016?
A. Containers are a very popular technology in the Linux world today as they solve a number of challenges related to application deployment.
Here's an example: An application developer writes a program, then gives it to the IT department to deploy -- but it doesn't work because there are various dependencies missing (i.e. the developer had them in their environment but missing in the server environment). Containers solve this by creating a complete dependency for an application including middleware, runtimes, libraries and even the OS requirements. Additionally, each of these dependencies/layers are packaged up and run in their own user-mode container, isolating them from other applications avoiding problems with applications not being compatible with each other. These applications running in containers have their own view of the file system, registry and even networking addresses.
Docker is a very popular in the world of containers as a standard repository and management layer for the native container functionality found in Linux. Windows Server 2016 brings containers to Windows Server and integrates with Docker for the repository and management. Windows Server 2016 will have two types of containers, Windows containers and Hyper-V containers.
[Container World delivers real-world case studies from the cloud-native ecosystem, hands-on technical education, the best speakers and cutting-edge startups under one roof. Get your ticket.]
Windows containers work the same was as Linux containers. Each containerized application runs in its own user-mode, isolated container on a shared host operating system. This is shown in the picture below and also shows how the various dependencies are pulled for a Docker application.
Note that different containers may use the same libraries. Also note that while an application has a dependency on a certain OS version and a base OS image may be downloaded, this must match the host OS version as multiple OS versions are not possible since they share a common kernel and OS.
There are two challenges with this approach that may cause a problem in certain environments.
- Not enough isolation since the isolation is at user-mode meaning a shared kernel. In a single tenant environment where applications can be trusted this is not a problem but in a multi-tenant environment a bad tenant may try to use the shared kernel to attack other containers.
- There is a dependency on the host OS version and even patch level which may cause problems if a patch is deployed to the host which then breaks the application.
This is where Hyper-V containers can be used. Hyper-V containers use the base image defined for the application and automatically creates a Hyper-V VM using that base image. Inside that VM are the various binaries, libraries and the application inside a Windows container -- and that is a critical point. Hyper-V containers are still using Windows containers within the VM. The only difference is the Windows container is now running inside a Hyper-V VM which provides kernel isolation and separation of the host patch/version level from that used by the application. The application is containerized using Windows containers and then at deployment time you pick the level of isolation required by choosing a Windows or Hyper-V container. This is shown below. Note that multiple Hyper-V containers can use a common base image and no manual management of the VMs is required. They are automatically created and deleted.
Windows Server 2016 supports nested virtualization which means even if your container host is a Hyper-V VM you will still be able to use Hyper-V containers on that container host as it can create VMs within VMs.