Getting Started with Containers (Part 2)

If you would like to read the other parts in this article series please go to:

• Getting Started with Containers (Part 1)
• Getting Started with Containers (Part 3)
• Getting Started With Containers (Part 4)
• Getting Started With Containers (Part 5)
• Getting Started with Containers (Part 6)
• Getting Started with Containers (Part 7)
• Getting Started With Containers (Part 8)

Introduction

In my previous article, I took some time to explain what containers are, and what they are not. Simply put, a container is an object that allows code to be used by multiple workloads, while enforcing an isolation boundary (see my previous article for a more detailed explanation). So far, I have talked about containers in a generic, almost theoretical context.

Before I Begin

Before I get started, I want to be sure to point out that the content in this article series is based on a Windows Server 2016 preview release. As such, it is possible that Microsoft could end up making some changes by the time that Windows Server 2016 is eventually released.

Windows Server Container Basics

One of the things that I mentioned in my previous article was that based on what I have read on some Internet message boards, containers seem to be causing a bit of confusion for some administrators. Based on what I have read, I think that the main reason for this confusion is that Windows Server 2016 offers two different types of containers. One type of container is based on Windows Server, while the other is based on Hyper-V. These two container types have their differences, and yet they are both referred to as containers. As such, I have read blog posts that directly contradict one another, and yet both posts are correct because the posts refer to two different types of containers. As such, the key to understanding containers is to first learn the basic container types and how they function. That is what this article is all about.

Hosts and Images

Even though there are two different types of containers that are supported by Windows Server 2016, the two container types are not radically different from one another. Regardless of whether a deployment is based on Windows Server containers or Hyper-V containers, there are certain concepts that universally apply.

One such concept is that of a container host. A container host can be a physical computer, as in the case of Windows Server containers, or it can be a virtual machine if Hyper-V containers are used. As the name implies, it is the container host’s job to host the containers. A single container host can host multiple containers, although it is also permissible for a host to host a single container.

The next concept that you must understand is that od a container image. Both Windows Server containers and Hyper-V containers are deployed from images. These images are generically referred to as container images.

Container images are perhaps the single most important concept that you will need to understand. The first thing that you need to know about container images is that they are different from other types of images used in IT. To show you what I mean, consider the way that most organizations handle server virtualization. The organization builds a series of sysprepped virtual machine images that can be used to deploy an operating system (and possibly some applications) to newly created virtual machines.

Things work a little bit differently in the world of containers, even though some of the terminology is similar to that of server virtualization. In the world of Hyper-V, a virtual machine image is usually just a virtual hard disk file whose contents have been prepared for cloning. Container images work differently from Hyper-V images, even though both technologies use the concept of images and even though Hyper-V containers use virtual machines.

So with that said, container images are not virtual machine specific. A container image can be used on a physical container host or on a virtual container host. The host type is irrelevant.

One of the things that makes container images different from virtual machine images is that virtual machine images are usually self-contained, whereas container images might not be. As previously mentioned, a virtual machine image commonly exists as a virtual hard disk file. A container image on the other hand, more closely resembles a collection of differencing disks.

Container images can be made up of many different layers, and these layers can have complex relationships (dependencies) with one another. If you think back to my previous article, you will recall that I explained that one of the main reasons for using containers is to improve efficiency. In a virtual server environment, running ten different virtual machines may mean having ten different copies of the same system files and running ten different instances of the same system processes. Containers seek to reduce this inefficiency by eliminating redundancy. It is the container images and their layers that make this possible. Let me give you an example.

Suppose for a moment that you needed to deploy three Exchange Server mailbox servers. If you stop and think about it, these servers contain a lot of redundancy. Each one would have a Windows Server operating system. The servers would also contain the same Exchange Server binaries. In fact, the biggest difference from one server to the next would be the contents of the mailbox database.

Anyone who has ever deployed a collection of Exchange Servers knows how time consuming the process can be. I recently had to deploy a series of virtualized Exchange mailbox servers for a project that I was working on. My approach was to create a virtual machine image (not a container image) containing the Windows Server operating system, the Exchange Server prerequisite components, and a copy of the Exchange Server binaries. I then used the image to create my Exchange servers. The process worked, but there was a lot of waste because each resulting VM had its own OS and its own Exchange binaries.

Had I used containers to complete this project, I would have started by creating an OS container image. The OS container image is a base layer that contains the server operating system. Multiple containers can share the same OS container image.

You can think of the OS container image as being similar to a virtual machine image in that the OS container image can be used to create new containers. The difference however, is that when you create a new container from an OS container, you aren’t actually copying the operating system, but rather linking to it.

So let’s pretend that you create an OS image, and then you use it to create a new container. That new container looks and feels like a clean Windows Server VM. Since the goal in this case is to deploy a series of Exchange Servers, you might install the Exchange Server binaries and prerequisites into this container. From there, you could save the container as an image. This image isn’t a full blown Exchange Server. It simply contains the Exchange components and a pointer to an OS image container. It does not have an operating system of its own. Once the Exchange image container has been created, you could use it to create a series of Exchange Server containers, which will ultimately function as Exchange Servers. These containers will contain very little code of their own since the operating system and the Exchange components all reside within parent images.

Conclusion

In this article, I began discussing the concept of container images. In the next article in this series, I will talk more about how container images work.

If you would like to read the other parts in this article series please go to:

• Getting Started with Containers (Part 1)
• Getting Started with Containers (Part 3)
• Getting Started With Containers (Part 4)
• Getting Started With Containers (Part 5)
• Getting Started with Containers (Part 6)
• Getting Started with Containers (Part 7)
• Getting Started With Containers (Part 8)