One of the most important decisions to make when containerizing your windows application is what container OS to use.
To understand this problem one needs to understand what essentially is changing.
- From customer to customer the choice of operating system support options will change between LTSC and SAC.
- From application to application, the technology will change,
Lets have a closer look …
Customer to Customer (LTSC or SAC)
Different customers will have different server operating systems and support agreements in place. The container host will be Windows Server 2016 machine. However there are two categories of support channels to consider. Each of these options resonate with the possible builds of the container host you will find out at a customer. Your container OS must be compatible with the customers infrastructure. (the infrastructure may very well be your own in some cases)
- Basically the Long Term support channel is for the non-early adopters, and non-innovators.
- Updates only include patches and security updates.
- Release cadence is every 2 to 3 years.
- Supported for 5 years.
- Examples: Windows Server 2016, Windows Server 2019
- STSC or SAC
This chart will help you quickly make the correct decision, regarding the support channel your container OS should be using.
Application to Application (NanoServer or ServerCore)
You always want to use the smallest possible container OS, that supports your application. Microsoft container OS ships in two flavors:
- Supports most* server roles.
- Image size between 2 and 5 gig depending on host OS support channel you target.
- Best fit for lift and shift brown field applications
- Supports a limited set of server roles.
- Has a limited dot net run time.
- Built in support for dot net core run-time.
- ASP.net 5.0 is apparently also supported.
- Best fit for the green field applications.
Tag naming convention
Look at the naming convention in below images and see how it resonates with the decision tree, you would use. In this example for an ASP.net Webforms application you will see the following naming convention.
The container you choose will be microsoft/asp.net:4.7.1-windowsservercore-ltsc2160, but at least now you understand how you got there. At the root of our decision tree is the customers support channel, next it is the OS, then finally the core run time requirements for you application.
Always remember you are dealing with a layered file system, so by convention, the tag description should reflect what is in its root. All images in docker-hub for the Microsoft stack follows this convention.
As an architect I am always looking to secure these technical decisions in a fluent programming model, thus nothing prevents us from doing just that.
It is possible to capture such decisions into a layer which in turn will allow us to add some useful utilities into the layer. These utilities are typically used by all the images we will create, example include Url-rewite.
The result is that you only have a handful of images to maintain, making container server patching really easy.