During my recent discovery of Docker (https://www.docker.com) I quickly found that Microsoft were getting in on the action with Windows containers, or rather they were playing catch up to the Linux world. Being an avid user of the Windows OS I decided to investigate deploying the Umbraco CMS inside a Windows Docker container, why not? As I was new to the world of Docker, and relatively new to Umbraco, this turned out to be slightly more difficult than it sounds.
The first thing to note is that you need the correct version of Windows and the correct version of Docker to be able to use Windows containers. Microsoft only just released support for containers in the Windows Server 2016 OS and Windows 10 OS (as long as you install the Anniversary edition update v1607). You also need v1.13 of Docker for windows installing which was in beta at the time (now available in their stable channel under the newly renamed community edition https://store.docker.com/editions/community/docker-ce-desktop-windows?tab=description).
MSWindows Docker images are LARGE!
Umbraco (https://umbraco.com) is an open source ASP.Net CMS that requires the full .NET v4 framework. This means you need to use the windowsservercore image as your base docker image (https://hub.docker.com/r/microsoft/windowsservercore).
If you are no stranger to the world of Docker the first thing you will notice is the sheer size of the windowsservercore image compared to the Linux based images you are used to.
The base image starts at 9.42GB before you even deploy your application. This can take a minute or so to download depending on your bandwidth. Docker users in the Linux world will be used to images in MB and split second download times. Not a good start Microsoft.
Containers are NOT VMs.
As expected when exploring new technologies, my first go at deploying Umbraco into a container didn’t quite go to plan. What I didn’t appreciate was how much work an error 500 (Internal Server Error) can be when you don’t have a Windows GUI to use. The windowsservercore image is based on the full fat Windows Server 2016 operating system but without any UI.
I admit it, I’ve been a typical Windows UI developer for many years now, only venturing into the command line when absolutely necessary. With Docker this is a skill you absolutely need to master once again.
If I were diagnosing my problem locally, IIS would have given me something a little more meaningful to go off than just a white page showing “error 500”. If this was a production server or a Virtual Machine I would RDP onto the box and fire up IIS there to investigate. So how do I debug IIS remotely without access to IIS or the Windows GUI? Enter Powershell.
What I quickly discovered (with the help of Google) is that it is possible to instruct Windows and IIS to do pretty much anything you want using Powershell. With this newfound knowledge, I set off to create a Docker container that would accept a remote IIS connection in the hope I could then diagnose my problem.
After a few test runs, creating windows user accounts and enabling windows features, I eventually managed to create a container I could connect to remotely. If you would like to see the end or use it feel free to download from the docker hub: https://hub.docker.com/r/phila1/remoteiis/
Once I remotely connected to IIS I quickly discovered I was missing a feature of IIS we use for Umbraco. A quick change to my Umbraco dockerfile and an msi install was all I needed.
Umbraco running in a Docker container, SUCCESS!
MSWindows Containers in Production?
I know I have mentioned this earlier but it does raise an important question. With the large image sizes, the performance of deploying containers in a production environment could be an issue, so should we even be considering using Docker where Windows is concerned?
I know Docker caches images and a Windows container start up time can be under 2 minutes, when ran locally. However, if you use Docker in a cloud-hosted environment (such as Amazon’s ECS service http://aws.amazon.com/ecs) that 10GB image is going to have to be downloaded every time a new EC2 instance is required. That is going to take some bandwidth and some time to deploy your application, time you may not be able to afford.
The main consideration for us here at Tombola is whether we can utilise Docker Windows containers to improve our deployment pipeline. Each development build could be deployed into a container where UI and end to end tests could be ran, to prove the build is in a deployable state before it gets anywhere near our live servers, watch this space.
Remote IIS image: https://hub.docker.com/r/phila1/remoteiis
Umbraco Docker repo: https://github.com/PhilA1/docker-umbraco
ASP.NET Docker scripts: https://github.com/PhilA1/docker-aspmvc