Microsoft has just released Tech Preview 3 (TP3) of their Windows Server 2016 Operating System introducing local container support among some other goodies. In this short post I’d like to share with you some ‘nice to know’ facts with regards to Windows containerisation as it stands today and moving forward.
Where to start?
To start, what are containers? To answer that question we first need to make a distinction between the two types of containers that Windows is going to support. First of all we have native, Windows server, containers, which can reside on a physical or virtualized Windows host running Server 2016. Windows containers will interact with the underlying Operating System (kernel) in exactly the same way that Docker containers do. This type of container is available today within the TP3 version of Windows Server 2016.
Hyper-V containers soon to be shipped
The second type is referred to as Hyper-V containers; these will be supported in the next TP (4) release of Windows Server 2016. Here each container will have its own copy of the Windows kernel to interact with, isolating them from any other containers that might be residing on the same host, providing additional isolation and security. Both container types, native Windows Server and Hyper-V will utilize the same management APIs, tools and image formats. At deployment time, customers can simply choose which deployment mode best meets their requirements. The differences between the two are minimal, with isolation (Hyper-V) being the most important one.
From Microsoft.com: The choice of container type is made when you start the container. A developer can create a container image using a Windows Server Container and deploy it as a Hyper-V Container or vice-versa without any changes other than specifying the appropriate runtime flag
Not like we were / are used to
Due note that this is different from ‘traditional’ application virtualization, like App-V for example, which does offer full isolation in the form of a private bubble if you will. Although from a containerized application perspective it will look and feel as if it has its own personal Operating System to run on, which is partly true since it does get sandboxed, it will still share a great deal of the underlying Windows kernel subsystems and devices with all other containers running on the same host. Again, here I’m referring to native, Windows Server, containers available today, not the Hyper-V containers. Which kind of brings me to the original question which I started out with, what are containers, and how do they rely on the underlying Operating System?
We could do with some more detail
You can probably imagine that this isn’t a question easily answered in just a few sentences. I wrote an extensive article on this a few months ago talking about Docker containers and all that surrounds them. How a container is build and run, the components it consists of, kernel interactions, isolation, repositories etc. I also listed the advantages and disadvantages containers bring to the table, plus extras.
And although I was primarily focusing on Docker, and thus Linux, containers at that time, all is still relevant today when having a look at Windows containers. Read it here. There might be some slight differences between the two, especially when comparing some of the kernel functionalities and resources shared by the container images with regards to the workloads in there (workloads run from within a container, not on top) which is basically Windows vs. Linux, but the overall concepts are pretty much the same.
Unified management
Currently both parties are working on making the standard Docker toolset compatible with both Docker and Windows Server containers, including the announced Hyper-V containers. And while you won’t be able to run Linux based containers on a Windows Operating System or vice versa (they simply depend on different kernel API’s etc.) you will, eventually, be able to use one single toolset to manage both. Parallel to all this Microsoft is also working on an updated version of their Docker toolset through Visual Studio, supporting both types, or versions, of containers as well.
Getting started
To get started using containers on Windows Server 2016, either on a physical or a virtualized host (note that it has to be a Core installation and you will need at least 10 GB of free disk space), you will need a so called base container Operating System, see my earlier mentioned article for an explanation on how all this works. But don’t worry, Microsoft has put together a ready to run script to get you up and ready for action fast. From your 2016 host you…
- Start an Administrative PowerShell session and type:
- start-process powershell -Verb runas
- wget -uri http://aka.ms/setupcontainers -OutFile C:\ContainerSetup.ps1 (which will download the actual script)
- C:\ContainerSetup.ps1 (which will execute the script)
As per Microsoft: The script will then begin to download and configure the Windows Server Container components. This process may take quite some time due to the large download. The machine may reboot during the process. When finished your machine will be configured and ready for you to create and manage Windows Server Containers and Windows Server Container Images with both PowerShell and Docker.
If you want to add in container support manually, you can as well. It is available as a Windows feature and can be added by running the command:
Install-WindowsFeature –name Containers
Also make sure to check out Marius Sandbu’s blog for a quick intro to Windows Server containers. He mentions a nice reference to Microsoft’s GitHub site from where a bunch of container examples can be downloaded.
Here Microsoft’s MSDN page on Windows Containers, a lot of useful information on there as well.
