Running Windows Containers on AWS E-Book

Marcio Morales

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 197

Veröffentlichungsjahr: 2023

Beschreibung

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.

Leseprobe

Running Windows Containers on AWS

A complete guide to successfully running Windows containers on Amazon ECS, EKS, and AWS Fargate

Marcio Morales

BIRMINGHAM—MUMBAI

Running Windows Containers on AWS

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Mohd Riyan Khan

Publishing Product Manager: Suwarna Rajput

Senior Editor: Runcil Rebello

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Jyoti Chauhan

Marketing Coordinator: Agnes D’souza

First published: April 2023

Production reference:1240323

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-413-6

www.packtpub.com

To my sons, Christian and Matheus, for showing me how talent and creativity evolve. To my wife, Amanda, for being my loving partner throughout our joint life journey.

– Marcio Morales

Contributors

About the author

Marcio Morales is a principal specialist solution architect at AWS, focusing on container services such as Amazon ECS, EKS, and AWS Fargate, helping customers modernize legacy infrastructure to modern cloud-native solutions. Before this, Marcio spent his entire career as a Microsoft consultant, implementing and migrating solutions such as Active Directory, Exchange Server, Hyper-V, System Center, and Azure. Additionally, during the night shifts, Marcio worked for 8 years as a Microsoft Certified Trainer (MCT), teaching more than 2,000 individuals with official Microsoft Official Courseware (MOC) on various topics.

Marcio holds more than 30 certifications, including Microsoft, AWS, Terraform, and Kubernetes certifications. He also has a bachelor’s degree in computer networking and an MBA in network architecture and cloud computing.

I want to thank the people who have been close to me and supported me, especially my wife, Amanda, and my parents.

About the reviewer

Joshua Brewer is currently a cloud support engineer at Amazon Web Services. Before joining AWS, he was an active-duty member of the United States Air Force, where he specialized in virtual desktop infrastructure. He has more than five years of virtualization/containerization experience. He gained an MSc in cloud computing architecture from the University of Maryland Global Campus. Josh is responsible for helping enterprise organizations successfully implement containerized workloads in AWS.

I am grateful for what I get to do on a daily basis. Since I first got my feet wet in the tech industry after joining the military, I have been on a constant journey where I have had to learn, adapt, and repeat. I am thankful for all the individuals who have aided my development during this journey. I am also extremely thankful for my family, who have supported me every step of the way.

Table of Contents

Preface

Part 1: Why Windows Containers on Amazon Web Services (AWS)?

1

Windows Container 101

Why are Windows containers an important topic?

How does Windows Server expose container primitives?

How Windows Server implements resource controls for Windows containers

Understanding Windows container base images

Enumerating the Windows container image sizes

Delving into Windows container licensing on AWS

Summary

Further reading

2

Amazon Web Services – Breadth and Depth

Why AWS for Windows containers?

Understanding how AWS Nitro impacts container performance

Learning about AWS container orchestrators

Summary

Part 2: Windows Containers on Amazon Elastic Container Service (ECS)

3

Amazon ECS – Overview

Technical requirements

Amazon ECS – fundamentals

Amazon ECS – task networking

Deploying an Amazon ECS cluster with Terraform

Why Terraform?

Deploying the AWS services

Summary

4

Deploying a Windows Container Instance

Technical requirements

Amazon ECS-optimized Windows AMIs

Amazon ECS agent

Right-sizing a Windows container instance

Storage

Processor

Memory

Network

Deploying a Windows container instance with Terraform

Deploying security groups

Summary

5

Deploying an EC2 Windows-Based Task

Technical requirements

Understanding a task definition

Task placement strategies

Task placement constraints

Setting up AD integration

Windows containers and gMSA integration

Setting up persistent storage

Scheduling an EC2 Windows-based task with Terraform

Deploying an EC2 Windows-based task definition

Deploying an ECS service

Deploying an Application Load Balancer

Summary

6

Deploying a Fargate Windows-Based Task

Technical requirements

AWS Fargate overview

Process isolation mode

Hyper-V isolation mode

Planning for serverless Windows containers

Fargate Windows-based task start-up time

Fargate Windows-based task image pull time

AWS Fargate Windows-based task use cases

Scheduling a Fargate Windows-based task definition with Terraform

Deploying a Fargate Windows-based task definition

Deploying an ECS service

Deploying an ALB

Summary

Part 3: Windows Containers on Amazon Elastic Kubernetes Service (EKS)

7

Amazon EKS – Overview

Amazon EKS – fundamentals

Control plane

Data plane

Amazon VPC CNI for Windows

Amazon EKS and Windows support

Personal thoughts

Summary

8

Preparing the Cluster for OS Interoperability

Setting up the VPC CNI plugin for Windows support

Avoiding pod-scheduling disruption

Using nodeSelector to avoid pod-schedule disruption

Using taints and tolerations to avoid pod schedule disruption

Dynamically scaling out Windows pods

Summary

9

Deploying a Windows Node Group

Technical requirements

Amazon EKS node groups

Amazon EKS-optimized Windows AMIs

Consuming an EKS-optimized Windows AMI using Terraform

Understanding the EKS Windows bootstrap

Working with persistent storage using CSI drivers

SMB CSI driver high-level overview

Managing persistent volumes on Kubernetes

Deploying an Amazon EKS cluster with Windows nodes using Terraform

Creating security groups

Creating an OpenID Connect endpoint and IAM roles for the cluster

Creating instance roles for Windows and Linux node groups

Enabling VPC CNI Windows support

Using ConfigMap to add Kubernetes permissions (RBAC) to a node level

Creating a launch template to launch and bootstrap Windows and Linux Amazon EC2 nodes

Creating an Auto Scaling group

Summary

10

Managing a Windows Pod

Technical requirements

Exploring Windows host and Pod resource management

Pod memory management

Pod CPU management

Host CPU management

System resource reservations

Understanding the Runtime Class use case

Understanding Active Directory integration on Kubernetes

Credential specs

Deploying a Windows Pod on Amazon EKS

Connecting to the Amazon EKS cluster

Deploying the Windows Pod

Summary

Part 4: Operationalizing Windows Containers on AWS

11

Monitoring and Logging

Implementing LogMonitor

Implementing log forwarding

The awslogs driver as a log processor

Fluent Bit as a log processor

Using Amazon CloudWatch Container Insights

Summary

12

Managing a Windows Container's Image Life Cycle

Understanding Microsoft Patch Tuesday

Security patch compliance on Windows container images

Rebuilding your container image frequently

Summary

13

Working with Ephemeral Hosts

The idea behind ephemeral hosts

Why custom AMIs

Building a custom AMI pipeline

Summary

14

Implementing a Container Image Cache Strategy

Why is implementing a container image cache strategy important?

Container runtime pull throttling

Layer extraction is a serial operation

Layer extraction is CPU/disk intensive when Windows Defender antivirus is enabled

Speeding up a Windows container startup time

Extending EC2 Image Builder with custom components

Summary

15

AWS Windows Containers Deployment Tools

Deploying an Amazon EKS cluster with eksctl

Containerizing Windows applications with AWS App2Container

Deploying Windows containers with AWS Copilot

Summary

Index

Other Books You May Enjoy

Part 1: Why Windows Containers on Amazon Web Services (AWS)?

In this part, you will get a Windows containers technical overview, covering the operational system primitives and how Windows Server isolates and implements resource control for Windows containers. In addition, you will learn how Windows containers on AWS are a relevant topic for customers’ application modernization journeys.

This part has the following chapters:

Chapter 1, Windows Container 101Chapter 2, Amazon Web Services – Breadth and Depth

1

Windows Container 101

In this chapter, we’re going to cover the foundations of a Windows container and why it is an essential topic for DevOps engineers and solution architects. The chapter will cover the following topics:

Why are Windows containers an important topic?How Windows Server exposes container primitivesHow Windows Server implements resource controls for Windows containersUnderstanding Windows container base imagesDelving into Windows container licensing on AWSSummary

Why are Windows containers an important topic?

Have you ever asked yourself, “Why should I care about Windows containers?” Many DevOps engineers and solution architects excel in Linux containerization, helping their companies with re-platforming legacy Linux applications into containers to architect, deploy, and manage complex microservices environments. However, many organizations still run tons of Windows applications, such as ASP.NET websites or .NET Framework applications, which are usually left behind during the modernization journey.

Through many customer engagements I have had in the past, there were two main aspects that meant Windows containers weren’t an option for DevOps engineers and solution architects.

The first was a lack of Windows operational system expertise in the DevOps team. Different system administrators and teams usually manage Windows and Linux, each using the tools that best fit their needs. For instance, a Windows system administrator will prefer System Center Configuration Manager (SCCM) as a Configuration Management solution. In contrast, a Linux system administrator would prefer Ansible.

Another example: a Windows system administrator would prefer System Center Operations Manager (SCOM) for deep insights, monitoring, and logging, whereas a Linux system administrator would prefer Nagios and an ELK stack. With the rapid growth of the Linux ecosystem toward containers, it is a natural and more straightforward career shift that a Linux system administrator needs to take in order to get up to speed as a DevOps engineer, whereas Windows system administrators aren’t exposed to all these tools and evolutions, making it a hard and drastic career shift, where you have to first learn about the Linux operating system (OS) and then the entire ecosystem around it.

The second aspect is the delusion that every .NET Framework application should be refactored to .NET (formerly .NET Core). In almost all engagements where the .NET Framework is a topic, I’ve heard developers talking about the beauty of refactoring their .NET Framework application into .NET and leveraging all the benefits available on a Linux ecosystem, such as ARM processors and the rich Linux tools ecosystem. While they are all 100% technically correct, as solution architects, we need to see the big picture, meaning the business investment behind it. We need to understand how much effort and investment of money will be required to fully refactor the application and its dependencies to move out of Windows, what will happen with the already purchased Windows Server licenses and management tools, and when the investment will break even. Sometimes, the annual IT budget will be better spent on new projects rather than refactoring 10-year-old applications, where the investment breakeven will take 5 or more years to come through, without much innovation on the application itself.

Now that we understand the most common challenges for Windows container adoption and the opportunity in front of us, we’ll dig into the Windows Server primitives for Windows containers, resource controls, and Windows base images.

How does Windows Server expose container primitives?

Containers are kernel primitives responsible for containerization, such as control groups, namespaces, union filesystems, and other OS functionalities. These work together to create process isolation provided through namespace isolation and control groups, which govern the resources of a collection of processes within a namespace.

Namespaces isolate named objects from unauthorized access. A named object provides processes to share object handles. In simple words, when a process needs to share handles, it creates a named event or mutex in the kernel; other processes can use this object name to call functions inside the process, then an object namespace creates the boundary that defines what process or container process can call the named objects.

Control groups or cgroups are a Linux kernel feature that limits and isolates how much CPU, memory, disk I/O, and network a collection of the process can consume. The collection process is the one running in the container:

Figure 1.1 – How a container runtime interacts with the Linux kernel

However, when it relates to the Windows OS, this is an entirely different story; there is no cgroup, pid, net, ipc, mnt, or vfs. Instead, in the Windows world, we call them job objects (the equivalent of cgroups), object namespaces, the registry, and so on. Back in the days when Microsoft planned how they would effectively expose these low-level Windows kernel APIs so that the container runtime could easily consume them, Microsoft decided to create a new management service called the Host Compute Service (HCS). The HCS provides an abstraction to the Windows kernel APIs, making a Windows container a single API call from the container runtime to the kernel:

Figure 1.2 – How a container runtime interacts with the Windows kernel

Working directly with the HCS may be difficult as it exposes a C API. To make it easier for container runtime and orchestrator developers to consume the HCS from higher-level languages such as Go and C#, Microsoft released two wrappers:

hcsshim is a Golang interface to launch and manage Windows containers using the HCSdotnet-computevirtualization is a C# class library to launch and manage Windows containers using the HCS

Now that you understand how Windows Server exposes container primitives and how container runtimes such as Docker Engine and containerd interact with the Windows kernel, let’s delve into how Windows Server implements resource controls at the kernel level for Windows containers.

How Windows Server implements resource controls for Windows containers

In order to understand how Windows Server implements resource controls for Windows containers, we first need to understand what a job object is. In the Windows kernel, a job object allows groups of processes to be managed as a unit, and Windows containers utilize job objects to group and track processes associated with each container.

Resource controls are enforced on the parent job object associated with the container. When you are running the Docker command to execute memory, CPU count, or CPU percentage limits, under the hood, you are asking the HCS to set these resource controls in the parent job object directly:

Figure 1.3 – Internal container runtime process to set resource controls

Resources that can be controlled include the following:

The CPU/processorMemory/RAMDisk/storageNetworking/throughput

The previous two topics gave us an understanding of how Windows Server exposes container primitives and how container runtimes such as Docker Engine and containerd interact with the Windows kernel. However, you shouldn’t worry too much about this. As a DevOps engineer and solution architect, it is essential to understand the concept and how it differs from Linux, but you will rarely work at the Windows kernel level when running Windows containers. The container runtime will take care of it for you.

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.