Almost every week I'm faced with this question from customers: Which Windows base container image is the right one for me? For that reason, I decided to write this blog post to help customers understand the differences between the three Windows container base images, its use cases, and pros and cons from each one.
Before we get started, it's important to note that in many cases, there is a framework image that leverages these images above. The most common examples are .Net Framework, ASP. Net, .Net (formerly .Net Core), among many others.
What are the base container images
Base images are used (as the name suggests) as basis for the framework and application you want to host. They dictate which OS APIs are available for your application and it could be a large or a small set of APIs. The more APIs are available, the more binaries are needed, resulting in a larger base image. For that reason, when we started to produce these base images we had Server Core and Nano Server, with the Server image being added later to address scenarios not supported by the former images.
Nano Server base container image
This is our smallest base container image. As mentioned above, this means less APIs available. For Nano Server, we focused on scenarios where developers will be writing new applications on which the framework can target the specific APIs of Nano Server. Examples of frameworks, languages, or apps that are supported on Nano Server are .Net Core (now called .Net), Apache, NodeJS, Phyton, Tomcat, Java runtime, JBoss, Redis, among others.
Once pulled and extracted, the Nano Server base image has around 290MB in size. That means its pull time is extremely fast, allowing for faster scale-up processes. The other side of this is the already mentioned requirement that only specific frameworks will be supported in this base image.
To provide some history, the Nano Server is actually based on a previously available Nano Server installation option. We discontinued this option a few years ago specifically to focus on the Nano Server base container image. Overall, the general question I recommend customers to ask when developing new applications is to always check if the Nano Server provides the necessary APIs for that application. If so, choose this image as the benefits of a smaller image are great.
Server Core base container image
In this case, the scenario expected is different than the Nano Server base image. The Server Core base container image is based on the Server Core installation. This image is focused on lift and shift scenarios, on which the expectation is to get the same application that was working on a VM and put it in a container - as is/no code changes. Of course there's a bunch of limitations here. For example, if the application did not work on Server Core already, it most likely won't work on the Server Core base container image.
More importantly, the Server Core base image supports .Net Framework, which is the framework used on most of the existing (not to say, legacy) applications out there. We see a lot of customers using this image to containerize applications from the Windows Server 2008 era. Not surprisingly, web applications written in ASP.Net 3.5.
The Server Core image has around 4.8GB after pulled and extracted, which means longer pull times, adding up to the total time of scale-up operations. However, the larger API area should be your target here. Just like on the Nano Server, I have some guidance on this image I provide to customers: First, check if the application you're trying to containerize works on regular Server Core deployments. If not, containers might not be an option here. If it does, you should still make sure you try out the application on a Server Core container to check if the app is not trying to use something from the OS that was removed when building the base container image.
Server base container image
This is our largest image, by a lot - but for all the good reasons. This image is based on the "Server with Desktop Experience" installation mode. Of course, the GUI is not present, but the UI APIs are there. This image enables a whole new set of scenarios, including support to GPU via DirectX.
Another interesting scenario enabled by this image is UI automation tests for developers. As mentioned before, you don't get a GUI with this image - rather, the UI APIs are present for UI automation tests to work. Also, some UI automation tools might not be supported on Windows containers at all. If you are familiar with such tools and you know one that doesn't work with Windows containers, please let us know as we're interested in these scenarios.
Of course, the compromise on the Server image is the total size of around 11.2GB, once its layers are downloaded and extracted. On the other hand, think of this base image as your an alternative to containerize an existing app that is not supported on Server Core. The question I ask customers here is: Does the app works on Server Core? If not, try the Server image as that should probably work. See that we start by giving the Server Core a try, as the size would be a great benefit. If it doesn't, the Server image should do the work.
Why not say the exact size of these images?
It's easy to fall on the temptation of comparing image sizes for comparison sake. However, just like on regular servers, you should not simply install your system and let it go. Containers are subject to Patch Tuesday and in fact, Microsoft updates these base images every month with security updates. That means you should be updating your production systems composed by containers every month to leverage these security updates. The way you perform that is a topic for another blog post, but the point here is that given these monthly changes, the size of the base container images will vary. Some months we gain some, some months we lose some. The fact that these images have around 290MB (Nano Server), 4.8GB (Server Core), and 11.2GB (Server) should give you a ballpark on what to expect in terms of size. Furthermore, these image layers are compacted for pulling operations (download) so the size that does over the wire is smaller than what you see on disk.
|Nano Server||Server Core||Server|
|Size (uncompressed on disk)||~290MB||4.8GB||11.2GB|
|Based on (installation mode)||Nano Server||Server Core||Server with Desktop|
|Scenarios||New applications being developed for Nano Server||Lift and Shift, web applications||Lift and Shift, GPU dependent apps, UI automation|
|Examples||.Net (formerly .Net Core)||.Net Framework, ASP.Net Framework||.Net Framework, DirectX, ML based applications|
As always, let us know if you have questions or comments, either in the comments section below or in our GitHub repo.
Some of you might have noticed I left the already known "Windows" image out of the article. That was on purpose, but I wanted to comment on that image so it doesn't create any confusion for current customers. Currently, Microsoft has 4 main base images for Windows containers, the already covered Nano Server, Server Core, and Server. The last one is the Windows image, which is not available for the Windows Server 2022 wave - reason why I chose not to cover it originally.
The Windows image has the same essence of the Server image already discussed above. It's base however, was different and over the time, we decided to reshape that into what is the Server image today.
If you are a customer using Windows containers for the purposes already explained in the Server image above (Lift and Shift, GPU support, ML, or anything that might need a larger API set from the OS) you have two options:
Hopefully that clarifies the use case as well as which image to use on this scenario.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.