Choosing Your Base Image in Windows Container

Jung-Hyun Nam
Mar 22 · 3 min read
Photo by Sebastian Herrmann on Unsplash

Most people use the Linux container image every day. But if you encountered the hell named Windows container, you may have headaches. 🤨

I will tell you something that may help you relieve the headaches.

Differences between base images

Microsoft provides four root Windows container foundation images as of the writing this post. Each container image has a unique characteristic.

In short, if your (legacy) application developed with Visual C++, or dependent with Windows SDK, or producing 32-bit build, your container options may be restricted into Server Core image.

But if you are using Python, Go-lang, the .NET Core, or new languages which do not tied-up strictly with Windows APIs, you may choose the Nano Server image instead of Server Core image.

If you decide to choose the Nano server image, you will need to familiar with multi-stage Docker build instead of build up your image directly into the Nano server image.

Do not invent the wheel if you can

Luckily, some of the major software providers and open-source parties respect the Windows container images. I listed some of Windows container images in Docker Hub.

If you cannot find the exact version of your needs, you can also build your image on your own with Dockerfile they published. I repeat, please do not reinvent the wheel if you can.

# OpenJDK (Java)
# Python
# If you looking for Nano Server based Python
# Go-lang
# NATS Message Queue

Image support lifecycle

When I use the Windows container first time, I was confused about the image support lifecycle. In the traditional Windows operating system, if the specific version of Windows reaches its End-of-Support (EOS), usually Microsoft does not guarantee to provide resources from the internet. So I worried about the same for container base image. But it was misunderstood.

As far as I know, Microsoft pushes its own Windows container root image to their server. But without any exceptions, they will not remove the base image without notice. Removing root images from the MCR will cause terrific problems inevitably.

The old Windows container image remains in the MCR repository without any security updates. But this does not mean you can trust the image and the host operating system. Eventually, you will upgrade your host and container images to prevent any unexpected security breaches.

You can find your target Windows version in the below link.

But also, this means you will have to build your application image periodically when the new version of Windows released through the Semi-Annual Channel if you want to use or test the latest version of Windows container.

So I recommend that choosing the LTSC (Long-Term Servicing Channel) version of Windows instead of SAC. This strategy makes some significant gaps, especially for Kubernetes. Still, Microsoft is trying to back-porting crucial features to deliver the best score to customers (such as Direct Server Return based network routing).

Beyond the Windows

DevOps Engineer’s Blog

Jung-Hyun Nam

Written by

DevOps Engineer @ DEVSISTERS, Corp., Microsoft MVP since 2009, Living in S.Korea.

Beyond the Windows

DevOps Engineer’s Blog

More From Medium

More on Docker from Beyond the Windows

More on DevOps from Beyond the Windows

More on DevOps from Beyond the Windows

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade