Reducing the size of Windows Server Container Images – Part 2

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Previously we announced our first major step in reducing the size of the Windows Server Container images by ~40%. Today, we are pleased to announce our next step in this direction by making our delta layers 60-80% smaller while reducing total image size by about 40% as part of the February 2023 release. These images are now available in MCR (Server Core, Windows, Server).

 

One of the primary techniques we use to reduce the size of Windows container image is to split our images into two layers (except Nano Server). Rather than shipping the entire image each month, we ship a baseline image occasionally (like we did in January 2023) and a monthly delta, which contains OS updates made since the last baseline image. So long as the machine in question has already downloaded the baseline image, it will not need to fetch it again and can just pull the monthly delta layer. By optimizing the composition of these delta layers, we are able to achieve improved download times for these month-to-month updates.

 

Container Images

Compressed size of delta layer (in GB)

Difference in size of delta layer

December 2022

February 2023

Windows Server 2019 Server Core

0.78

0.23

~71% smaller

Windows Server 2022 Server Core

0.93

0.27

~71% smaller

Windows Server 2019 Windows

2.57

1.03

~60% smaller

Windows Server 2022 Server

2.25

0.85

~62% smaller

 

How was this achieved?

The concept behind the delta layer is that only a small percentage of files are serviced; thus, the delta layer should be relatively small compared to the baseline image. Unfortunately, in practice, the delta layer was much larger than desired. A careful analysis was conducted to understand why more files than expected were included in the delta layer. The investigation concluded that although many files had no changes in content, various metadata associated with these files had changed, causing our algorithm to include the file in the delta image.

 

Based on these observations, we started looking for ways to avoid including these files in the delta layer. The first observation was that particular metadata is not material and could be filtered out of the hashes used to determine if a file has changed. In other cases, we found ways to make small compensating actions in the delta layer rather than including updated files. In addition to the algorithmic changes mentioned above, we also identified content that was not needed in a container scenario and could be excluded. These improvements significantly reduced the number of files included in the delta layer resulting in a much smaller delta layer size.

 

Closing

We hope you find value in our pursuit of offering the smallest Windows container images possible. While this is our first significant step, it is just the beginning. We strive to learn from your valuable feedback and engagement with the broader community.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.