devops

Windows containers how to...not?

Christopher Simpson

Jun 5, 2023 • 6 min read

Some smashed Windows, barely contained within their frames. Photo by Tara Evans

Things to know about Windows Containers

This started as an initial research into Windows Containers. My initial impression was not fantastic, left wanting.

"Windows requires the host OS version to match the container OS version" (src)
- This is in stark constrast compared to Linux containers, where you can trivially, swap out a Debian based image with a lighter, tighter alpine based image, or even change languages as needs evole (saving you time & money due to lower resource costs, and speed increases)
- The above is also a small lie, you can "use Hyper-V isolation to run older containers on new host builds" (src)
- If that sounds finicky, it is
The default entrypoint for each Windows base OS image is a console, either cmd.exe or PowerShell. (src)
The "latest" tag isn't a thing for Windows container builds. You'll find this weird if you're familiar with the container ecosystem because it breaks the established convention of the latest build of a container image being tagged with latest
It's a mess don't bother- take the plunge and use Linux containers, and a container orchestrator like Kubernetes, Openshift, and pay for training and support to up-skill teams. Unless you have a massive .NET estate (perhaos). Read on for reasoning.

Do I need a licence for my Windows containers?

Not for the containers. You do need a license for the host on which they run, though- and that host has to be Windows.

The warning is quite stern, reminiscent of the familiar shouty MIT licence which fondly shreeks: "THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND" (src).

With Microsoft, a different take- a stern warning to not run Windows containers without a licence:

"You may not use the Container Image if you do not have a corresponding version and edition of the Host License" (src - Microsoft)

So you'd be forgiven for thinking getting the license puts you in a better place than the "NO WARRANTY OF ANY KIND" with Linux containers- but no, even with your shiny Windows licence, the conditions are still as follows:

"The software is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions."The software is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions." (src - Microsoft)

So it's not readily clear what the value-add benefits are to running containers under Windows yet, since we've established flexibility and ease are not one of them.

It's easy to simply not see these very real issues if you're on say, the Microsoft Partner Program which gets you all these 'permissions slips' with no warranty to run containers for a few hundered bucks. But since the ambiguity around container security (how to I update my containers) is so vague, why would you walk the path?

"Microsoft has delayed the scheduled end of support and servicing dates for a number of products to help people and organisations focus their attention on retaining business continuity." - Microsoft Base image servicing life-cycles, April 14th 2020

It's very hard to see Windows containers getting updated at a regular cadence (aka 'SecOps') which is practically a solved problem in the Linux world (read: Container Security, by Liz Rice) and you'll take onboard how to pull, update/upgrade/patch container images and automate that good security process as part of every release- it's so trivial now it's boring. The same simply isn't the case, sadly, for Windows containers in their current form. The "Semi-Annual Channel is a twice-per-year feature update release" simply doesn't cut it for remaining competitive, whilst also having piece of mind for security.

Question if you even need Windows containers at all

If you're embarking on a large modernisation project, realising that the industry is changing around you- and your organisations technology choices are slowing down your competitiveness, then resist the urge to stay with the familiar. You're already considering the change. Take a hard look at your foundations (Windows) and ask the hard questions.

That said, perhaps you have an extremely large, successfully and happy .net code base and you're looking to automate further your build and release process. Perhaps there's room there. Though, if you do have such a significant .NET application(s), by the time your using the official Windows "Server" container image (which is 11.2GB), what are the advantages over creating a VM? It's not clear within the Windows ecosystem at leas- read on to deliberate why.

Are Windows containers even containers?

No. They are not. Linux containers, are an ensemble of Linux kernel constructs (namespaces, croups) which share the host operating kernel to create the illusion of isolation between processes, leaning on namespaces. If that sounds a lot, look at the artwork by Julia Evans 'How Containers Work' :

The result of Linux containers, is you get a semi isolated way to run useful programs on the same hardware with strong-enough promises around isolation for most people. By 'most people' this does not include public cloud providers, where, perhaps surprisingly your containers are, still, in-fact vac-wrapped within the complete isolation of a Virtual Machine. This is in comparison to arguably harder isolation guarantees which are found in operating systems such as Illumos Zones, and FreeBSD bhyve. Regardless, these cgroups, namespaces and the "Open Container Image layout specification" (OCI) primitives allow us to reason about these programs as 'containers'.

Within the Linux container ecosystem, the above results in:

Small, portable container images (as small as a few megabytes)
- In security, there's the concept of 'reducing the attack surface' (less code, less things to go wrong- ship only what you need, and ideally make it imutable)
- If it's not in your container, you don't need to patch it, this is in contrast to the VM approach where, you have everything & the kitchen sink whether you want it or not
- ...you're paying for all that too, by the way- in storage, ingres/egres , attack surface, hard to reproduce bugs etc
Which can be kept up to date (patched)
Unencumbered (licencing restrictions)
Portable- the fact you can run a Linux container image on any host operating system easily (including Windows, bizarrely) puts the flexibility of the approach head over heals of the Windows containers alternative
Code in any language (create python, Rust - even .net) Linux containers

Windows containers don't take that approach, colour is added to the ecosystem with an interesting approach.

"Windows offers four container base images that users can build from. Each base image is a different type of the Windows or Windows Server operating system, has a different on-disk footprint, and has a different set of the Windows API set."
- Container Base Images, Microsoft 2023

By contrast, these images range from 295MB (Nano Server) to > 11GB (the 'Server base' container image'). These sizes vary of course, as updates and patches are released. See "Nano Server x Server Core x Server - Which base image is the right one for you?" - tech community, Microsoft 2021.

The venerable Microsoft has an excellent track record in maintaining backward compatibility, and perhaps this is why it's less trivial to introduce isolation primitives into Windows which Linux and other *Nix systems benefit from making the 'container' abstraction easier to create- they started out as time sharing operating systems, expecting multiple but separate users. This is in stark contrast to Windows which had been single user since it's DOS days, and only eventually was the concept of multi-user added to the operating system- on-top). When you pile so much on top, the straw breaks the camels back. In this case the back is ease of use and an addressable market. That said, Linus famously stated "We don't break userspace", but- to it's history does not suffer from the fundamental disconnect in where this systems began (time sharing vs single user systems).