Blog

The eight practices for Containerized Delivery on the Microsoft stack – PRACTICE 3: Keep your Windows Containers up-to-date

06 Apr, 2018
Xebia Background Header Wave

This post is originally published as article within SDN Magazine on October 13th, 2017.
During the past year I supported several clients in their journey toward Containerized Delivery on the Microsoft stack. In this blogseries I’d like to share eight practices I learned while practicing Containerized Delivery on the Microsoft stack using Docker, both in a Greenfield and in a Brownfield situation. In the third blogpost of this series I want to talk about Keeping your Windows Containers up-to-date.

PRACTICE 3: Keep your Windows Containers up-to-date

If you work with or start working with Windows containers you may wonder how to implement an update strategy to deal with Windows updates. Because containers are meant to be stateless and immutable, you can’t run Windows Update within your container. So what is the solution?
In contrast to Linux container images where people can create a container image from scratch, each Windows container image you create should be based on one of the base images (currently nanoserver or windowsservercore ) that were created by Microsoft. Similar to Windows Updates, those base images are updated by Microsoft on a regular basis in order to roll out the latest security and bug fixes. This is one of the reasons why you should always use one of Microsoft’s base images instead of creating your own. As part of the containerized delivery way of- working, you have to put a process in place to ensure that you update your image references to the latest Windows base images on a regular basis.
out-of-date base image
I recommend my clients to use the docker pull command to automatically pull the latest Microsoft base images each time they have to build an image which is directly dependent on it. This ensures that you always build those container images using the latest OS base images and including all security and bug fixes. For all other container images that depend on those “internal base images”, you have to put a process in place to ensure that they always use one of the most recent internal base images.
Most of the times when I discuss this approach, I get the question: “So we have to download that 10 Gigs of base image each time for each update?” Luckily this is not the case. When you execute the docker inspect command against the base images, you will see that they consist of two layers: one big base layer that will be used for a longer period of time and another smaller update layer that contains small patches and that is updated constantly by Microsoft. So updating to a newer Windows base image version is not painful as it is only pulling the latest update layer from Docker Hub.
layers of base image
Interested in the next practice? See PRACTICE 4: Group Managed Service Accounts.

Cornell Knulst
Cornell works for Xpirit, Hilversum, The Netherlands, as a trainer/architect. He is specialized in the domain of Application Lifecycle Management and Continuous Delivery, with a special focus on Microsoft-based technologies.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts