Back in September at the Microsoft Ignite conference, the corporate marketing folks and techies had quite a bit of fanfare around the release of the next major version of the Windows Server operating system, Server 2016. One of the new features of the OS, which was only given a smaller bit of exposure in Atlanta, was the introduction of Windows Containers. For most people, it was a “Yeah, that’s a DevOps thing” reaction. But if you think of it that way, you truly are missing out on some very exciting and innovative technology that can not only benefit DevOps (by default), but also system administrators and cloud administrators alike.
All about containers
Let’s talk about what a Windows Container is first. If you already know Linux containers, then you have the basics. Simply put, containers are an OS virtualization and application delivery technology. They are not the same as virtual machines you run in Hyper-V or vSphere. To draw a picture of the fundamental differences between the two technologies, I like to refer to a good analogy that was penned by Mike Coleman at Docker. It basically says to think of a house and an apartment complex. The house, which has its own plumbing, electrical, heating, and protection from unwanted visitors, is self-contained. The house is essentially a virtual machine. An apartment complex has the same resources as a house, such as electrical, plumbing, and heating, but they are shared among all the units. The individual apartments come in various sizes and you only rent what you need, not the entire complex. The apartments are containers, with the shared resources being the container host.
Now that you have that visual, you should think of containers not as a virtualization technology, but as an application delivery technology. At the core, containers are actually providing a means of virtualizing the operating system for the sole purpose of running applications on a single kernel host. The term applications can also mean services (which are just applications, right?) or microservices (as they are now being called), which could include DNS, DHCP, HTTP servers, and more. Microservices are small, lightweight, elastic, complete, and resilient services that are created for and run inside containers. Now, understand that Linux has been doing containers for a very long time, all the way back to chroot, FreeBSD jails, and Solaris jails. The LXC (Linux Containers) introduction was back in 2008 and has been used by Linux developers almost exclusively—that is, until now.
One question that comes up is “What kind of applications could I possible run in a Windows container?” Well, as I mentioned earlier, you could run microservices like DNS and DHCP, but there are other possibilities as well. You can certainly run IIS and ASP.NET web services in a container, package and run SQL Server in a container, or even run your favorite (or at least my kids’ favorite) gaming addiction of Minecraft in a container. By searching the Docker Hub for Windows Container apps, you’ll see an ever-increasing selection of applications that can ride inside of this awesome technology. And that is just the “official” repository; there are many not-so-official (and even rogue) repositories with even more options. I won’t list these here for liability reasons, but a simple search will give you what you need.
Even with the availability of applications that can run inside of the containers, it needs to be noted that you are still dealing with …well, applications… and they may or may not be coded in such a way that will work in a container environment. This is where we get into the “are containers 100% compatible?” discussion. To put it straight, it’s not about the container being compatible with the application, it’s about the application being able to operate within the container. Some applications, like IIS for example, just work, while others may need some developer assistance or a helper app or two to get going and be stable. Remember, containers are OS virtualization and provide all the basic OS resources that the application(s) request when they run. The container itself is the application delivery mechanism, not the application itself. Clear as mud?
Enter Windows Containers
There are technically two flavors of containers for Windows Server that will run Windows applications:
One is the standard Windows Server Container that runs on top of the operating system, such as Windows Server 2016. The other, called a Hyper-V Container or an “isolated” container, runs in a VM on Microsoft’s Hyper-V hypervisor. This addresses the concerns of security professionals who were hesitant about standard containers running on top of an OS. In addition, it increases the overall running container density capabilities of the Hyper-V hosts. By running multiple containers in Hyper-V VMs, you can effectively take your density count to another level and run hundreds (if not thousands) of containers on a single host. Of course, mileage may vary depending on the host and its resources, but you get the point.
How about management? Well, Windows Containers are Docker containers, plain and simple. If you have used Docker for Linux containers, then you already know Windows containers, because they are almost identical in how they are managed and work, except of course for the base OS that is used. Oh, and it wouldn’t be a Microsoft offering if it didn’t have a licensing factor, which Linux usually does not. Currently, you can deploy Windows Containers in Windows Server 2016 (Full, Core, or NanoServer Editions), Windows 10 (Enterprise and Professional Editions), as well as Azure. You can deploy and manage these containers from any Docker client, including the Windows command line when the Docker Engine is installed. You can also manage them from PowerShell, but this has just recently been open-sourced on GitHub and is still in development, so some features do not yet work as they do in the Docker command line. Look for more administrative capability to come for containers in Microsoft’s management apps as well as some 3rd parties.
This is just the beginning for Windows Containers, and this article just scratches the surface on what they are and what they are capable of. Like it or not, this technology will be part of the future of application delivery for Windows. Given that the Linux kernel is just starting to be integrated into the Windows OS (yes, Hell froze over for some folks when that happened), I am confident in and looking forward to the ability to run both native Linux and Windows Docker containers side-by-side on a Windows host or virtual machine, without the need for a “helper’ VM or other Linux OS shim to get them running. This would be very cool is so many ways and I believe it is a goal that the Blue Badges in Redmond need to focus on. In the near future, it’s all about the applications, and containers are—and will continue to be—a big part of that.
To read more about Docker containers for Windows, check out a good Docker blog article from Product Manager Michael Friis on the basics of Docker on Windows, as well as great quick start and technical documentation at the Microsoft Docker documentation site. For the more visually inclined, I highly recommend Nigel Polton’s series on Docker Containers on PluralSight, or the free YouTube video tutorial series from John Willis (@botchagalupe). These videos are centered on the Linux version of Docker, but almost all of it applies to the Windows port as well.