Edit

Share via

Windows and containers

Applies to: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Containers are a technology for packaging and running Windows and Linux applications across diverse environments on-premises and in the cloud. Containers provide a lightweight, isolated environment that makes apps easier to develop, deploy, and manage. Containers start and stop quickly, making them ideal for apps that need to rapidly adapt to changing demand. The lightweight nature of containers also makes them a useful tool for increasing the density and utilization of your infrastructure.

Graphic showing how containers can run in the cloud or on-premises, supporting monolithic apps or microservices written in nearly any language.

The Microsoft container ecosystem

Microsoft provides many tools and platforms to help you develop and deploy apps in containers:

How containers work

A container is an isolated, lightweight package for running an application on the host operating system. Containers run on top of the host operating system's kernel (which you can think of as the buried plumbing of the operating system), as shown in the following diagram.

Architectural diagram showing how containers run on top of the kernel

While a container shares the host operating system's kernel, the container doesn't get unfettered access to it. Instead, the container gets an isolated–and in some cases virtualized–view of the system. For example, a container can access a virtualized version of the file system and registry, but any changes affect only the container and are discarded when it stops. To save data, the container can mount persistent storage such as an Azure Disk or a file share like Azure Files.

A container builds on top of the kernel, but the kernel doesn't provide all of the APIs and services an app needs to run. Most of these APIs and services come from system files (libraries) that run above the kernel in user mode. Because a container is isolated from the host's user mode environment, the container needs its own copy of these user mode system files. These files are packaged into something known as a base image. The base image serves as the foundational layer upon which you build your container, providing it with operating system services not provided by the kernel.

Containers vs. virtual machines

In contrast to a container, a virtual machine (VM) runs a complete operating system–including its own kernel–as shown in the following diagram.

Architectural diagram showing how VMs run a complete operating system beside the host operating system

Containers and virtual machines each have their uses. In fact, many deployments of containers use virtual machines as the host operating system rather than running directly on the hardware, especially when running containers in the cloud.

For more information on the similarities and differences of these complementary technologies, see Containers vs. virtual machines.

Container images

You create all containers from container images. A container image is a bundle of files organized into a stack of layers that resides on your local machine or in a remote container registry. A container image consists of the user mode operating system files that your app needs to run. The image also includes your app's runtimes, dependencies, and any configuration files that your app requires.

Microsoft offers several images (called base images) that you can use as a starting point to build your own container image:

  • Windows - contains the full set of Windows APIs and system services (minus server roles).
  • Windows Server - contains the full set of Windows APIs and system services.
  • Windows Server Core - a smaller image that contains a subset of the Windows Server APIs–namely the full .NET framework. It also includes most but not all server roles (for example Fax Server isn't included).
  • Nano Server - the smallest Windows Server image and includes support for the .NET Core APIs and some server roles.

Container images are composed of a series of layers. Each layer contains a set of files that, when overlaid together, represent your container image. Because of the layered nature of containers, you don't always have to target a base image to build a Windows container. Instead, you can target another image that already carries the framework you want. For example, the .NET team publishes a .NET core image that carries the .NET core runtime. It saves users from needing to duplicate the process of installing .NET core–instead they can reuse the layers of this container image. The .NET core image itself is built based upon Nano Server.

For more information, see Container Base Images.

Container users

Containers for developers

Containers help developers build and ship higher-quality apps, faster. With containers, developers can create a container image that deploys in seconds, identically across environments. Containers act as an easy mechanism to share code across teams and to bootstrap a development environment without impacting your host filesystem.

Containers are portable and versatile, can run apps written in any language, and they're compatible with any machine running Windows 10, version 1607 or later, or Windows Server 2016 or later. Developers can create and test a container locally on their laptop or desktop, and then deploy that same container image to their company's private cloud, public cloud, or service provider. The natural agility of containers supports modern app development patterns in large-scale, virtualized cloud environments. The most useful benefit to developers is perhaps the ability to isolate your environment so that your app always gets the version of libraries that you specify, avoiding conflicts with dependencies.

Containers for IT professionals

Containers help admins create infrastructure that's easier to update and maintain, and that more fully utilizes hardware resources. IT professionals can use containers to provide standardized environments for their development, QA, and production teams. By using containers, systems administrators abstract away differences in operating system installations and the underlying infrastructure.

You can also use the interactive mode of containers to run conflicting instances of a command line tool on the same system.

Container orchestration

Orchestrators are a critical piece of infrastructure when setting up a container-based environment. Orchestrators are essential when managing containerized apps at scale. While you can manage a few containers manually using Docker and Windows, apps often make use of five, ten, or even hundreds of containers, making orchestrators indispensable.

Container orchestrators were built to help manage containers at scale and in production. Orchestrators provide functionality for:

Orchestrators help you grow containerized apps at scale, providing functionality for:

  • Deploying at scale
  • Workload scheduling
  • Health monitoring
  • Failing over when a node fails
  • Scaling up or down
  • Networking
  • Service discovery
  • Coordinating app upgrades
  • Cluster node affinity

There are many different orchestrators that you can use with Windows containers; here are the options Microsoft provides:

Try containers on Windows

To get started with containers on Windows Server or Windows 10, see the following article:

Get started: Configure Your Environment for Containers

For help with deciding which Azure services are right for your scenario, see Azure container services and Choosing what Azure services to use to host your application.

Resources

To view resources for using Windows Server containers, see the following resources:

  • Last updated on