Choosing Your Base Image in Windows Container

Jung-Hyun Nam
Mar 22 · 3 min read
Image for post
Image for post
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
# If you looking for Nano Server based Python
https://github.com/rkttu/python-nanoserver
# 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).

Beyond the Windows

DevOps Engineer’s Blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store