Both Windows Containers feature and Docker, Why?

Have you ever wondered why you still need to install Docker, when you already installed the Windows Container Feature? I have.

Because I’m new to containerization everything is interesting and cool, but not everything is described into detail, and most courses and information just give you the need-to-know knowledge of working with containers. Unfortunately for me, one of my habits is that I like to know the why and how of things.

So, containers on Linux were straight forward, install Docker and you’re good to go. But containers under Windows posed a problem because I needed to install the Windows Container feature and Docker. Why do I need both? Couldn’t I just install Windows Containerization and use that with tools provided by Microsoft as usually is the case? Why do I also need to install Docker? And if I install Docker, why do I still need the Windows Container feature?

These questions arose, because my background is in virtualization, and when you install a hypervisor or app virtualization or desktop virtualization, you’ll get the whole package, there are no dependencies. Apparently, this was different, so I started searching, but there were no direct answers, because – as earlier stated – most of the information is limited to giving you the knowledge on how to run containers and not the deeper workings of the containers.

To answer this question, we must look at how containerization works and the origin of Docker.

Containers work by using the kernel of the host OS directly. So, a container consists of libraries and applications, but is without an OS. To compare this to virtualization where each VM has its own OS and gets resources (CPU time and memory) scheduled by the hypervisor, the container gets its own compartment on the hosts OS kernel assigned by the container software that hooks directly into the kernel. This type of virtualization was first introduced by Virtuozzo in 2001 and open-source projects followed, like OpenVZ in 2005 and LXC in 2008.

In 2013 some people found that LXC was not doing everything they wanted, so they started the dotCloud project – now Docker – as an add-on to LXC. Where LXC took care of the containers, Docker added extra functionality. In the past 7 years Docker evolved and now no longer needs LXC because they made their own container creation software called libcontainer. Both LXC and libcontainer use “cgroups”, which is a Linux kernel feature to create isolated resource usage on a system. This meant that Docker could only run on Linux hosts.

In 2016 Microsoft announced their commercial partnership with Docker (They already had a technical collaboration since October 2014) which meant that from that point on Docker could also be run on Windows. But for Docker to work there had to be a kernel-hook which could create isolated compartments and the Windows kernel did not have the cgroups feature so LXC and libcontainer were no good. That is where the Windows Container feature comes in. The Windows Container feature does what cgroups does on the Linux kernel. And that is why you need both Docker and the Windows Container feature. Sure, Microsoft could have built their own commands for use with the Windows Container feature, but Docker was already an industry standard, so they used Docker for the management of the containers on Windows.

In summary the Windows container feature is the kernel hook in the OS that can create isolated resource compartments a.k.a. containers on the host system, and Docker is used to manage all the images and containers on that host. If you take it a step further, you could use Docker Swarm or Kubernetes to manage multiple Docker hosts (see picture below).

Daniël de Zoete

Started his working life as a system manager at a health care organization. Is now a dedicated technical consultant at PepperByte. Specialist in virtualization and security.

Core qualities
Eager to learn, punctual, fun, loyal, patient

Hobbies
Socializing, watching television series and sports

Job description
Technical Consultant