Update 2021/2/10: Microsoft stopped creating images for Docker in the summer of 2020. We now publish artifacts, which can be used to spin up containers and BcContainerHelper has replaced NavContainerHelper. This blog post reflects the old way of using NAV/BC on Docker and references NavContainerHelper, which is outdated.
As of yesterday evening Windows Server version 1709 (with and without Containers) is available on Azure:
I thought it would be a good idea to describe how this relates to the NAV on Docker images recently published on the Docker Hub.
Before diving into the details, please read this blog post which talks about the Windows as a Service model and how Microsoft builds, deployed and services Windows. The model talks about the Long-term Servicing Channel (LTSC) and the Semi-Annual Channel.
The available release channels are different for each Windows Server installation option:
|Installation option||Semi-Annual Channel (Windows Server)||Long-term Servicing Channel (Windows Server 2016)|
|Server with Desktop||No||Yes|
Meaning, that if you deploy a Windows Server 1709 you will get a Server Core and will only be able to get a command prompt.
With No Desktop, I mean no meaningful desktop. You actually can remote desktop into an Azure VM with Windows Server 1709, you just get a desktop with a command prompt:
and if you press Ctrl+Alt+End you get a good old “last century style” menu:
The Task Manager you get from selecting Task Manager in the menu gives you valuable info about your server and services.
The Task Manager does provide one cute extra feature, which is very useful: File -> Run New Task
Launch that in order to start another command or PowerShell prompt.
If you look at the tags on Docker Hub for windowsservercore, you will find 2 major versions:
As described in this blog post, there are 2 ways of running the NAV on Docker images.
- Hyper-V containers, with kernel level/hyperv isolation (meaning the image has its own kernel)
- Windows Server containers, with process isolation (meaning the image shares the kernel with the host).
As you can imagine, shared Kernel is only possible if the host kernel is the same major version as the container base image. Fortunately, both Windows 10 1709 and Windows Server 1709 does support running “old” 14393 containers under Hyper-V.
Read this blog post for deeper description on the version compatibility. This gives us this compatibility matrix (gray column is the base image of the NAV on Docker images):
Host OS Container base image
|windowsservercore 10.0.14393.x||windowsservercore 1709|
|Windows 10||Yes (with Hyper-V)||No|
|Windows 10 1709||Yes (with Hyper-V)||Yes (with Hyper-V)|
|Windows Server 2016||Yes||No|
|Windows Server 1709||Yes (with Hyper-V)||Yes|
As you know, we are supporting NAV on Docker for development and test purposes, meaning we are in the right column.
So why should we look at 1709?
Well, there are multiple reasons. Beside the obvious ones, that we are Microsoft, and we should follow the versions, there also have been significant improvements to the containers feature in 1709 and images have been on a major diet:
I am also confident that Azure Container Services is running 1709 as host and the more serious we get with Azure Container Services, the more urgent 1709 will become.
So yes, of course we will be creating 1709 images going forward, but as you probably can understand, we are not in a rush, but we will be looking into this and discuss what we need to do.
You can of course use 1709 if you want to, but for now you will not get any significant benefits if all you want to do is to run NAV on Docker images.
But… – this is not the last you heard of 1709.