Book Image

Running Windows Containers on AWS

By : Marcio Morales
Book Image

Running Windows Containers on AWS

By: Marcio Morales

Overview of this book

Windows applications are everywhere, from basic intranet applications to high-traffic public APIs. Their prevalence underscores the importance of combining the same tools and experience for managing a modern containerized application with existing critical Windows applications to reduce costs, achieve outstanding operational excellence, and modernize quickly. This comprehensive guide to running and managing Windows containers on AWS looks at the best practices from years of customer interactions to help you stay ahead of the curve. Starting with Windows containers basics, you’ll learn about the architecture design that powers Amazon ECS, EKS, and AWS Fargate for Windows containers. With the help of examples and best practices, you’ll explore in depth how to successfully run and manage Amazon ECS, EKS, and AWS Fargate clusters with Windows containers support. Next, the book covers day 2 operations in detail, from logging and monitoring to using ancillary AWS tools that fully containerize existing legacy .NET Framework applications into containers without any code changes. The book also covers the most common Windows container operations, such as image lifecycle and working with ephemeral hosts. By the end of this book, you’ll have mastered how to run Windows containers on AWS and be ready to start your modernization journey confidently.
Table of Contents (22 chapters)
1
Part 1: Why Windows Containers on Amazon Web Services (AWS)?
4
Part 2: Windows Containers on Amazon Elastic Container Service (ECS)
9
Part 3: Windows Containers on Amazon Elastic Kubernetes Service (EKS)
14
Part 4: Operationalizing Windows Containers on AWS

Understanding Windows container base images

When building your Windows application into a Windows container, it is crucial to assess the dependencies it carries, such as Open Database Connectivity (ODBC) drivers, a Dynamic-Link Library (DLL), and additional applications. These entire packages (meaning the application plus dependencies) will dictate which Windows container image must be used.

Microsoft offers four container base images, each exposing a different Windows API set, drastically influencing the final container image size and on-disk footprint:

  • Nano Server is the smallest Windows container base image available, exposing just enough APIs to support .NET Core or other modern open source frameworks. It is a great option for sidecar containers.
  • Server Core is the most common Windows container base image available. It exposes the Windows API set to support the .NET Framework and common Windows Server features, such as IIS.
  • Server is smaller than the Windows image but has the full Windows API set. It fits, in the same use case mentioned previously, applications that require a DirectX graphics API.
  • Windows is the largest image and exposes the full Windows API set. It is usually used for applications that require a DirectX graphics API and frameworks such as DirectML or Unreal Engine. There is a very cool community project specifically for this type of workload, which can be accessed at the following link: https://unrealcontainers.com/.

Important note

The Windows image is not available for Windows Server 2022, as Server is the only option for workloads that require a full Windows API set.

Enumerating the Windows container image sizes

You have probably already heard about how big Windows container images are compared to Linux. While, technically, the differences in sizes are exorbitant, it doesn’t bring any value to the discussion since we won’t address Windows-specific needs with Linux, and vice versa. However, selecting the right Windows container base image directly affects the solution cost, especially regarding the storage usage footprint, drastically influencing the container host storage allocation.

Let’s delve into Windows container image sizes. The values in the following table are based on Windows Server 2022 container images:

Image name

Image size

Extracted on disk

Nano Server

118 MB

296 MB

Server Core

1.4 GB

4.99 GB

Windows Server

3.28 GB

10.8 GB

Table 1.1 – Windows container image sizes

As discussed in the previous section, the difference in size refers to the amount of the Windows API set exposed to the container, addressing different application needs. The Extracted on disk column is crucial information because, on AWS, one of the price compositions for the block storage called Amazon Elastic Block Storage (EBS) is the amount of space provisioned; you pay for what you provision, independent of whether it is used or not, thereby influencing the EBS volume size you will deploy on each container host.

We’ll dive deep into this topic in greater detail in Chapter 14, Implementing a Container Image Cache Strategy.