Key Concepts:

Windows Containers

How are Windows containers different to Linux containers and how can they be used most effectively?

Key points:

  • Despite their similarities to Linux containers, Windows containers introduce additional complexities that must be understood in order to use them in an optimal manner.
  • Process isolation mode should be strongly preferred over Hyper-V isolation mode when building and running Unreal Engine containers.
  • Choose the version of Windows Server that you run on your container hosts carefully to avoid excessive maintenance overheads.

Windows containers are a far newer technology than their more mature Linux counterparts, having first been introduced in Windows Server 2016. The manner in which Windows container images interact with the host system kernel brings with it additional mechanisms and associated complexities which are not present when working with Linux containers. This page provides an overview of the key differences between Windows containers and Linux containers, and provides guidance on how to achieve optimal performance when building and running Windows containers.

Contents

Windows container architecture

The Windows container platform page provides an overview of the key architectural differences between containers running under Windows hosts and those running under Linux hosts. Further technical detail is provided in this DockerCon presentation discussing the initial implementation of container support in Windows. The key architectural differences are summarised below:

Kernel version compatibility

Due to the excellent backward-compatibility of the Linux kernel, Linux containers encapsulating older distributions will continue to work correctly with newer kernel versions. Newer distributions will also often continue to function correctly on older kernel versions, although this will not be the case if the software inside the container relies on newer kernel features that are not present in the older kernel. As a result, the Linux host system needs only to maintain an up-to-date kernel version to ensure maximum compatibility with a wide range of Linux container images 3.

This is not the case for Windows containers. Container images based on older Windows versions will not run on newer host kernel versions, nor will newer containers run on older host kernel versions 4. Microsoft maintains a compatibility table detailing supported host/container configurations, accompanied by a detailed discussion of how Windows container version compatibility works. As can be seen in the compatibility table, older container images can actually be run on newer host systems, but only by utilising a mechanism called Hyper-V isolation mode, which is described in the next section.

Isolation modes

Windows containers can run in one of two “isolation modes”:

Although Hyper-V isolation mode offers the convenience of improved compatibility by decoupling the host kernel from running containers, the use of Hyper-V VMs introduces additional complexities and associated issues. These issues are discussed in the next section.

Hyper-V isolation mode issues

Windows containers are still an evolving technology. This section will be updated over time to reflect any relevant developments.

There are a number of issues present in the current implementation of Hyper-V isolation mode that significantly hinder its suitability for use in production systems:

Windows base image variants

Microsoft provides three primary variants of the Windows base image:

All Windows container images must derive either directly or indirectly from one of these base image variants. (The FROM scratch directive that can be used to create Linux base images is not supported for Windows containers.) It is also worth noting that the filesystem layers for each of the Windows base images are marked as foreign layers, which means they are not stored in private container registries by default and are instead pulled directly from the Microsoft Container Registry.

Hardware acceleration support

This functionality is experimental and currently only available in preview builds. This section will be updated when the functionality is released.

Preview builds of Docker running on the latest versions of Windows Server and Windows 10 feature experimental support for accessing hardware devices inside Windows containers using the --device flag, in a similar manner to how this flag is currently used to expose hardware devices to Linux containers. This functionality is currently limited to containers derived from the mcr.microsoft.com/windows base image that are running in process isolation mode, and does not support other base images or containers running in Hyper-V isolation mode.

The experimental device access functionality includes special treatment of GPU devices, with support for hardware acceleration using the DirectX API. It is important to note that this functionality is not the same as that provided by the NVIDIA Docker runtime for Linux containers, which supports OpenGL, OpenCL, and NVIDIA CUDA.

Recommendations for an optimal experience

References