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.

Server Core Image: Most users will choose the Server Core image, which has the best compatibility for existing, traditional Windows backend applications.

Nano Server Image: Nano server was introduced as a standalone version of Windows before, but it is now only available as a Docker image, following trends. The Nano server image is not a complete Windows operating system. So it does not have many crucial components on Windows, but its efficiency is best among all variations of Windows.

IoT Core Image: If you are looking for Windows 10 IoT and its container feature, this option is your only available choice.

The Windows Image: Windows image has a complete set of Windows operating system in itself, except GUI related features. But, as you guess, the image has a massive size. If you pull the c image every time, it is just like download the full DVD class ISO images from the internet. 😂

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)

openjdk:8-jre-windowsservercore-1809

openjdk:8-jdk-windowsservercore-1809

openjdk:11-jre-windowsservercore-1809

openjdk:11-jdk-windowsservercore-1809 # Python

python:2-windowsservercore-1809

python:3-windowsservercore-1809

https://github.com/rkttu/python-nanoserver # If you looking for Nano Server based Python # Go-lang

golang:windowsservercore-1809 # NATS Message Queue

nats:2-windowsservercore-1809

nats:2-nanoserver-1809

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.

https://support.microsoft.com/en-us/lifecycle/search?alpha=windows%20server

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).