This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.
Best practices
Choosing a Windows Server version
There are two primary release channels available for Windows Server 2019: the Long-Term Servicing Channel and the Semi-Annual Channel.
-
Long-Term Servicing Channel (LTSC) — This is the release model that most customers use in production (formerly called the Long-Term Servicing Branch) where a new major version is released every 2–3 years. With LTSC, there are five years of mainstream support and five years of extended support.
This channel is appropriate for systems that require a longer servicing option and functional stability. Deployments of Windows Server 2019 and earlier versions of Windows Server are not affected by the Semi-Annual Channel releases. The LTSC receives ongoing security and non-security updates, but it does not receive new features and functionality.
-
Semi-Annual Channel — The Semi-Annual Channel is for customers who are innovating quickly to take advantage of new operating system capabilities at a faster pace, especially for containers and microservices. Windows Server products in the Semi-Annual Channel have new releases available twice a year, in spring and fall.
Each release is supported for 18 months from the initial release. Most of the Semi-Annual Channel features are rolled into the next LTSC release of Windows Server. The editions, functionality, and supporting content might vary from release to release. In this model, Windows Server releases are identified by the year and month of release: for example, in 2017, a release in the ninth month (September) would be identified as version 1709.
Note
Microsoft has announced it is dropping Semi-Annual Channel (SAC) releases for Windows Server. Starting with Windows Server 2022 there will be only one release on the LTSC. It will get 10 years’ support (five years mainstream, and five years extended).
Treat container instances as ephemeral servers
Windows administrator and IT professionals are responsible for several tasks that include OS patching, managing backups, restoring tests, and maintaining a healthy state for the applications they manage. These tasks change when using Windows containers and Amazon ECS because the containers should not be treated as an ordinary Windows Server instances. Rather, they should be treated as ephemeral instances that can be frequently removed, added, and replaced.
The Amazon ECS Windows container instance’s sole purpose is to run
containers, which drastically reduces management tasks compared to
a Windows Server directly hosting an application. For example,
when an Amazon ECS cluster is created, an
AWS Auto Scaling group for the cluster is automatically
created, which can be used to scale-in and scale-out the cluster
based on the application’s capacity requirements. Additionally,
EC2 Image Builder
Use multi-stage builds for container images
One of the most challenging parts to building container images is
constraining the image size. Each instruction in the
Dockerfile
A common practice referred to as the builder pattern is to have one Dockerfile for development and a slimmed-down Dockerfile for production that only contains your application and the minimum dependencies required to run it. However, maintaining multiple Dockerfiles introduces surface area for error and adds to the maintenance overhead.
For example, in the following Dockerfile, the first block builds the .NET application and the second block uses the resulting image to build the Windows container image. This process is referred to as multi-stage builds.
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS build WORKDIR /app # copy csproj and restore as distinct layers COPY *.sln . COPY aspnetmvcapp/*.csproj ./aspnetmvcapp/ COPY aspnetmvcapp/*.config ./aspnetmvcapp/ RUN nuget restore # copy everything else and build app COPY aspnetmvcapp/. ./aspnetmvcapp/ WORKDIR /app/aspnetmvcapp RUN msbuild /p:Configuration=Release -r:False FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8 AS runtime WORKDIR /inetpub/wwwroot COPY --from=build /app/aspnetmvcapp/. ./
For more information on Docker best practices, refer to
Docker
development best practices
Caching layer strategy
Windows container images are large, ranging from 3.8 GB on disk for a Windows container image containing .NET framework based on Windows Server SAC edition to 5.1 GB on Windows Server 2019 LTSC. It’s essential to implement a Windows container image layer caching strategy when utilizing EC2 Auto Scaling groups to avoid delays during task launch.
A common strategy is to pre-populate container images on the Amazon Machine Image (AMI) used by the Auto Scaling group to avoid two time-expensive Docker operations:
-
Downloading the image from the repository
-
Extracting the image as layers on the local operating system
The download and extraction phase consumes sequential I/O operations per second on the disk that directly impacts the container instance’s performance until all images are downloaded and extracted. Also, it imposes a delay on the container’s readiness to receive traffic, because the process can take two to five minutes to complete, depending on the size of the image.
The Amazon ECS container instances should be treated as
ephemeral
For more information on caching layer strategy, refer to
Speeding
up Windows container launch times with EC2 Image Builder and image
cache strategy