Exciting new things for Docker with Windows Server 1709
What a difference a year makes… last September, Microsoft and Docker launched Docker Enterprise Edition (EE), a Containers-as-a-Service platform for IT that manages and secures diverse applications across disparate infrastructures, for Windows Server 2016. Since then we’ve continued to work together and Windows Server 1709 contains several enhancements for Docker customers.
Docker Enterprise Edition Preview
To experiment with the new Docker and Windows features, a preview build of Docker is required. Here’s how to install it on Windows Server 1709 (this will also work on Insider builds):
Install-Module DockerProvider Install-Package Docker -ProviderName DockerProvider -RequiredVersion preview
To run Docker Windows containers in production on any Windows Server version, please stick to Docker EE 17.06.
Docker Linux Containers on Windows
A key focus of Windows Server version 1709 is support for Linux containers on Windows. We’ve already blogged about how we’re supporting Linux containers on Windows with the LinuxKit project.
To try Linux Containers on Windows Server 1709, install the preview Docker package and enable the feature. The preview Docker EE package includes a full LinuxKit system (all 13MB of it) for use when running Docker Linux containers.
[Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", "1", "Machine") Restart-Service Docker
To disable, just remove the environment variable:
[Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", $null, "Machine") Restart-Service Docker
Docker Linux containers on Windows is in preview, with ongoing joint development by Microsoft and Docker. Linux Containers is also available on Windows 10 version 1709 (“Creators Update 2”). To try it out, install the special Docker for Windows preview available here.
Docker ingress mode service publishing on Windows
Parity with Linux service publishing options has been highly requested by Windows customers. Adding support for service publishing using ingress mode in Windows Server 1709 enables use of Docker’s routing mesh, allowing external endpoints to access a service via any node in the swarm regardless of which nodes are running tasks for the service.
These networking improvements also unlock VIP-based service discovery when using overlay networks so that Windows users are not limited to DNS Round Robin.
Check out the corresponding post on the Microsoft Virtualization blog for details on the improvements.
Named pipes in Windows containers
A common and powerful Docker pattern is to run Docker containers that use the Docker API of the host that the container is running on, for example to start more Docker containers or to visualize the containers, networks and volumes on the Docker host. This pattern lets you ship, in a container, software that manages or visualizes what’s going on with Docker. This is great for building software like Docker Universal Control Plane.
Running Docker on Linux, the Docker API is usually hosted on Unix domain socket, and since these are in the filesystem namespace, sockets can be bind-mounted easily into containers. On Windows, the Docker API is available on a named pipe. Previously, named pipes where not bind-mountable into Docker Windows containers, but starting with Windows 10 and Windows Server 1709, named pipes can now bind-mounted.
Jenkins CI is a neat way to demonstrate this. With Docker and Windows Server 1709, you can now:
- Run Jenkins in a Docker Windows containers (no more hand-installing and maintaining Java, Git and Jenkins on CI machines)
- Have that Jenkins container build Docker images and run Docker CI/CD jobs on the same host
I’ve built a Jenkins sample image (Windows Server 1709 required) that uses the new named-pipe mounting feature. To run it, simple start a container, grab the initial password and visit port 8080. You don’t have to setup any Jenkins plugins or extra users:
> docker run -d -p 8080:8080 -v \\.\pipe\docker_engine:\\.\pipe\docker_engine friism/jenkins 3c90fdf4ff3f5b371de451862e02f2b7e16be4311903649b3fc8ec9e566774ed > docker exec 3c cmd /c type c:\.jenkins\secrets\initialAdminPassword <password>
Now create a simple freestyle project and use the “Windows Batch Command” build step. We’ll build my fork of the Jenkins Docker project itself:
git clone --depth 1 --single-branch --branch add-windows-dockerfile https://github.com/friism/docker-3 %BUILD_NUMBER% cd %BUILD_NUMBER% docker build -f Dockerfile-windows -t jenkins-%BUILD_NUMBER% . cd .. rd /s /q %BUILD_NUMBER%
Hit “Build Now” and see Jenkins (running in a container) start to build a CI job to build a container image on the very host it’s running on!
Smaller Windows base images
When Docker and Microsoft launched Windows containers last year, some people noticed that Windows container base images are not as small as typical Linux ones. Microsoft has worked very hard to winnow down the base images, and with 1709, the Nanoserver download is now about 70MB (200MB expanded on the filesystem).
One of the things that’s gone from the Nanoserver Docker image is PowerShell. This can present some challenges when authoring Dockerfiles, but multi-stage builds make it fairly easy to do all the build and component assembly in a Windows Server Core image, and then move just the results into a nanoserver image. Here’s an example showing how to build a minimal Docker image containing just the Docker CLI:
# escape=` FROM microsoft/windowsservercore as builder SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"] RUN Invoke-WebRequest -Uri https://download.docker.com/win/static/test/x86_64/docker-17.09.0-ce-rc1.zip -OutFile 'docker.zip' RUN Expand-Archive -Path docker.zip -DestinationPath . FROM microsoft/nanoserver COPY --from=builder ["docker\\docker.exe", "C:\\Program Files\\docker\\docker.exe"] RUN setx PATH "%PATH%;C:\Program Files\docker" ENTRYPOINT ["docker"]
You now get the best of both worlds: Easy-to-use, full-featured build environment and ultra-small and minimal runtime images that deploy and start quickly, and have minimal exploit surface area. Another good example of this pattern in action are the .NET Core base images maintained by the Microsoft .NET team.
Summary
It’s hard to believe that Docker Windows containers GA’d on Windows Server 2016 and Windows 10 just one year ago. In those 12 months, we’ve seen lots of adoption by the Docker community and lots of uptake with customers and partners. The latest release only adds more functionality to smooth the user experience and brings Windows overlay networking up to par with Linux, with smaller container images and with support for bind-mounting named pipes into containers.
To learn more about Docker solutions for IT:
- Learn more about Docker for Windows
- Visit IT Starts with Docker and sign up for ongoing alerts
- Learn more about Docker Enterprise Edition
- Sign up for upcoming webinars
Christian Sparre
September 26, 2017 at 7:08 am
Exciting indeed, was trying out Linux container support and got the hello-world:linux image running. You might mention that Hyper-V should be enabled and Hyper-V nesting should be enabled for the VM. I tried running ubuntu but got the following error when pulling the image:
failed to register layer: failed to start service utility VM
and
encountered an error during CreateContainer: failure in a Windows system call: Not enough storage is available to complete this operation.
I'm not sure what it refers to, but there are plenty memory and storage on the VM
Christian Sparre
September 26, 2017 at 11:19 pm
The above error seems to have something to do with available memory, tried increasing the host VM memory to 8GB, and I could start ubuntu. It failed when extracting the fs layers.
Bart
September 27, 2017 at 12:14 am
Hi Christian,
I get a comparable error at build time, at a COPY statement. I have this running directly on my 16GB ram PC.
"failed to copy files: failed to start service utility VM (lcowfs.startVM): container 85031661542e4b93e73cd3540200f06226de535145e6845b2924f3f9b4d5d909_svm encountered an error during CreateContainer: failure in a Windows system call: The file or directory is corrupted and unreadable."
Files and everything are perfectly fine, because the same exact setup does build when targeting the stable linux Docker host.
Michael Friis
September 27, 2017 at 5:49 am
Yes, this suggests that you need more memory.
Some operations are not super reliable, so you might just want to retry if you see other problems.
Bart
September 26, 2017 at 10:00 am
Hi Michael, this is great news! I tried out the special Docker for Windows preview on an insider build, and running the alpine image seems to work fine. I do get some other issues with running other images, but I'm sure that's because this is all very beta still.
The Docker for Windows preview does note that running Windows payloads next to Linux payloads isn't possible just yet, exactly what I'm trying to achieve. Will this be available in the final release of 1709 in october?
Michael Friis
September 27, 2017 at 5:52 am
Yes, running Docker Linux and Windows containers side by side is the plan, but we still need a few more pieces to fall in place for that to happen.
Hicklin
November 13, 2017 at 3:47 am
I have the 2016 1709 running as required, I am trying to run windows and Linux side by side but with no luck. I can run Linux fine then change the ENV setting and run a windows image. problem is I am not able to run both at the same time. is this even possible yet?
Michael Friis
November 13, 2017 at 9:47 am
Unfortunately, it's not there yet. Details: https://twitter.com/friism/status/929048319065653248
Rich
October 2, 2017 at 6:44 am
Hi Michael,
Does this new version allow Windows containers to establish a RDP session with a Windows host OS?
The ability to display a containerized app's GUI was first demonstrated by Taylor Brown using Windows Server 2016 Technical Preview 3/4 but was removed in TP 5 right before MS released its initial version of Windows Server 2016. I was hoping that this feature would be reintroduced in a later (hopefully this) server version.
Michael Friis
November 13, 2017 at 9:50 am
It does not.
Ruben
October 6, 2017 at 6:17 am
Hi Michael,
Looks like there are some really interesting changes coming up.
I am however a little confused about the removal of Powershell from Nanoserver. To me, having Powershell is a minimum requirement for a Windows Container. I need it when I create my images with Dockerfile and I also need it when I want to check some things on the container with docker exec.
I saw that there is a workaround for the Dockerfile by using multi-stage builds but this feels a bit like hacking something that shouldn't need hacking.
Will it be possible to create our own custom image that has nanoserver + Powershell? (basically installing Powershell from bash in Dockerfile)
Michael Friis
November 13, 2017 at 9:52 am
Microsoft maintains nanoserver-based images with PowerShell pre-installed, you can base yourself on those: https://hub.docker.com/r/microsoft/powershell/tags/
Ken
October 30, 2017 at 8:14 am
I have the Docker preview running on Windows Server 1709. I was able to run a microsoft/nanoserver container. I then set the LCOW_SUPPORTED to 1, restarted the Docker service and was able to run an alpine container. However, when I unset LCOW_SUPPORTED, restarted the Docker service and attempted to run a microsoft/nanoserver container again it failed with the following error.
PS C:\programdata\docker> docker container run -it microsoft/nanoserver:1709
C:\Program Files\Docker\docker.exe: Error response from daemon: container 374c1b271842ca7c9d5de4c632dd03287bdc77b8212cb7ce319871fbd493f3c7 encountered an error during CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101) extra info: {"SystemType":"Container","Name":"374c1b271842ca7c9d5de4c632dd03287bdc77b8212cb7ce319871fbd493f3c7","Owner":"docker","VolumePath":"\\\\?\\Volume{4773913d-fd0f-45d4-a8e3-2902bbe20937}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\374c1b271842ca7c9d5de4c632dd03287bdc77b8212cb7ce319871fbd493f3c7","Layers":[{"ID":"9d958f6a-b6cc-50f1-896f-b52470fe31df","Path":"C:\\ProgramData\\docker\\windowsfilter\\92392eff11be0d494efb3c0b9fae64b59464838a30f2645a9f95db48ca5a18bf"},{"ID":"55f5a56b-7211-5656-a3dd-0e3288c1b48e","Path":"C:\\ProgramData\\docker\\windowsfilter\\0e0c3c243b293c84487e0fe94c9b709f9567a11ded6e98dd4b433aa03ed4badf"}],"HostName":"374c1b271842","HvPartition":false,"EndpointList":["70a3df8b-ba7c-433d-b64a-7c23115f9749"],"AllowUnqualifiedDNSQuery":true}.
We've tried a variety of ways to unset the environment variable, restart the service and rebooting the server. We've also gotten the same behavior on a second server.
Any ideas?
Igor
November 7, 2017 at 9:33 am
I have the same issue with latest insider preview, but I never able to run any windows container there, with docker ee preview, docker ee stable, docker ce 17.09, latest docker binaries. Always get The operating system of the container does not match the operating system of the host.
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 2
Server Version: 17.10.0-ee-preview-3
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd json-file logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 16278 (16278.1000.amd64fre.rs3_release.170825-1441)
Operating System: Windows Server Standard
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 8GiB
Name: WIN-447DPV82V22
ID: CEFS:L4OD:AJOD:7HXW:AGAI:EVGX:LI74:HCDG:JQNY:MUZC:3EXK:DHJK
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Client:
Version: 17.10.0-ee-preview-3
API version: 1.33
Go version: go1.8.4
Git commit: 1649af8
Built: Fri Oct 6 17:52:28 2017
OS/Arch: windows/amd64
Server:
Version: 17.10.0-ee-preview-3
API version: 1.34 (minimum version 1.24)
Go version: go1.8.4
Git commit: b8571fd
Built: Fri Oct 6 18:01:48 2017
OS/Arch: windows/amd64
Experimental: true
Imran Qureshi
November 10, 2017 at 4:03 pm
Having run into this too, you have to install the latest Preview version of docker: https://www.thomasmaurer.ch/2017/10/how-to-run-docker-linux-container-on-windows-server-1709/
Michael Friis
November 13, 2017 at 9:55 am
Please open an issue with details here: https://github.com/Microsoft/opengcs/issues/new
Antonio Di Motta
November 10, 2017 at 12:36 am
What is the way to force the update to 1709 on windows server 2016?
Michael Friis
November 13, 2017 at 9:55 am
You cannot in-place upgrade from Windows Server 2016 to Windows Server 1709.
James Klimek
November 16, 2017 at 3:29 pm
We were able to get our Windows docker swarm(s) up and running today on 1709 and Docker EE-17.10-Preview – really fantastic technology – great job!!
Is there any guidance on the timeline for EE17.10 to go to GA?
Again – we were amazed at how easy it was to set up the swarms and scale!
Christian Pejrup
December 8, 2017 at 4:45 am
So I thought I would take the new named pipe on windows for a spin.
Did the install of Docker
"17.10.0-ee-pr… Docker Docker Enterprise Edition for Windows Server 2016 (Preview)"
Configured LCOW
And the Jenkins sample…and got an error from the daemon
"invalid volume specification: '\\.\pipe\docker_engine:\\.\pipe\docker_engine'."
Christian Pejrup
December 11, 2017 at 10:43 am
So i wanted to give the sample a go.
Setup:
Docker Version: 17.10.0-ee-preview-3
Windows Server 1709:
Major Minor Build Revision
—– —– —– ——–
10 0 16299 0
Running the sample i get the error "Error response from daemon: invalid volume specification: '\\.\pipe\docker_engine:\\.\pipe\docker_engine'." as if the named pipe functionality is not available.
Am I miss something?
Mehul
January 9, 2018 at 9:28 pm
I used Windows server 1709 on Azure with container and without container. I used powershell and executed following commands.
Install-Module DockerProvider
Install-Package Docker -ProviderName DockerProvider -RequiredVersion preview
[Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", "1", "Machine")
Restart-Service Docker
I tried running ubuntu image but no luck.
PS C:\Users\mehul> docker run ubuntu
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
C:\Program Files\Docker\docker.exe: no matching manifest for windows/amd64 in the manifest list entries.
See 'C:\Program Files\Docker\docker.exe run –help'.
I even enabled nested VM on Azure using following powershell command as follows.
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
but no luck so far running Linux container inside windows server 1709.
Did I miss anything?
Mehul
January 11, 2018 at 3:13 pm
Since docker preview didn't work, I tried Linuxkit and now I am getting following error.
PS C:\Users\mehul> docker -H "npipe:////./pipe//docker_lcow" pull ubuntu:16.04
16.04: Pulling from library/ubuntu
50aff78429b1: Extracting [==================================================>] 42.74MB/42.74MB
f6d82e297bce: Download complete
275abb2c8a6f: Download complete
9f15a39356d6: Download complete
fc0342a94c89: Download complete
failed to register layer: failed to start service utility VM (applydiff b93cb7c017a264256f13ccef5969b2231485144bce27858762c48343e3f3f229): container b93cb7c017a264256f13ccef5969b2231485144bce27858762c48343e3f3f229_svm encountered an error during CreateContainer: failure in a Windows system call: No hypervisor is present on this system. (0xc0351000) extra info: {"SystemType":"container","Name":"b93cb7c017a264256f13ccef5969b2231485144bce27858762c48343e3f3f229_svm","Layers":null,"HvPartition":true,"HvRuntime":{"ImagePath":"C:\\Program Files\\Linux Containers","LinuxInitrdFile":"initrd.img","LinuxKernelFile":"bootx64.efi"},"ContainerType":"linux","TerminateOnLastHandleClosed":true}
The steps to install Linux Kit are as follows.
# Stop Docker Service
Stop-Service Docker
# Get the latest dockerd.exe and docker.exe
Invoke-WebRequest -UseBasicParsing -OutFile dockerd.exe https://master.dockerproject.org/windows/x86_64/dockerd.exe
Invoke-WebRequest -UseBasicParsing -OutFile docker.exe https://master.dockerproject.org/windows/x86_64/docker.exe
move-item dockerd.exe "$Env:ProgramFiles\Docker"
move-item docker.exe "$Env:ProgramFiles\Docker"
$url = "https://github.com/linuxkit/lcow/files/1482864/release.zip"
$outfile = "lcowrelease.zip"
Invoke-WebRequest -Uri $url -OutFile $outfile
Remove-Item "$env:ProgramFiles\Linux Containers" -Force -Recurse
Expand-Archive $outfile -DestinationPath "$Env:ProgramFiles\Linux Containers\."
rm $outfile
$env:LCOW_SUPPORTED=1
$env:LCOW_API_PLATFORM_IF_OMITTED="linux"
Remove-Item c:\lcow -Force -Recurse; mkdir c:\lcow
Restart-Computer
So both ways Linux container on Windows server 1709 doesn't work.
Thanks,
Mehul
Marc Noon
February 22, 2018 at 5:29 pm
Is it possible to have two kernels on one OS? I know that sounds pretty crazy but if it could switch kernels dynamically then it could solve the Linux on windows VM issue. The alternative is having a Windows Kernel mimic a Linux Kernel which just seems like it would be rife with problems depending on changes in priorities for the various operating systems.
Carl Fischer
April 6, 2018 at 3:32 pm
Hi Marc – with the latest versions of Docker for Windows you can run Linux and Windows containers side-by-side. Check out https://blog.docker.com/2018/02/docker-for-windows-18-02-with-windows-10-fall-creators-update/
Rayan Alsubhi
March 9, 2018 at 5:11 pm
I'm trying to try out mounting the docker_engine pipe on Windows 10. I'm not able to do that. Is it only supported on Windows server?
Carl Fischer
April 6, 2018 at 3:28 pm
Hi Rayan – in Server 1709 / Win 10 Fall Creators Update (1709) named pipe mounting is only supported with process isolated containers. On Win 10 all containers use Hyper-V isolation so in effect it is not supported on that version of Windows 10. Microsoft believes this is fixed in their 1803 release, see https://github.com/moby/moby/issues/36562
Jason Sievert
April 6, 2018 at 12:03 pm
I am hitting the invalid volume specification as well, fresh install of 1709 but the preview version is now 17.10.0-ee-preview-3.
Has anyone been able to get this to work? This would solve a ton of issues for us in our devops workflow.
FiZxMiKe
April 25, 2018 at 6:58 am
On Windows Server 1709, Installed Docker EE Preview, Enabled LCOW, run busybox with -m 2GB and free -m shows only ~900 megs available. I have linux containers that need 1.5 GB to run that crash on every D4W install I try. Any pro-tips to help me out? Thanks!
Marius Bjørnstad
April 25, 2018 at 8:27 am
Docker works for me on the Insider build, thanks for the blog post.
I'm able to run with a mapped volume on C:\
> docker run –rm -v c:\:/mnt centos ls /mnt
(content of C:\)
> docker run –rm -v d:\:/mnt centos ls /mnt
docker: Error response from daemon: container ce562206dbf04f7da1f73f5c7b2c3dfed5c128c27da1145a2a6e2b6cc7faa68b encountered an error during CreateContainer: failure in a Windows system call: Catastrophic failure (0x8000ffff) extra info: {"SystemType":"container","Name":"ce562206dbf04f7da1f73f5c7b2c3dfed5c128c27da1145a2a6e2b6cc7faa68b","Owner":"docker","LayerFolderPath":"C:\\ProgramData\\docker\\lcow\\ce562206dbf04f7da1f73f5c7b2c3dfed5c128c27da1145a2a6e2b6cc7faa68b","Layers":[{"ID":"da88b5fb-501d-564b-bcb2-3294eec0cafe","Path":"C:\\ProgramData\\docker\\lcow\\a47431f1ac4b722919811ff8098f625e6627808b4ef8bf34cc5077572883f265\\layer.vhd"}],"MappedDirectories":[{"HostPath":"d:\\","ContainerPath":"/tmp/gcs/ce562206dbf04f7da1f73f5c7b2c3dfed5c128c27da1145a2a6e2b6cc7faa68b/binds/mnt","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":true}],"HvPartition":true,"EndpointList":["a16c7b1c-f3c2-4cf6-abc2-0548e87ac4a3"],"HvRuntime":{"ImagePath":"C:\\Program Files\\Linux Containers","LinuxInitrdFile":"initrd.img","LinuxKernelFile":"bootx64.efi"},"AllowUnqualifiedDNSQuery":true,"ContainerType":"linux","TerminateOnLastHandleClosed":true}.
The insider build doesn't have a task bar (or GUI in general), so I can't bring up the docker settings and select "Shared Drives". I'm new to this and probably missing something, does anyone know how I can map things on "D:\"?
Marius Bjørnstad
April 25, 2018 at 8:31 am
Sorry, I have been taking my time, but seconds after I post this I thought.. I should try E:, and it works!! D: is ReFS and C:, E: is NTFS, so does it only support NTFS?