Запуск приложений в контейнере в windows

Время на прочтение
6 мин

Количество просмотров 35K

Когда я разговариваю с Linux инженерами и говорю им о проблемах Kubernetes кластера на Windows, на меня смотрят очень подозрительно. Некоторые даже не верят что

это законно

такое бывает. Контейнеры на Windows не так распространены и востребованы, как на Linux. Но я думаю, что поговорить об этой теме стоит, хотя бы для того, что бы понимать общую концепцию и основные отличия контейнеров Windows и Linux. Первой записью я пройдусь по полотну широкой кистью, а затем, в последующих постах, попробую постепенно углубиться в нюансы.

Контейнеры в Windows

Согласно данной статье:

Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux

Действительно, контейнеры в Windows до недавнего времени были экзотикой. А хуже всего то, что документацию приходилось собирать по крохам, на каждом ресурсе будь то официальный сайт Docker или Microsoft, всё представлялось в обзорном виде без описания «как и почему», а через месяц-два и существующая информация устаревала. И в этом нет ничего сверхъестественного – контейнеры и технологии с ними связанные развиваются с какой-то нереальной скоростью.

В настоящий момент с документацией все стало лучше и что бы погрузится в мир контейнеров для Windows достаточно почитать официальную документацию от Microsoft и следить за её изменениями. Что интересно, документация написана хорошо и на русском языке, хотя при глубоком изучении вам не избежать переходов по ссылкам на различные ресурсы по типу https://www.docker.com/ или https://kubernetes.io/ где всё написано на старом добром английском языке.

Сейчас ответы на любые вопросы можно найти в официальной документации, но есть некоторые нюансы, которые лучше знать заранее. Возможно вам это будет полезно и сэкономит время при погружении в контейнерные технологии под флагом Microsoft.

Вы не можете запускать контейнеры Windows на Linux и на Windows*

Контейнерные технологии позволяют легко обращаться с окружением благодаря наличию переконфигурированных образов приложений. Это как Apple Appstore или Google Play, но только для инженеров и разработчиков. Как и в магазинах для мобильных приложений вы не можете поставить приложение из Google Play на iOS. Так и на Docker хосте с операционной системой Linux вы не можете запустить контейнер с операционной Windows. Верно и обратное утверждение, правда с некоторыми «но», так как Docker хост с Windows всё же может предоставить Linux окружение для запуска контейнеров.

Так же вы не можете запустить контейнер Windows в среде Windows не убедившись в совместимости версий операционной системы. Работая с контейнерами от Microsoft вам придется оглядываться на Windows Container Version Compatibility и периодически открывать данный документ.

Говоря о версионности — Microsoft с приходом контейнеров приняла решение о выпуске новых полугодовых версий Windows semi-annual. Это такие версии как windows server 1703, 1709, 1803, 1809, 1903. Цифры означают год и месяц выхода, а поддерживаются они по 18 месяцев. Первые две уже покоятся с миром и находятся в end of service. Кроме того, существуют версии LTS такие как Windows Server 2016 и Windows Server 2019. Список версий.

Так вот, если вы собрали контейнер на хосте с версией Windows 1803, то и запустить данный контейнер вы можете только на хостах с Windows 1803. Соответственно, чтобы не пересобирать каждый раз сам контейнер вам придется использовать LTS версию Windows, что при современных скоростях развития технологий не всегда оправдано. Либо всё же думать о версионности и таки постоянно пересобирать контейнеры следуя шаг в шаг за программой semi-annual.

Тэг latest в Dokerfile для Windows контейнеров присутствует не всегда и вообще он deprecated. По-хорошему вам всегда надо знать, что у вас за версия Windows и вносить соответствующие правки в Dockerfile.

Контейнеры — это часть подхода «Инфраструктура как код». Пересобирать контейнеры нужно постоянно, это не только просто и весело, но в этом и заключается основная магия, которая позволяет приложениям всегда работать на свежем улучшенном софте. Но в нашем случае мы сталкиваемся с ограничением: не получится держать универсальный Dockerfile под все системы Windows. Это необходимо учитывать.

Всё вышесказанное справедливо для контейнеров, запущенных в режиме process isolation. В режиме Hyper-V isolation действует обратная совместимость – вы можете запускать все контейнеры, которые собраны на текущей и предыдущей версиях. В общем-то с помощью Hyper-V isolation можно на хосте Windows запускать и Linux контейнеры. Но такой режим пока что поддерживает меньше плюшек, чего только стоит отсутствие Kubernetes.

Отличие process isolation и Hyper-V isolation это тема отдельной статьи. Сейчас скажу только то, что сценарии с Hyper-V isolation мне не совсем очевидны, а по умолчанию в Windows используется process isolation.

Отдельной головной болью является поиск правильных по версии образов на Docker Hub. Некоторые образы вообще отсутствуют для Windows. Например, официальной сборки Nginx, MySQL, Nodejs, как и сотни других приложений под Windows вы не найдете и вам придется собирать контейнеры самостоятельно либо использовать контейнеры, собранные и предоставленные участниками сообщества.

Windows стоит денег.

Не стоит забывать и о том, что Windows это по-прежнему платная штука. К примеру, Semi-annual версии доступны по подписке Visual Studio или при наличии Software Assurance в действующем лицензионном контракте Microsoft. Ссылка.

Но у Microsoft есть большое количество способов получит платное за бесплатно. Это и программа BizSpark и всякие trial версии Windows Server 2019 на 180 дней и прочее и прочее.

Контейнеры Windows не легковесны.

Принято считать, что контейнеры легковесны, но что правда для Linux не всегда правда для Windows. Подавляющее большинство контейнеров Windows, на первый взгляд весит непозволительно много. Да и на второй взгляд впечатление не меняется. Например, базовый образ aspnet:4.8 весит порядка 7.5 Гб.

Даже если вы будете размещать базовые образы в локальном репозитории, первоначальная загрузка образа на хост будет занимать довольно продолжительное время, что уж говорить про удаленные репозиторий типа Docker Hub.

Да вы можете в некоторых сценариях использовать легковесный Windows Nano Server, но увы он имеет кучу ограничений. И тем более вам не по пути с Windows Nano Server если вы разрабатываете под .Net Framework.

Для управления надо хорошо знать CMD и Powershell.

Скорее всего работать вам придется с core версией Windows Server на Docker хостах. Windows Server имеет огромное количество возможностей по удаленному управлению. Общий подход такой, что имея Windows Server с графическим интерфейсом вы можете подключатся всеми графическими оснастками к любому core серверу.

Данный подход не работает в сценариях с контейнерами, хотя в контейнере и находится полноценная версия Windows Server. Внутрь контейнера Windows теоретически можно подключится по WMI, но это не так просто, хотя бы потому что хостовая ОС будет перехватывать данный трафик на себя. Контейнеров на хосте может быть несколько десятков и сотен, и в таком случае направлять трафик в нужный контейнер это целое дело.

CMD и Powershell понадобятся как для администрирования контейнеров так и самого хоста на котором установлен Docker. Так же знание данных оболочек необходимо для написания Dockerfile, так как все инструкции RUN будут выполнятся в вышеупомянутых командных оболочках.

Запомнить все длинные командлеты Powershell довольно сложно. Это вам не лаконичные команды bash. Хотя сейчас большинство командлетов имеет понятные любому Linux инженеру алиасы. В powershell можно использовать:

rm вместо Remove-Item
pwd вместо Get-Location.
cat вместо Get-Content 
touch вместо New-Item
etc.
# ключи данных команд из Linux вам тут без пользы. Команда rm –rf не прокатит.
# но в Powershell есть аналог man в котором можно всё посмотреть
Get-Help <командлет>

Из крайне полезных вещей, это то, что с помощью Powershell можно запустить в контейнере простой веб сервер для целей тестирования. В Powershell всё представляется в виде объектов. Если вы сторонник ООП, то вы быстро оцените преимущества этой командной оболочки.

В качестве заключения вводной статьи хочу сказать что я нарочно не касался вопроса оркестрации и управления кластерам. Docker на Windows находится в роли догоняющего и приложения по оркестрации такие как Swarm и Kubernetes на Windows реализуют не полный свой функционал.

Так же на текущий момент если вы хотите поднять кластер Docker, то он скорее всего будет мульти платформенный. То есть вам придется иметь в кластере один или более хостов с операционной системой Linux. Например, для Kubernetes, мастер ноды обязаны быть на Linux. А в Swarm, Linux контейнеры понадобятся, например, для реализации балансировщика на Nginx или запуска других популярных приложений для кластера, которые доступны только для Linux.

P.S. Использование Windows в контейнерах имеет весьма ограниченный набор сценариев для применения. Тем не менее эти сценарии могут оказаться крайне продуктивными. Конечно, первое что приходит на ум это web приложения на IIS, но мой опыт показывает, что в контейнерах хорошо изолируются самописные службы Windows и некоторые сервисы такие как MSMQ.

UPD. В статье есть небольшая неточность, кластер Docker на одних только Windows хостах собрать можно. Причем, это не только Swarm, но и развиваемый самим Micrisoft продукт для оркестрации кластера Service Fabric

UPD2. Docker контейнеры для Windows 10 доступны только в режиме Hyper-V isolation и используют отличные от Windows Server базовые образы.

Today, Microsoft announced the general availability of Windows Server 2016, and with it, Docker engine running containers natively on Windows. This blog post describes how to get setup to run Docker Windows Containers on Windows 10 or using a Windows Server 2016 VM. Check out the companion blog posts on the technical improvements that have made Docker containers on Windows possible and the post announcing the Docker Inc. and Microsoft partnership.

Before getting started, It’s important to understand that Windows Containers run Windows executables compiled for the Windows Server kernel and userland (either windowsservercore or nanoserver). To build and run Windows containers, a Windows system with container support is required.

Windows 10 with Anniversary Update

For developers, Windows 10 is a great place to run Docker Windows containers and containerization support was added to the the Windows 10 kernel with the Anniversary Update (note that container images can only be based on Windows Server Core and Nanoserver, not Windows 10). All that’s missing is the Windows-native Docker Engine and some image base layers.

The simplest way to get a Windows Docker Engine is by installing the Docker for Windows public beta (direct download link). Docker for Windows used to only setup a Linux-based Docker development environment (slightly confusing, we know), but the public beta version now sets up both Linux and Windows Docker development environments, and we’re working on improving Windows container support and Linux/Windows container interoperability.

With the public beta installed, the Docker for Windows tray icon has an option to switch between Linux and Windows container development. For details on this new feature, check out Stefan Scherers blog post.

Switch to Windows containers and skip the next section.

Windows Server 2016

Windows Server 2016 is the where Docker Windows containers should be deployed for production. For developers planning to do lots of Docker Windows container development, it may also be worth setting up a Windows Server 2016 dev system (in a VM, for example), at least until Windows 10 and Docker for Windows support for Windows containers matures.

For Microsoft Ignite 2016 conference attendees, USB flash drives with Windows Server 2016 preloaded are available at the expo. Not at ignite? Download a free evaluation version and install it on bare metal or in a VM running on Hyper-V, VirtualBox or similar. Running a VM with Windows Server 2016 is also a great way to do Docker Windows container development on macOS and older Windows versions.

Once Windows Server 2016 is running, log in, run Windows Update to ensure you have all the latest updates and install the Windows-native Docker Engine directly (that is, not using “Docker for Windows”). Run the following in an Administrative PowerShell prompt:

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Install-Module -Name DockerMsftProvider -Force
Install-Package -Name docker -ProviderName DockerMsftProvider -Force
Restart-Computer -Force

Docker Engine is now running as a Windows service, listening on the default Docker named pipe. For development VMs running (for example) in a Hyper-V VM on Windows 10, it might be advantageous to make the Docker Engine running in the Windows Server 2016 VM available to the Windows 10 host:

# Open firewall port 2375
netsh advfirewall firewall add rule name="docker engine" dir=in action=allow protocol=TCP localport=2375

# Configure Docker daemon to listen on both pipe and TCP (replaces docker --register-service invocation above)
Stop-Service docker
dockerd --unregister-service
dockerd -H npipe:// -H 0.0.0.0:2375 --register-service
Start-Service docker

The Windows Server 2016 Docker engine can now be used from the VM host by setting DOCKER_HOST:

$env:DOCKER_HOST = "<ip-address-of-vm>:2375"

See the Microsoft documentation for more comprehensive instructions.

Running Windows containers

First, make sure the Docker installation is working:

> docker version
Client:
Version:      1.12.1
API version:  1.24
Go version:   go1.6.3
Git commit:   23cf638
Built:        Thu Aug 18 17:32:24 2016
OS/Arch:      windows/amd64
Experimental: true

Server:
Version:      1.12.2-cs2-ws-beta
API version:  1.25
Go version:   go1.7.1
Git commit:   62d9ff9
Built:        Fri Sep 23 20:50:29 2016
OS/Arch:      windows/amd64

Next, pull a base image that’s compatible with the evaluation build, re-tag it and to a test-run:

docker pull microsoft/windowsservercore
docker run microsoft/windowsservercore hostname
69c7de26ea48

Building and pushing Windows container images

Pushing images to Docker Cloud requires a free Docker ID. Storing images on Docker Cloud is a great way to save build artifacts for later user, to share base images with co-workers or to create build-pipelines that move apps from development to production with Docker.

Docker images are typically built with docker build from a Dockerfile recipe, but for this example, we’re going to just create an image on the fly in PowerShell.

"FROM microsoft/windowsservercore `n CMD echo Hello World!" | docker build -t <docker-id>/windows-test-image -

Test the image:

docker run <docker-id>/windows-test-image
Hello World!

Login with docker login and then push the image:

docker push <docker-id>/windows-test-image

Images stored on Docker Cloud available in the web interface and public images can be pulled by other Docker users.

Using docker-compose on Windows

Docker Compose is a great way develop complex multi-container consisting of databases, queues and web frontends. Compose support for Windows is still a little patchy and only works on Windows Server 2016 at the time of writing (i.e. not on Windows 10).

To develop with Docker Compose on a Windows Server 2016 system, install compose too (this is not required on Windows 10 with Docker for Windows installed):

Invoke-WebRequest https://dl.bintray.com/docker-compose/master/docker-compose-Windows-x86_64.exe -UseBasicParsing -OutFile $env:ProgramFiles\docker\docker-compose.exe

To try out Compose on Windows, clone a variant of the ASP.NET Core MVC MusicStore app, backed by a SQL Server Express 2016 database. A correctly tagged microsoft/windowsservercore image is required before starting.

git clone https://github.com/friism/Musicstore
...
cd Musicstore
docker-compose -f .\docker-compose.windows.yml build
...
docker-compose -f .\docker-compose.windows.yml up
...

To access the running app from the host running the containers (for example when running on Windows 10 or if opening browser on Windows Server 2016 system running Docker engine) use the container IP and port 5000. localhost will not work:

docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" musicstore_web_1
172.21.124.54

If using Windows Server 2016 and accessing from outside the VM or host, simply use the VM or host IP and port 5000.

Summary

This post described how to get setup to build and run native Docker Windows containers on both Windows 10 and using the recently published Windows Server 2016 evaluation release. To see more example Windows Dockerfiles, check out the Golang, MongoDB and Python Docker Library images.
Please share any Windows Dockerfiles or Docker Compose examples your build with @docker on Twitter using the tag #windows. And don’t hesitate to reach on the Docker Forums if you have questions.

More Resources:

• Sign up to be notified of GA and the Docker Datacenter for Windows Beta
• Docker for Windows Server
• Learn more about the Docker and Microsoft partnership

Свершилось! То ли молитвы помогли, то ли жертвоприношения, но теперь можно запускать Docker контейнеры с Windows внутри. Прекрасная новость пришла одновременно с релизом Windows Server 2016. И речь не идёт о какой-нибудь хитро-спрятанной виртуальной машине, или эмуляции Windows на Linux ядре — запускается настоящая Windows в настоящем Docker, с работающими Dockerfile, docker-compose и прочими docker-приблудами.

Ограничения

Но это не значит, что теперь можно запускать любой контейнер где угодно. Из-за того, что Docker контейнеры «отдалживают» ядро операционной системы у своего хоста (а иначе им пришлось бы иметь свою ОС и превращаться в виртуальную машину), Windows контейнеры можно запускать только на свежих Windows 10 Pro Anniversary Update и Windows Server 2016.

Второй момент, запустить нативно Linux контейнер на Windows всё еще нельзя. В Anniversary Update есть собственная Linux подсистема (с помощью которой можно запустить настоящий Bash, например), но она не дотягивает для полноценного Linux-ядра, так что для того же контейнера с Убунтой на Windows всё еще нужна спрятанная виртуальная машина.

Наконец, одновременно запускать те и другие контейнеры на Windows машине можно, но с танцем. Если выполнить такую команду в Windows Server 2016 с установленным Docker (год назад я бы обозвал такое колдовством), оно сработает:

Но если после этой команды попробовать запустить Ubuntu контейнер, Docker взгрустнёт:

Проблема в том, что Windows и Linux контейнера обслуживаются разными Docker-демонами, которые, тем не менее, используют один и тот же канал для общения с командной строкой. То есть в каждый момент времени только один демон может быть активным. На официальном Докер-сайте есть бета «Docker for Windows«,  которая пытается справиться проблемой (пока только на Windows 10 Pro и Enterprise). Но даже с ней, чтобы переключиться с Windows на Linux контейнеры, нужно либо лезть в меню настроек, либо общаться с командной строкой:

Пока есть только два базовых образа с контейнерной Windows:

• microsoft/windowsservercore
• microsoft/nanoserver

Сделать свой базовый образ (scratch image) — нельзя.

Образ Windows Server Core весит аж 10 гигов и в целом ведёт себя как полноценная Windows Server 2016. Например, MS SQL и полноценный .NET Framework устанавливаются там без проблем. Если ваше приложение не сильно зависит от UI, то установится и оно.

Nano Server слегка интереснее. Это очень оптимизированная и урезанная Windows Server, которая весит меньше гига. Но и ограничений хватает: нет 32-битных приложений, UI, RDP, порезаный PowerShell, и т.д. Но это не мешает поставить на Nano Server тот же IIS, .NET Core, и даже какой-нибудь MySQL.

И кто-нибудь мог представить пару лет назад, что в Dockerfile можно будет встретить сразу «Microsoft», «Windows» и «PowerShell»?

Это же Windows в Докере! До сих пор звучит абсурдно.

Степени изоляции

Windows контейнера можно запускать в двух режимах изоляции:

• Windows Server Containers
• Hyper-V Containers

В первом режиме Windows контейнера ведут себя так же, как и все остальные контейнера в Docker: делят общее ядро с операционной системой, контейнерные процессы изолированы, но всё еще видны в хостовом дереве процессов, и т. п. Это дефолтный и самый быстрый способ запустить контейнер в Windows.

Во втором случае контейнера попадают особую Hyper-V виртуальную машину. Это, конечно, плохо сказывается на скорости запуска, но зато и изоляция полная.

Заключение

Windows в Докере — это просто отличные новости. Даже если не бросаться упаковывать свои продукты по контейнерам, это прекрасный инструмент для того, чтобы изолировать свои юнит-тесты, рабочие машины, сервера для демонстраций, песочницы — всё то, для чего раньше приходилось создавать виртуальную машину. Если Microsoft еще умудрится запустить nanoserver на Linux, то я им прощу недавнее снятие с производства Microsoft Band 2, неосмотрительно купленный за два месяца до этого.

You can run any application in Docker as long as it can be installed and executed unattended, and the base operating system supports the app. Windows Server Core runs in Docker which means you can run pretty much any server or console application in Docker.

TL;DR

Update! For a full walkthrough on Dockerizing Windows apps, check out my book Docker on Windows and my Pluralsight course Modernizing .NET Apps with Docker.

Check out these examples:

• openjdk:windowsservercore — Docker image with the Java runtime on Windows Server Core, by Docker Captain Stefan Scherer
• elasticsearch:nanoserver — Docker image with a Java app on Nano Server
• kibana:windowsservercore — Docker image with a Node.js app on Windows Server Core
• nats:nanoserver — Docker image with a Go app on Nano Server
• nerd-dinner — Docker image with an ASP.NET app on Windows Server Core
• dotnetapp — Docker image with a .NET Core app on Nano Server

The 5 Steps

Lately I’ve been Dockerizing a variety of Windows apps — from legacy .NET 2.0 WebForms apps to Java, .NET Core, Go and Node.js. Packaging Windows apps as Docker images to run in containers is straightforward — here’s the 5-step guide.

1. Choose Your Base Image

Docker images for Windows apps need to be based on microsoft/nanoserver or microsoft/windowsservercore, or on another image based on one of those.

Which you use will depend on the application platform, runtime, and installation requirements. For any of the following you need Windows Server Core:

• .NET Framework apps
• MSI installers for apps or dependencies
• 32-bit runtime support

For anything else, you should be able to use Nano Server. I’ve successfully used Nano Server as the base image for Go, Java and Node.js apps.

Nano Server is preferred because it is so drastically slimmed down. It’s easier to distribute, has a smaller attack surface, starts more quickly, and runs more leanly.

Being slimmed down may have problems though — certain Windows APIs just aren’t present in Nano Server, so while your app may build into a Docker image it may not run correctly. You’ll only find that out by testing, but if you do find problems you can just switch to using Server Core.

Unless you know you need Server Core, you should start with Nano Server. Begin by running an interactive container with docker run -it --rm microsoft/nanoserver powershell and set up your app manually. If it all works, put the commands you ran into a Dockerfile. If something fails, try again with Server Core.

Derived Images

You don’t have to use a base Windows image for your app. There are a growing number of images on Docker Hub which package app frameworks on top of Windows.

They are a good option if they get you started with the dependencies you need. These all come in Server Core and Nano Server variants:

• microsoft/iis — basic Windows with IIS installed
• microsoft/aspnet — ASP.NET installed on top of IIS
• microsoft/aspnet:3.5 — .NET 3.5 installed and ASP.NET set up
• openjdk — OpenJDK Java runtime installed
• golang — Go runtime and SDK installed
• microsoft/dotnet — .NET runtime and SDK installed.

A note of caution about derived images. When you have a Windows app running in a Docker container, you don’t connect to it and run Windows Update to apply security patches. Instead, you build a new image with the latest patches and replace your running container. To support that, Microsoft release regular updates to the base images on Docker Hub, tagging them with a full version number (10.0.14393.693 is the current version).

Base image updates usually happen monthly, so the latest Windows Server Core and Nano Server images have all the latest security patches applied. If you build your images from the Windows base image, you just need to rebuild to get the latest updates. If you use a derived image, you have a dependency on the image owner to update their image, before you can update yours.

If you use a derived image, make sure it has the same release cadence as the base images. Microsoft’s images are usually updated at the same time as the Windows image, but official images may not be.

Alternatively, use the Dockerfile from a derived image to make your own «golden» image. You’ll have to manage the updates for that image, but you will control the timescales. (And you can send in a PR for the official image if you get there first).

2. Install Dependencies

You’ll need to understand your application’s requirements, so you can set up all the dependencies in the image. Both Nano Server and Windows Server Core have PowerShell set up, so you can install any software you need using PowerShell cmdlets.

Remember that the Dockerfile will be the ultimate source of truth for how to deploy and run your application. It’s worth spending time on your Dockerfile so your Docker image is:

• Repeatable. You should be able to rebuild the image at any time in the future and get exactly the same output. You should specify exact version numbers when you install software in the image.
• Secure. Software installation is completely automated, so you should make sure you trust any packages you install. If you download files as part of your install, you can capture the checksum in the Dockerfile and make sure you verify the file after download.
• Minimal. The Docker image you build for your app should be as small as possible, so it’s fast to distribute and has a small surface area. Don’t install anything more than you need, and clean up any installations as you go.

Adding Windows Features

Windows features can be installed with Add-WindowsFeature. If you want to see what features are available for an image, start an interactive container with docker run -it --rm microsoft/windowsservercore powershell and run Get-WindowsFeature.

On Server Core you’ll see that .NET 4.6 is already installed, so you don’t need to add features to run .NET Framework applications.

.NET is backwards-compatible, so you can use the installed .NET 4.6 to run any .NET application, back to .NET 2.0. In theory .NET 1.x apps can run too. I haven’t tried that.

If you’re running an ASP.NET web app but you want to use the base Windows image and control all your dependencies, you can add the Web Server and ASP.NET features:

RUN Add-WindowsFeature Web-server, NET-Framework-45-ASPNET, Web-Asp-Net45  

Downloading Files

There’s a standard pattern for installing dependencies from the Internet — here’s a simple example for downloading Node.js into your Docker image:

ENV NODE_VERSION="6.9.4" `  
    NODE_SHA256="d546418b58ee6e9fefe3a2cf17cd735ef0c7ddb51605aaed8807d0833beccbf6"

WORKDIR C:/node

RUN Invoke-WebRequest -OutFile node.exe "https://nodejs.org/dist/v$($env:NODE_VERSION)/win-x64/node.exe" -UseBasicParsing; `  
    if ((Get-FileHash node.exe -Algorithm sha256).Hash -ne $env:NODE_SHA256) {exit 1} ;

The version of Node to download and the expected SHA-256 checksum are captured as environment variables with the ENV instruction. That makes it easy to upgrade Node in the future — just change the values in the Dockerfile and rebuild. It also makes it easy to see what version is present in a running container, you can just check the environment variable.

The download and hash check is done in a single RUN instruction, using Invoke-WebRequest to download the file and then Get-FileHash to verify the checksum. If the hashes don’t match, the build fails.

After these instructions run, your image has the Node.js runtime in a known location — C:\node\node.exe. It’s a known version of Node, verified from a trusted download source.

Expanding Archives

For dependencies that come packaged, you’ll need to install them as part of the RUN instruction. Here’s an example for Elasticsearch which downloads and uncompresses a ZIP file:

ENV ES_VERSION="5.2.0" `  
    ES_SHA1="243cce802055a06e810fc1939d9f8b22ee68d227" `
    ES_HOME="c:\elasticsearch"

RUN Invoke-WebRequest -outfile elasticsearch.zip "https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-$($env:ES_VERSION).zip" -UseBasicParsing; `  
    if ((Get-FileHash elasticsearch.zip -Algorithm sha1).Hash -ne $env:ES_SHA1) {exit 1} ; `
    Expand-Archive elasticsearch.zip -DestinationPath C:\ ; `
    Move-Item c:/elasticsearch-$($env:ES_VERSION) 'c:\elasticsearch'; `
    Remove-Item elasticsearch.zip

It’s the same pattern as before, capturing the checksum, downloading the file and checking the hash. In this case, if the hash is good the file is uncompressed with Expand-Archive, moved to a known location and the Zip file is deleted.

Don’t be tempted to keep the Zip file in the image, «in case you need it». You won’t need it — if there’s a problem with the image you’ll build a new one. And it’s important to remove the package in the same RUN command, so the Zip file is downloaded, expanded and deleted in a single image layer.

It may take several iterations to build your image. While you’re working on it, it’s a good idea to store any downloads locally and add them to the image with COPY. That saves you downloading large files every time. When you have your app working, replace the COPY with the proper download-verify-delete RUN pattern.

Installing MSIs

You can download and run MSIs using the same approach. Be aware that not all MSIs will be built to support unattended installation. A well-built MSI will support command-line switches for any options available in the UI, but that isn’t always the case.

If you can install the app from an MSI you’ll also need to ensure that the install completed before you move on to the next Dockerfile instruction — some MSIs continue to run in the background. This example from Stefan Scherer’s iisnode Dockerfile uses Start-Process ... -Wait to run the MSI:

RUN Write-Host 'Downloading iisnode' ; \  
    $MsiFile = $env:Temp + '\iisnode.msi' ; \
    (New-Object Net.WebClient).DownloadFile('https://github.com/tjanczuk/iisnode/releases/download/v0.2.21/iisnode-full-v0.2.21-x64.msi', $MsiFile) ; \
    Write-Host 'Installing iisnode' ; \
    Start-Process msiexec.exe -ArgumentList '/i', $MsiFile, '/quiet', '/norestart' -NoNewWindow -Wait

3. Deploy the Application

Packaging your own app will be a simplified version of step 2. If you already have a build process which generates an unattended-friendly MSI, you can can copy it from the local machine into the image and install it with msiexec:

COPY UpgradeSample-1.0.0.0.msi /

RUN msiexec /i c:\UpgradeSample-1.0.0.0.msi RELEASENAME=2017.02 /qn  

This example is from the Modernize ASP.NET Apps — Ops Lab from Docker Labs on GitHub. The MSI supports app configuration with the RELEASENAME option, and it runs unattended with the qn flag.

With MSIs and other packaged deployment options (like Web Deploy) you need to choose between using what you currently have, or changing your build output to something more Docker friendly.

Web Deploy needs an agent installed into the image which adds an unnecessary piece of software. MSIs don’t need an agent, but they’re opaque, so it’s not clear what’s happening when the app gets installed. The Dockerfile isn’t an explicit deployment guide if some of the steps are hidden.

An xcopy deployment approach is better, where you package the application and its dependencies into a folder and copy that folder into the image. Your image will only run a single app, so there won’t be any dependency clashes.

This example copies an ASP.NET Web app folder into the image, and configures it with IIS using PowerShell:

RUN New-Item -Path 'C:\web-app' -Type Directory; `  
    New-WebApplication -Name UpgradeSample -Site 'Default Web Site' -PhysicalPath 'C:\web-app'

COPY UpgradeSample.Web /web-app  

If you’re looking at changing an existing build process to produce your app package, you should think about building your app in Docker too. Consolidating the build in a multi-stage Dockerfile means you can build your app anywhere without needing to install .NET or Visual Studio.

See Dockerizing .NET Apps with Microsoft’s Build Images on Docker Hub.

4. Configure the Entrypoint

When you run a container from an image, Docker starts the process specified in the CMD or ENTRYPOINT instruction in the Dockerfile.

Modern app frameworks like .NET Core, Node and Go run as console apps — even for Web applications. That’s easy to set up in the Dockerfile. This is how to run the open source Docker Registry — which is a Go application — inside a container:

CMD ["registry", "serve", "config.yml"]  

Here registry is the name of the executable, and the other values are passed as options to the exe.

ENTRYPOINT and CMD work differently and can be used in conjunction. See how CMD and ENTRYPOINT interact to learn how to use them effectively.

Starting a single process is the ideal way to run apps in Docker. The engine monitors the process running in the container, so if it stops Docker can raise an error. If it’s also a console app, then log entries written by the app are collected by Docker and can be viewed with docker logs.

For .NET web apps running in IIS, you need to take a different approach. The actual process serving your app is w3wp.exe, but that’s managed by the IIS Windows service, which is running in the background.

IIS will keep your web app running, but Docker needs a process to start and monitor. In Microsoft’s IIS image they use a tool called ServiceMonitor.exe as the entrypoint. That tool continually checks a Windows service is running, so if IIS does fail the monitor process raises the failure to Docker.

Alternatively, you could run a PowerShell startup script to monitor IIS and add extra functionality — like tailing the IIS log files so they get exposed to Docker.

5. Add a Healthcheck

HEALTHCHECK is one of the most useful instructions in the Dockerfile and you should include one in every app you Dockerize for production. Healthchecks are how you tell Docker if the app inside your container is healthy.

Docker monitors the process running in the container, but that’s just a basic liveness check. The process could be running, but your app could be in a failed state — for a .NET Core app, the dotnet executable may be up but returning 503 to every request. Without a healthcheck, Docker has no way to know the app is failing.

A healthcheck is a script you define in the Dockerfile, which the Docker engine executes inside the container at regular intervals (30 seconds by default, but configurable at the image and container level).

This is a simple healthcheck for a web application, which makes a web request to the local host (remember the healthcheck executes inside the container) and checks for a 200 response status:

HEALTHCHECK CMD powershell -command `  
    try { `
     $response = iwr http://localhost:80 -UseBasicParsing; `
     if ($response.StatusCode -eq 200) { return 0} `
     else {return 1}; `
    } catch { return 1 }

Healthcheck commands need to return 0 if the app is healthy, and 1 if not. The check you make inside the healthcheck can be as complex as you like — having a diagnostics endpoint in your app and testing that is a thorough approach.

Make sure your HEALTHCHECK command is stable, and always returns 0 or 1. If the command itself fails, your container may not start.

Any type of app can have a healthcheck. Michael Friis added this simple but very useful check to the Microsoft SQL Server Express image:

HEALTHCHECK CMD [ "sqlcmd", "-Q", "select 1" ]  

The command verifies that the SQL Server database engine is running, and is able to respond to a simple query.

There are additional advantages in having a comprehensive healthcheck. The command runs when the container starts, so if your check exercises the main path in your app, it acts as a warm-up. When the first user request hits, the app is already running warm so there’s no delay in sending the response.

Healthchecks are also very useful if you have expiry-based caching in your app. You can rely on the regular running of the healthcheck to keep your cache up-to date, so you could cache items for 25 seconds, knowing the healthcheck will run every 30 seconds and refresh them.

Summary

Dockerizing Windows apps is straightforward. The Dockerfile syntax is clean and simple, and you only need to learn a handful of instructions to build production-grade Docker images based on Windows Server Core or Nano Server.

Following these steps will get you a functioning Windows app in a Docker image — then you can look to optimizing your Dockerfile.