Microsoft have introduced Windows Containers, which are based on the same technology as Linux containers, but have some gotcha and caveats to them, especially when working with provided Microsoft images.

If you want to learn more about Windows Containers

Size

One of the first differences you will see between Windows and Linux containers, is the size of the container images. 
For example, a Linux container with Nginx might be a few hundred MB, while a Windows container with IIS (the Windows’ webserver) can be several GB.

The Microsoft team has made an effort to create the smallest images possible, but even the smallest image (microsoft/nanoserver) is still 1.17GB. 
And that’s if you’re lucky to not need a bigger image because of dependencies issues.

Indeed, the full .NET framework has a hard dependency on the microsoft/servercore image, which is essentially a packaged version of Windows Server Core, which is a Windows Server version with no GUI. And that image is 13.8 GB in size.

When migrating .NET apps to a Windows container, keep in mind that you will probably need to accommodate large image sizes.

Cross compatibility

One of the big advantage of Linux containers, is that they don’t really care on which version of the Linux kernel they run on, ie, you can have mismatch in Linux versions between your dev and prod setup, and it will still work as expected. 

This is not the case on Windows containers. Microsoft had to make breaking changes to add features to the Windows containers (such as Hyper-V process isolation), so newer images that includes those changes will not run on older hosts.

Log support

On of the big headache we had when moving an Asp.NET website, was the log support of the IIS image, or lack thereof.

When launching an IIS app, the logs are written to logs files in the container, and are not relayed to the standard output of the entrypoint process (which in the IIS case is W3SVC, which will manage and monitor IIS), so you can’t see any logs under “docker logs”.

A solution for bypassing this limitation is detailed in another of our blog articles, here : <link_here>.

CI/CD support

Deploying Windows containers is pretty easy and comparable to Linux containers. Once you’ve got a host with the correct Windows version and Docker agent, it’s virtually identical to running Linux containers.

Building them is an other story though. With a Linux container, a few lines of YAML added to a file in you container repository, and you can build your images automatically with numerous CI/CD SaaS solutions.

Since Windows containers are still pretty new, CI/CD solutions are not supporting it yet. Meaning you will either need to build them by hand, or be well versed in Windows, and write some custom powershell script to build and push it for you, and manage the distribution and execution of this script.

About TrackIt

TrackIt is an Amazon Web Services Advanced Consulting Partner specializing in cloud management, consulting, and software development solutions based in Marina del Rey, CA.

TrackIt specializes in Modern Software Development, DevOps, Infrastructure-As-Code, Serverless, CI/CD, and Containerization with specialized expertise in Media & Entertainment workflows, High-Performance Computing environments, and data storage.

TrackIt’s forté is cutting-edge software design with deep expertise in containerization, serverless architectures, and innovative pipeline development. The TrackIt team can help you architect, design, build and deploy a customized solution tailored to your exact requirements.

In addition to providing cloud management, consulting, and modern software development services, TrackIt also provides an open-source AWS cost management tool that allows users to optimize their costs and resources on AWS.

Contact Us to learn more!

Caveats of Completely Moving an IIS Website to a Windows Container