First look: Run Docker in Windows Server 2016

The way applications are being built and delivered across data centers is changing. The move to a service delivery model is well under way, and it’s closely tied to the shift to a devops culture. Central to this change is the implementation of a continuous delivery processes, using build tooling to deliver new and updated applications.

Also key are container technologies such as Docker, which allow you to abstract applications and services from the underlying OS, running in a secure silo and accessing underlying OS services only. Multiple containers can run on the same host, each protected from the others. Unlike hypervisor-based virtualization, containers don’t need a separate OS image, and containers can happily run on virtualized infrastructure -- including being hosted in infrastructure-as-a-service clouds.

While container technologies are nothing new -- they date back to the mainframe, were a key feature of FreeBSD and OpenSolaris, and have been supported in the Linux kernel for years -- the simplicity of the Docker container engine has made containers an integral component of the modern data center. Docker’s easy-to-use command line and well-defined API mean it’s a snap to build, share, and manage containers on Linux -- and now on Windows.

Windows Server meets Docker

Docker’s Windows tools have been available for some time, but only for Windows 7 and Windows 8.1. Microsoft had promised Docker support in Windows Server a while ago, demonstrating it on stage at its Build developer event in April 2015. It took a few more months for that support to make it to a release of Windows Server, with the first public version arriving a couple of weeks ago in Windows Server 2016 Technical Preview 3.

Now that I have the latest Windows Server 2016 build running on a test server, I’ve been looking at how Windows Server 2016 implements containers. One note: While you can install the PowerShell container cmdlets on a full UI Windows Server, it’s not recommended. That’s why Microsoft includes a WIM (Windows Imaging) disk image for a Server Core with container support as part of the Windows Server 2016 TP3 download alongside the standard installer. While setting up a test server, I also discovered that Windows Server 2016 is now much stricter about the processors it supports, with Second Level Address Translation (SLAT) a prerequisite for Hyper-V, which meant that one of my test servers is now obsolete.

While you can convert the Server Core WIM into a Hyper-V VM or use it to set up Windows Server 2016 Core on a bare-metal server, it’s actually easier to start with Windows Server containers by downloading a preconfigured Hyper-V image from MSDN, using a PowerShell script to pull down the image and install and configure the VM. There’s no progress indicator in the download script, and it’s a 6GB or so set of files, so you’ll need to keep an eye on the download using other tools. I used the network traffic monitor built into Task Manager, as my Internet connection was being very flaky. Alternatively you can use Azure’s IaaS as a host; a Windows Server 2016 Core image with container support is available in the Azure gallery.

Once the virtual machine has been downloaded, the script will unpack the archive and set up a Hyper-V virtual machine, launching it using the password you set when invoking the download script. You can use Hyper-V’s built-in viewer to connect to the VM, though first you’ll want to shut down the VM and connect it to your Hyper-V virtual switch.

The initial image is a basic Windows Server Core container, and you’ll need to add files and services to it before you can use it as part of an application. As files are added, you can use Docker commands to make a fresh image, so you have a new container ready to go. Each time you create a container from an image, you’re instantiating a fresh file system. Thus, shutting down a container will destroy any data that has been stored in the container, unless you’re saving it in an external file system or another application or service.

Microsoft’s Quick Start on Windows Server Containers and Docker walks you through the process of using Docker commands to build new images and connecting a containerized Web server to an external network. It’s pretty straightforward. If you’ve used Docker on Linux or on a Windows development laptop you’ll find the process to be quite familiar.

That’s not to say it’s ready for prime time: Not all Docker commands work with the Windows Server 2016 release yet. You won’t be able to get a diff, you can’t restart a container, and there’s still a question whether pause and unpause will be supported. Some other commands work partially. For example, only some of the options for build work. However, you can connect to a container using Remote Desktop, if you’ve set the administrator password and opened the correct firewall ports.

Powering containers with PowerShell

As an alternative to Docker, Microsoft gives you the option of using PowerShell to build and manage containers. Windows Server 2016, especially the new Nano Server option, is designed to be managed by remote PowerShell scripts, either your own or through System Center, so using it to manage Windows Containers makes a lot of sense. There’s no difference between a Docker Windows Container and a PowerShell Windows Container, and while the current Technical Preview doesn’t let you use Docker to manage a container created in PowerShell and vice versa, the two can work with the same library.

You can use PowerShell to implement a container with one of the images bundled in the evaluation Server Core VM, connecting it to a Hyper-V Virtual Switch. Once the container has been created, you’ll use another PowerShell command to start the container, which can then be managed via remote PowerShell commands. Container cmdlets can be bundled into scripts to simplify container deployment, making it easier to automate containers across data centers or cloud infrastructures.

If you’ve used Docker to build and run containers in the past, you may have issues with the PowerShell cmdlet syntax. PowerShell’s container management tooling is all about building scripts, so instead of launching a container in one line of code, you’ll first create a container description, attach it to a variable, and use another cmdlet to launch that container. Once you’ve written PowerShell code, it’s relatively easy to generalize the instructions, with your code as the basis of a script.

Networking poses challenges for containers, and Windows Containers address this by using the host OS to handle NAT. Containers get an IP address from the host, and the host can be configured to handle port mapping and firewalling for the container. In some cases you will need to set up static port mappings, using either PowerShell or Docker commands. You’ll also need to configure the host OS’s built-in firewall rules. If you want to have a directly addressable container, you’ll need to configure it to get IP addresses from the rest of the network using DHCP or an IPAM (IP Address Management) server, then use a script to update the DNS. In practice it will be easier to leave containers unnamed, unless you need direct access, and handle connections via a load balancer for Web endpoints or via a message queue for microservices.

Microsoft’s initial documentation guides you through setting up an Nginx Web server on a container. If you want to experiment with other containers, Microsoft has additional samples on GitHub, including Node.js and IIS -- as well as Minecraft. However, the real aim for this early release is to get your applications running on Windows Containers. It’s a good opportunity to see how some of your own code works in a container and to experiment with using containers as a scaling mechanism.

Docker vs. PowerShell

Microsoft has chosen to separate PowerShell and Docker container management at this point, as there are some fundamental differences between the two management platforms. It’s unclear how the gaps will be bridged, as they include issues as simple as naming and as complex as managing state. Until Microsoft details its approach to blending the two, it’s best to pick one approach and stick with it. Both PowerShell and Docker give you command-line control of your containers, and both offer APIs that can be used by higher-level management tooling.

That means there are still significant caveats around Windows Server Containers. While Microsoft is working to fix the PowerShell-Docker divide, it’s a significant issue for anyone wanting to pilot a container-driven continuous delivery process either locally or in Azure.

That’s not to say it isn’t worth trying out Windows Server’s container support. You can use the new PowerShell tooling to start building the management framework you will need if you’re going to run containers in a production environment. Similarly, you can start exploring how Docker will work in your data center, building and running an environment to host containers that can be used once Windows Server 2016 is released. With Hyper-V Containers still to be unveiled, we don’t yet have the complete picture around containers in Windows Server 2016. But Windows Server 2016 TP3 offers enough to get started -- while we look forward to seeing more in future Technical Previews.