Review: Windows Server containers are new and strange
Microsoft’s Docker-driven container feature works as advertised, but comes with a steep learning curve
-
Windows Server 2016 Containers
Containers have been all the rage in the open source world for a number of years, but noticeably absent from Windows until now. In Windows Server 2016, Microsoft released its own container capabilities. Furthermore, Microsoft has given its customers the flexibility of operating containers at the Windows Server level or at the Hyper-V level.
Before I go on, let me take just a moment to explain the basic concept of a container. Containers are a form of virtualization, but they are quite different from virtual machines. Virtual machines use hardware virtualization to allow multiple OS instances to run side by side, isolated from one another by the virtual machine structure.
In contrast, containers don't include their own operating system but share a common OS image. As such, a container contains only application and service binaries and the libraries and configuration files those binaries require. For example, a Windows Server container would contain things like registry entries and application binaries.
As previously mentioned, Windows Server 2016 allows for the creation of Windows Server containers and Hyper-V containers. The two container types are nearly identical to one another, but there is one important difference between the two.
It isn’t always acceptable for two containers to share a common OS kernel. There may be security requirements that mandate total isolation between two workloads, or a workload’s functional requirements may mandate the use of two different OS kernels (such as a Nano Server kernel and a Server Core kernel).
Unlike Windows Server containers, Hyper-V containers place the host OS kernel inside of a Hyper-V VM. Thus multiple host OS kernels can be used in parallel, and isolated from one another through hardware virtualization. Otherwise Windows Server containers and Hyper-V containers work the same way, and you manage them with the same tools.
Getting started with Windows containers
The first step to deploying Windows Server containers is to install the container feature, and then reboot the server. As you can see in Figure 1, the process of installing the Container feature is no different from installing any other Windows Server feature.
Figure 1
The installation and configuration process gets a little bit tricky at this point. Some of the procedures used to get a container up and running have changed since the days of Windows Server 2016 Technical Preview, and much of the online documentation has not yet caught up.
The next thing that you will have to do before you can create a container is to install Docker. Docker is the management tool that is used to create and run Windows Server and Hyper-V containers. You can install Docker by entering the following commands:
Install-Module DockerMsftProvider
Install-Package -Name docker -ProviderName DockerMsftProvider
You can see what the installation process looks like in Figure 2. When the installation completes, you will need to reboot the server.
Figure 2
When the server restarts, you will need to make sure that the Docker service is running. To do so, use the following command:
get-service docker
If the service is stopped, then you can start the service by typing:
start-service docker
You can then use these commands to confirm that the Docker service is running and functioning as expected:
get-service docker
docker version
You can see these commands in action in Figure 3.
Figure 3
It is worth noting that Docker commands are case sensitive. In most cases, the commands must be entered in lower case to avoid receiving an error message.
Once Docker is up and running, you will need to install the base container image, and then restart the Docker service. The command used to install the base image varies depending on whether you decide to use a Windows Server Core image or a Nano Server image. This command is used for install a base Windows Server Core image:
docker pull Microsoft/windowsservercore
This command is used to install a base Nano Server image:
docker pull Microsoft/nanoserver
Regardless of which type of base image you deploy, you will have to restart the Docker service once the base image has been installed. At that point, your container host should be ready for use. You can verify that the images have been correctly installed by entering the docker images
command. For instance, Figure 4 shows a Windows Server Core image that is ready for use.
Figure 4
Creating a container from the base image is relatively easy to do. To create a Docker container, you will need to use the docker run
command, along with the name of the base image that you want to use, and the name of the command that you want to run inside of the container. Add the -it
switch if you want the container to be interactive. There are many other switches available that we won't get into here, but you can access these switches by entering the docker --help
command.
The following command line will create a Windows Server Core container and execute the shell command, landing you at the command prompt:
docker run -it Microsoft/windowsservercore cmd
If you look at Figure 5, you can see that the command prompt window has opened inside of PowerShell. This prompt is inside the Windows Server Core container that we have just created.
Figure 5
It is easy to think of the container shown in the figure above as being like a VM running a single application (the command prompt window). While that analogy is at least somewhat fitting, there is another key difference between containers and virtual machines that you need to be aware of.
Containers are meant to be highly dynamic. They can be created, destroyed, and recreated easily on a whim. In fact, containers tend to be temporary structures, created from scratch whenever they are needed. The essential concept to keep in mind is that containers only exist for as long as the application within the container is running.
To illustrate this point, I typed exit
to exit the Command Prompt window, effectively terminating the container. I then used the same command that I used earlier to create another container. From a different PowerShell window, I entered the following command:
docker ps -a
This command lists the machine’s containers. It lists running containers, and those containers that have been exited. If you look at Figure 6, you can see that the container at the bottom of the list was created 12 minutes ago, and was terminated 8 minutes ago. In contrast, the first container on the list was created about a minute ago, and is still running.
Figure 6
Thoughts on Windows containers
Working with Windows Server containers will be a completely new experience to most seasoned Windows administrators. Docker uses its own set of commands that are vastly different from the Windows command prompt and PowerShell commands that we are all accustomed to.
When you combine this new command set with a concept that is completely different from anything in Windows in the past, and throw in Microsoft documentation that is difficult to follow, it makes for a steep learning curve. On the plus side, Windows Server containers behave much like their Linux counterparts, and Linux containers have been around for a long time. This will get easier.
But as I work with Windows containers, I just can’t help but to get the feeling that Microsoft is still trying to figure out where containers fit into its current ecosystem. Perhaps the best evidence of this is the inability to manage Windows Server containers through System Center.
Overall, I think that Microsoft has done a decent job on its container feature. This is Microsoft’s first attempt at supporting containers, and Windows Server containers seem to be nearly as good as the containers that are used in the open source world, although I admittedly have had very little experience with Linux containers.
What Microsoft needs to do now is to provide its customers with better documentation on the container feature, with plenty of step-by-step tutorials. Until that happens, Windows admins are unlikely to get the full benefit from their containers. Microsoft also needs to extend the System Center suite so that customers can use the same tools to manage containers as they use to manage their other Windows resources.
---
Cost: Microsoft offers two different editions of Windows Server 2016. Windows Server 2016 Standard Edition is designed for low density, or non-virtualized environments, and retails for $882. Standard Edition allows for up to two Hyper-V containers, or an unlimited number of Windows Server containers. Windows Server 2016 Datacenter Edition retails for $6115, but allows for an unlimited number of Hyper-V and Windows Server containers.
Copyright © 2017 IDG Communications, Inc.