Explaining Windows containers

During this chapter, we have focused on software containers within Linux operating systems. Software containers started on Linux systems, but due to their importance and advances in technology in terms of host resource usage, Microsoft introduced them in the Microsoft Windows Server 2016 operating system. Before this, Windows users and administrators were only capable of using software containers for Linux through virtualization. Thus, there was the Docker Toolbox solution, of which Docker Desktop formed a part, and installing this software on our Windows-based computer allowed us to have a terminal with the Docker command line, a fancy GUI, and a Hyper-V Linux virtual machine where containers would run. This made it easy for entry-level users to use software containers on their Windows desktops, but Microsoft eventually brought in a game-changer here, creating a new encapsulation model.

Important note

Container runtimes are client-server applications, so we can serve the runtime to local (by default) and remote clients. When we use a remote runtime, we can use our clients to execute commands on this runtime using different clients, such as docker or nerdctl, depending on the server side. Earlier in this chapter, we mentioned that desktop solutions such as Docker Desktop or Rancher Desktop use this model, running a container runtime server where the common clients, executed from common Linux terminals or Microsoft PowerShell, can manage software containers running on the server side.

Microsoft provided two different software container models:

• Hyper-V Linux Containers: The old model, which uses a Linux virtual machine
• Windows Server Containers, also known as Windows Process Containers: This is the new model, allowing the execution of Windows operating-system-based applications

From the user’s perspective, the management and execution of containers running on Windows are the same, no matter which of the preceding models is in use, but only one model can be used per server, thus applying to all containers on that server. The differences here come from the isolation used in each model.

Process isolation on Windows works in the same way it does on Linux. Multiple processes run on a host, accessing the host’s kernel, and the host provides isolation using namespaces and resources control (along with other specific methods, depending on the underlying operating system). As we already know, processes get their own filesystem, network, processes identifiers, and so on, but in this case, they also get their own Windows registry and object namespace.

Due to the very nature of the Microsoft Windows operating system, some system services and dynamic linked libraries (DLLs) are required within the containers and cannot be shared from the host. Thus, process containers need to contain a copy of these resources, which makes Windows images quite a lot bigger than Linux-based container images. You may also encounter some compatibility issues within image releases, depending on which base operating system (files tree) was used to generate it.

The following schema represents both models side by side so that we can observe the main stack differences:

Figure 1.8 – A comparison of Microsoft Windows software container models

We will use Windows Server containers when our application requires strong integration with the Microsoft operating system, for example, for integrating Group Managed Service Accounts (gMSA) or encapsulating applications that don’t run under Linux hosts.

From my experience, Windows Server containers became very popular when they initially arrived, but as Microsoft improved the support of their applications for Linux operating systems, the fact that developers could create their applications in .NET Core for either Microsoft Windows or Linux, and the lack of many cloud providers offering this technology, made them almost disappear from the scene.

It is also important to mention that orchestration technology evolution helped developers move to Linux-only containers. Windows Server containers were supported only on top of Docker Swarm until 2019 when Kubernetes announced their support. Due to the large increase of Kubernetes’ adoption in the developer community and even in enterprise environments, Windows Server container usage reduced to very specific and niche use cases.

Nowadays, Kubernetes supports Microsoft Windows Server hosts running as worker roles, allowing process container execution. We will learn about Kubernetes and host roles in Chapter 8, Deploying Applications with the Kubernetes Orchestrator. Despite this fact, you will probably not find many Kubernetes clusters running Windows Server container workloads.

We mentioned that containers improve application security. The next section will show you the improvements at the host and container levels that make containers safer by default.