Building out a Windows container

Containers are a technology that came out of the Linux ecosystem. However, over the years, Windows has introduced support for Docker, and lately Windows is also supported (in GA!) on Kubernetes.

I had been planning to play around with containers and Windows for a while (hey, I work for Microsoft, so why not?). In the course of the next couple of weeks, I\’m planning to share with you 3 things I wanted to discover about Windows containers:

1. Building out a Windows container
2. CI/CD for Windows containers
3. Kubernetes support for Windows containers

This is the first post in that series, talking about Windows containers. Before we build them out, let\’s cover some basics about how Windows supports containers.

Windows Containers basics

Docker for Windows

Containers are a technology to simplify packaging and running applications at scale. They offer process level isolation, meaning you run multiple isolated containers on the same operation system. Containers differ however from virtual machines. Where virtual machines work on an operating system level, containers work on a process level.

The use of containers was popularized with Docker. Docker is both a container runtime as a set of APIs that allow you to build containers. In a typical workflow you have a developer that builds a container image, and an operational person that would then run multiple containers based on that image. The runtime and the tooling around this is build around a set of Docker APIs, which are abstracted by multiple tool (e.g. the Docker CLI that allows command such as docker build and docker run.

When Microsoft introduced container support into Windows, they worked with Docker to make sure that the same tools and APIs could be used to create and run containers on Windows. That means Microsoft adapted the Windows system to be able to run the Docker APIs and then made the necessary contributions to the Docker source code to actually integrate the Docker APIs into Windows.

What that last section means is that you can use the same tools to build and run Linux containers to build and run Windows containers. You\’ll still need to run Windows containers on a Windows machine, but the tooling (e.g. container registry, dockerfiles, docker commands) remains the same.

Process vs Hyper-V isolation.

When looking into Windows Containers, you\’ll notice there are actually two flavors of Windows Containers that offer a different level of isolation. One flavor are the process isolation containers, another are Hyper-V isolation containers.

Process isolation is a similar technology to how containers are implemented on Linux. Multiple containers can run in isolation, while sharing the same Windows kernel.

Hyper-V isolation runs each container in its own micro-VM. This means each container runs its own version of the Windows Kernel. This offers a higher level of isolation compared to process isolation, but has a slightly higher overhead and start-up time.

Base images

All container development starts with a base image. Microsoft has a couple of base images available for Windows containers, the most popular being either Server Core or Server Nano.

Server Core is a bare-bones Windows Server Image that still supports the full .net framework. It contains most of the Windows APIs you might need. This image comes in an image size of about 1.3GB.

Server Nano is a minimal Windows Server Image. It is great to running .net core applications. It has a minimal set of Windows APIs, and doesn\’t come with Powershell or WMI. This minimal comes in at a size of roughly 100MB.

There are a couple additional images made available by Microsoft. There in an IoT optimized image, a full Windows image (at 3.5GB) and a couple of images with different .net Frameworks pre-installed.

That being said, choosing the right base image for a Windows container deployment is critical. As you can see, Nano is about 1/10th the size of a Server Core image, so this will have a major impact on your footprint.

Identity

Identity is a critical piece to consider in Windows container development. In traditional Windows applications, most servers are domain joined. Containers are not domain joined. In stead, you have to rely on a Group Managed Service Account (gMSA) to access AD. Using a gMSA with your container deployments will allow you to use an identity in AD to authenticate and access SQL servers, File shares and other applications.

Setting up Windows 10 to do container development

We\’ll need to do two things to get our containers running on Windows 10:

• Enable Hyper-V
• Install Docker Desktop

The enable Hyper-V step is optional, but recommended. By default, containers on Windows 10 run in Hyper-V isolation (remember from earlier?). You can optionally run them with process isolation. I\’ll run them with Hyper-V isolation, so I\’ll enable the Hyper-V feature.

There\’s a couple ways to setup Hyper-V on Windows 10, and I\’ll go through the easiest one, which is through PowerShell. You need to open PowerShell as an admin. The quickest way to do this, is to hit Windows Key + X and then hit PowerShell (admin).

With PowerShell open, you\’ll need do this one command to enable Hyper-V.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

The setup takes only seconds, and afterwards you\’ll be prompted if you want to restart. You\’ll need to restart for the actual feature become activated.

Next step is to download and install Docker Desktop. You\’ll need to create a DockerHub account and then download the installer. The setup itself is simple, but takes a while to run. One element of caution with the Docker Desktop installation is that this includes a kubectl executable, which will become part of your path variable. Typically not an issue, but I\’ve seen computers where the kubectl version from the Docker Desktop version gets stale, and then you end up playing a cat and mouse game to find out where the file is located. Just be cautious.