Recognizing proxy servers’ critical position, Docker Desktop 4.30 offers new enhancements, especially on the Windows front, to ensure seamless integration and interaction within these secured environments.

Traditional approach

The realm of proxy servers is intricate, a testament to their importance in modern corporate infrastructure. They’re not just barriers but sophisticated filters and conduits that enhance security, optimize network performance, and ensure efficient internet traffic management. In this light, the dance of authentication — while complex — is necessary to maintain this secure environment, ensuring that only verified users and applications gain access.

Traditionally, Docker Desktop approached corporate networks with a single option: basic authentication. Although functional, this approach often felt like navigating with an outdated map. It was a method that, while simple, sometimes led to moments of vulnerability and the occasional hiccup in access for those venturing into more secure or differently configured spaces within the network. 

This approach could also create roadblocks for users and admins, such as:

• Repeated login prompts: A constant buzzkill.
• Security faux pas: Your credentials, base64 encoded, might as well be on a billboard.
• Access denied: Use a different authentication method? Docker Desktop is out of the loop.
• Workflow whiplash: Nothing like a login prompt to break your coding stride.
• Performance hiccups: Waiting on auth can slow down your Docker development endeavors.

Seamless interaction

Enter Docker Desktop 4.30, where the roadblocks are removed. Embracing the advanced authentication protocols of Kerberos and NTLM, Docker Desktop now ensures a more secure, seamless interaction with corporate proxies while creating a streamlined and frictionless experience. 

This upgrade is designed to help you easily navigate the complexities of proxy authentication, providing a more intuitive and unobtrusive experience that both developers and admins can appreciate:

• Invisible authentication: Docker Desktop handles the proxy handshake behind the scenes.
• No more interruptions: Focus on your code, not on login prompts.
• Simplicity: No extra steps compared to basic auth. 
• Performance perks: Less time waiting, more time doing.

A new workflow with Kerberos authentication scheme is shown in Figure 1:

A new workflow with NTLM auth scheme is shown in Figure 2:

Integrating Docker Desktop into environments guarded by NTLM or Kerberos proxies no longer feels like a challenge but an opportunity. 

With Docker Desktop 4.30, we’re committed to facilitating this transition, prioritizing secure, efficient workflows catering to developers and admins who orchestrate these digital environments. Our focus is on bridging gaps and ensuring Docker Desktop aligns with today’s corporate networks’ security and operational standards.

FAQ

• Who benefits? Both Windows-based developers and admins.
• Continued basic auth support? Yes, providing flexibility while encouraging a shift to more secure protocols.
• How to get started? Upgrade to Docker Desktop 4.30 for Windows.
• Impact on internal networking? Absolutely none. It’s smooth sailing for container networking.
• Validity of authentication? Enjoy 10 hours of secure access with Kerberos, automatically renewed with system logins.

Docker Desktop is more than just a tool — it’s a bridge to a more streamlined, secure, and productive coding environment, respecting the intricate dance with proxy servers and ensuring that everyone involved, from developers to admins, moves in harmony with the secure protocols of their networks. Welcome to a smoother and more secure journey with Docker Desktop.

Learn more

• Update to Docker Desktop 4.30.
• Read Docker Desktop 4.30: Proxy Support with SOCKS5, NTLM and Kerberos, ECI for Build Commands, Build View Features, and Docker Desktop on RHEL Beta.
• Create a Docker Account and choose Business subscription.
• Authenticate using your corporate credentials.
• Subscribe to the Docker Newsletter.
• Vote on what’s next! Check out our public roadmap.
• New to Docker? Get started.

This means that these developers will be able to take advantage of WSL 2 and Docker’s integration, allowing developers to store their code within their WSL 2 distro and run the Docker CLI from within this distro. This removes the need to access files stored on the Windows host and provides significant performance improvements for users.

To find out more about using Docker Desktop with WSL 2, check out Simon’s full tips and tricks article. If you want to learn more about how Docker developed the WSL 2 backend you can have a look through our history of the integration or learn more about the implementation details of the backend check out one of Simon’s other blog posts. 

If you are enjoying Docker Desktop but have ideas of what we could do to make it better then please give us feedback. You can let us know what features you want to see next via our roadmap, including voting up GPU support for WSL 2. Or if you are new to Docker, download Docker Desktop and get started with WSL 2 today.

With this announcement, the launch of the Windows 2004 release imminently and Docker Desktop v2.3.02 reaching WSL2 GA , we thought this would be a good time to reflect on how we got to where we are today with WSL 2.

April 2019

Casting our minds back to 2019 (a very different time!), we first discussed WSL 2 with Microsoft in April. We were excited to get started and wanted to find a way to get a build as soon as possible.

May 2019

It turned out the easiest way to do this was to collect a laptop at Kubecon EU (never underestimate the bandwidth of a 747). We brought this back and started work on what would be our first ‘hacky’ version of WSL 2 for Docker Desktop.

June 2019

With some internal demo’s done we decided to announce what we were planning <3

This announcement was a bit like watching a swan on a lake, our blog post was calm and collected, but beneath the water we were kicking madly to take us towards something we could share more widely.

July 2019

We finally got far enough along that we were ready to share something!

And not long after we released our first preview of Docker Desktop using WSL 2

August-September 2019

Once again, with a preview out and things seeming calm we went back to work. We were talking with Microsoft weekly about how we could improve what we had, on fixing bugs and generally on improving the experience. Simon and Ben did have enough time though to head over to the USA to talk to Microsoft about how we were getting on.

October 2019

We released a major rework to how Docker Desktop would integrate with WSL 2:

Along with adding K8s support and providing feature parity with our old Hyper-V based back end. We also made the preview more visible in Docker Desktop and our user numbers started to increase

November 2019 – Feb 2020

This time flew by, we spent a lot of this time chasing down bugs, looking at how we could improve the local experience and also what the best ways of working would be:

March 2020

We had built up a fair bit of confidence in what we had built and finally addressed one of the largest outstanding items we still had in our backlog – we added Windows Home support

This involved us removing the functionality associated with running our old Moby VM in Hyper V and all of the options associated with running Windows containers – as these are not supported on Windows Home. With this we were now able to focus on heading straight to GA…

April 2020

We doubled down how we were getting ready for GA, learning lessons on improving our development practice. We wanted to share how we were preparing and testing WSL 2 ready for the 2.7m people out there running Docker Desktop.

May 2020

We finally reached our GA with Docker Desktop v2.3.02!

Now we are out in the wild, we shared some ideas and best practices to make sure you are getting the best experience out of Docker Desktop when working with WSL 2. 

(And of course for Windows Pro users this still comes with all the same features you know and love including the ability to switch back over to using Windows Containers.)

What’s next?

Next, is that people start to use Docker Desktop with WSL 2! To try out Docker Desktop with WSL 2 today, make sure you are on Windows 2004 or higher and download the latest Docker Desktop to get started.

If you are enjoying  Docker Desktop but have ideas of what we could do to make it better then please give us feedback. You can let us know what features you want to see next via our roadmap, including voting up GPU support for WSL 2. 

WSL 2 (or Windows Subsystem for Linux version 2) is Microsoft’s second take on shipping a Linux Kernel with Windows. The first version was awesome as it translated Linux system calls to the equivalent Windows NT call in real time. The second version includes a full fledged virtual machine. 

It was only natural that Docker would embrace this change and ship a Docker Desktop for Windows version that runs on WSL 2 (WSL 1 had issues running the Docker daemon). This is still a Technical Preview, but after using it for a couple of days, I’ve completely switched my local development to take advantage of it and I’m pretty happy with it.

In this blog, I’ll show you an example of how to develop Docker-powered applications using the Docker Desktop WSL 2 Tech Preview.

Why use Docker Desktop WSL 2 Tech Preview over the “stable” Docker Desktop for Windows?

The main advantage of using the technical preview is that you don’t have to manage your Docker VM anymore.  More specifically:

• The VM grows and shrinks with your needs in terms of RAM/CPU, so you don’t have to decide its size and preallocate resources. It can shrink to almost zero CPU/RAM if you don’t use it. It works so well that most of the time you forget there’s a VM involved.
• Filesystem performance is great, with support for inotify and the VM’s disk size can match the size of your machine’s disk.

Apart from the above, if you love Visual Studio Code like I do, you can use the VS Code Remote WSL plugin to develop Docker-powered applications locally (more on that in a bit). You also get the always awesome Docker developer experience while using the VM.

How does Docker Desktop for WSL 2 Tech Preview work?

When you install it, it automatically installs Docker in a managed directory in your default WSL 2 distribution. This installation includes the Docker daemon, the Docker CLI and the Docker Compose CLI. It is kept up to date with Docker Desktop and you can either access it from within WSL, or from PowerShell by switching contexts — see, Docker developer experience in action!

Developing applications with Docker Desktop for WSL 2 Tech Preview

For this example, we’ll develop a simple Python Flask application, with Redis as its data store. Every time you visit the page, the page counter will increase — say hello to Millennium!

Setting up VS Code Remote – WSL

Visual Studio Code recently announced a new set of tools for developing applications remotely — using SSH, Docker or WSL. This splits Visual Studio Code into a “client-server” architecture, with the client (that is the UI) running on your Windows machine and the server (that is your code, Git, plugins, etc) running remotely. In this example, we’re going to use the WSL version.

To start, open VS Code and select “Remote-WSL: New Window”. This will install the VS Code Remote server in your default WSL distribution (the one running Docker) and open a new VS Code workspace in your HOME directory.

Getting and Exploring the Code

Clone this Github repository by running git clone https://github.com/akalipetis/python-docker-example. Next, run code -r python-docker-example to open this directory in VS Code and let’s go a quick tour!

Dockerfile and docker-compose.yml

These should look familiar. The Dockerfile is used for building your application container, while docker-compose.yml is the one you could use for deploying it. docker-compose.override.yml contains all the things that are needed for local development.

Pipfile and Pipfile.lock

These include the application dependencies. Pipenv is the tool used to manage them.

The app.py  file contains the Flask application, which we’re just using in this example. Nothing special here!

Running the application and making changes

In order to run the application, open a WSL terminal (this is done using the integrated terminal feature of VS Code) and run docker-compose up. This will start all the containers (in this case, a Redis container and the one running the application). After doing so, visit http://localhost:5000 in your browser and voila — you’ve visited your new application. That’s not development though, so let’s change and see it in action. Open the app.py in VS Code and change the following line:

Refresh the web page and observe that:

1. The message was immediately changed
2. The visit counter continued counting from the latest value

Under the hood

Let’s see what actually happened.

• We changed a file in VS Code, which is running on Windows.
• Since VS Code is running on a client-server mode with the server running is WSL 2, the change was actually made to the file living inside WSL.
• Since you’re using the Technical Preview of Docker Desktop for WSL 2 and docker-compose.override.yml is using Linux workspaces to mount the code from WSL 2 directly into the running container, the change was propagated inside the container.
  • While this is possible with the “stable” Docker Desktop for Windows, it isn’t as easy. By using Linux workspaces, we don’t need to worry about file system permissions. It’s also super fast, as it’s a local Linux filesystem mount.
• Flask is using an auto-reloading server by default, which — using inotify — is reloading the server on every file change and within milliseconds from saving your file, your server was reloaded.
• Data is stored in Redis using a Docker volume, thus the visits counter was not affected by the restart of the server.

Other tips to help you with Docker Desktop for WSL 2

Here are a few additional tips on developing inside containers using the Technical Preview of Docker Desktop for WSL 2:

• For maximum file system performance, use Docker volumes for your application’s data and Linux Workspaces for your code.
• To avoid running an extra VM, switch to Windows containers for your “stable” Docker Desktop for Windows environment.
• Use docker context default|wsl to switch contexts and develop both Windows and Linux Docker-powered applications easily.

Final Thoughts

I’ve switched to Windows and WSL 2 development for the past two months and I can’t describe how happy I am with my development workflow. Using Docker Desktop for WSL 2 for the past couple of days seems really promising, and most of the current issues of using Docker in WSL 2 seem to be resolved. I can’t wait for what comes next!

The only thing currently missing in my opinion is integration with VS Code   Remote Containers (instead of Remote WSL which was used for this blogpost) would allow you to run all your tooling within your Docker container.

Until VS Code Remote Containers support is ready, you can run pipenv install --dev to install the application dependencies on WSL 2, allowing VS Code to provide auto-complete and use all the nice tools included to help in development.

Get the Technical Preview and Learn More

If you’d like to get on board, read the instructions and install the technical preview from the Docker docs.

For more on WSL 2, check out these blog posts:

• 5 Things to Try with Docker Desktop WSL 2 Tech Preview
• Get Ready for the Tech Preview of Docker Desktop for WSL 2

Developing #Docker Powered Apps on Windows with #WSL2 by Docker Captain @akalipetis
Click To Tweet

The original WSL was an impressive effort to emulate a Linux Kernel on top of Windows, but there are such foundational differences between Windows and Linux that some things were impossible to implement with the same behavior as on native Linux, and this meant that it was impossible to run the Docker Engine and Kubernetes directly inside WSL. Instead, Docker Desktop developed an alternative solution using Hyper-V VMs and LinuxKit to achieve the seamless integration our users expect and love today.

Microsoft has just announced WSL 2 with a major architecture change: instead of using emulation, they are actually providing a real Linux Kernel running inside a lightweight VM. This approach is architecturally very close to what we do with LinuxKit and Hyper-V today, with the additional benefit that it is more lightweight and more tightly integrated with Windows than Docker can provide alone. The Docker daemon runs well on it with great performance, and the time it takes from a cold boot to have dockerd running in WSL 2 is around 2 seconds on our developer machines. We are very excited about this technology, and we are happy to announce that we are working on a new version of Docker Desktop leveraging WSL 2, with a public preview in July. It will make the Docker experience for developing with containers even greater, unlock new capabilities, and because WSL 2 works on Windows 10 Home edition, so will Docker Desktop.

Collaborating with Microsoft

As part of our shared effort to make Docker Desktop the best way to use Docker on Windows, Microsoft gave us early builds of WSL 2 so that we could evaluate the technology, see how it fits with our product, and share feedback about what is missing or broken. We started prototyping different approaches and we are now ready to share a little bit about what is coming in the next few months.

Docker Desktop Future

We will replace the Hyper-V VM we currently use by a WSL 2 integration package. This package will provide the same features as the current Docker Desktop VM: Kubernetes 1-click setup, automatic updates, transparent HTTP proxy configuration, access to the daemon from Windows, transparent bind mounts of Windows files, and more.

This integration package will contain both the server side components required to run Docker and Kubernetes, as well as the CLI tools used to interact with those components within WSL. We will then be able to introduce a new feature with Docker Desktop: Linux workspaces.

Linux Workspaces

When using Docker Desktop today, the VM running the daemon is completely opaque: you can interact with the Docker and Kubernetes API from Windows, but you can’t run anything within the VM except Docker containers or Kubernetes Pods.

With WSL 2 integration, you will still experience the same seamless integration with Windows, but Linux programs running inside WSL will also be able to do the same. This has a huge impact for developers working on projects targeting a Linux environment, or with a build process tailored for Linux. No need for maintaining both Linux and Windows build scripts anymore! As an example, a developer at Docker can now work on the Linux Docker daemon on Windows, using the same set of tools and scripts as a developer on a Linux machine:

A developer working on the Docker Daemon using Docker Desktop technical preview, WSL 2 and VS Code remote

Also, bind mounts from WSL will support inotify events and have nearly identical I/O performance as on a native Linux machine, which will solve one of the major Docker Desktop pain points with I/O-heavy toolchains. NodeJS, PHP and other web development tools will benefit greatly from this feature.

Combined with Visual Studio Code “Remote to WSL”, Docker Desktop Linux workspaces will make it possible to run a full Linux toolchain for building containers on your local machine, from your IDE running on Windows.

Performance

With WSL 2, Microsoft put a huge amount of effort into performance and resource allocations: The VM is setup to use dynamic memory allocation, and can schedule work on all the Host CPUs, while consuming as little (or as much) memory it requires – within the limits of what the host can provide, and in a collaborative manner towards win32 processes running on the host.

Docker Desktop will leverage this to greatly improve its resource consumption. It will use as little or as much CPU and memory as it needs, and CPU/Memory intensive tasks such as building a container will run much faster than today.

In addition, the time to start a WSL 2 distribution and the Docker daemon after a cold start is blazingly fast – within 2s on our development laptops, compared to tens of seconds in the current version of Docker Desktop. This opens the door to battery-life optimizations by deferring the daemon startup to the first API call, and automatically stop the daemon when it is not running any container.

Zero-configuration bind mount support

One of the major issues users have today with Docker Desktop – especially in an enterprise environment – is the reliability of Windows file bind mounts. The current implementation relies on Samba Windows service, which may be deactivated, blocked by enterprise GPOs, blocked by 3rd party firewalls etc. Docker Desktop with WSL 2 will solve this whole category of issues by leveraging WSL features for implementing bind mounts of Windows files. It will provide an “it just works” experience, out of the box.

Technical Preview of Docker Desktop for WSL 2

Thanks to our collaboration with Microsoft, we are already hard at work on implementing our vision. We have written core functionalities to deploy an integration package, run the daemon and expose it to Windows processes, with support for bind mounts and port forwarding.

A technical preview of Docker Desktop for WSL 2 will be available for download in July. It will run side by side with the current version of Docker Desktop, so you can continue to work safely on your existing projects. If you are running the latest Windows Insider build, you will be able to experience this first hand. In the coming months, we will add more features until the WSL 2 architecture is used in Docker Desktop for everyone running a compatible version of Windows.

Developers using Docker to build containerized applications often build Docker Compose files to deploy them. With the integration of Kubernetes into the Docker product line, some developers may want to leverage their existing Compose files but deploy these applications in Kubernetes.

With Docker on the desktop (as well as Docker Enterprise Edition) you can use Docker compose to directly deploy an application onto a Kubernetes cluster.

Here’s how it works:

Let’s assume I have a simple Docker compose file like the one below that describes a three tier app: a web front end, a worker process (words) and a database.

Notice that our web front end is set to route traffic from port 80 on the host to port 80 on the service (and subsequently the underlying containers). Also, our words service is going to launch with 5 replicas.

services:
  web:
    build: web
    image: dockerdemos/lab-web
    volumes:
     - "./web/static:/static"
    ports:
     - "80:80"

  words:
    build: words
    image: dockerdemos/lab-words
    deploy:
      replicas: 5
      endpoint_mode: dnsrr
      resources:
        limits:
          memory: 16M
        reservations:
          memory: 16M

  db:
    build: db
    image: dockerdemos/lab-db

I’m using Docker for Mac, and Kubernetes is set as my default orchestrator. To deploy this application I simply use docker stack deploy providing the name of our compose file (words.yaml) and the name of the stack (words). What’s really cool is that this would be the exact same command you would use with Docker Swarm:

$ docker stack deploy --compose-file words.yaml words
Stack words was created
Waiting for the stack to be stable and running...
 - Service db has one container running
 - Service words has one container running
 - Service web has one container running
Stack words is stable and running

Under the covers the compose file has created a set of deployments, pods, and services which can be viewed using kubectl.

 
$ kubectl get deployment
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
db        1         1         1            1           2m
web       1         1         1            1           2m
words     5         5         5            5           2m

$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
db-5489494997-2krr2      1/1       Running   0          2m
web-dd5755876-dhnkh      1/1       Running   0          2m
words-86645d96b7-8whpw   1/1       Running   0          2m
words-86645d96b7-dqwxp   1/1       Running   0          2m
words-86645d96b7-nxgbb   1/1       Running   0          2m
words-86645d96b7-p5qxh   1/1       Running   0          2m
words-86645d96b7-vs8x5   1/1       Running   0          2m

$ kubectl get services
NAME            TYPE          CLUSTER-IP       EXTERNAL-IP    PORT(S)       AGE
db              ClusterIP     None                    55555/TCP     2m
web             ClusterIP     None                    55555/TCP     2m
web-published   LoadBalancer  10.104.198.84        80:32315/TCP  2m
words           ClusterIP     None                    55555/TCP     2m

If you look at the list of services you might notice something that seems a bit odd at first glance. There are services for both web and web-published. The web service allows for intra-application communication, whereas the web-published service (which is a load balancer backed by vpnkit in Docker for Mac) exposes our web front end out to the rest of the world.

So if we visit http://localhost:80 we can see the application running. You can actually see the whole process in this video that Elton recorded.

Now if we wanted to remove the service you might think you would remove the deployments using kubectl (I know I did). But what you actually do is use docker stack rm and that will remove all the components created when we brought the stack up.

$ docker stack rm words
Removing stack: words

$ kubectl get deployment
No resources found

And, to me, the cool thing is that this same process can be used with Docker EE – I simply take my Compose file and deploy it directly in the UI of Docker Enterprise Edition (EE) – but that’s another post.

Want to try it for yourself? Grab Docker for Mac or Docker for Windows, but be sure to check out the documentation (Mac and Windows) for more info.

Learn more:

• Sign-up to download the Docker EE beta with Kubernetes or try it in our labs
• Watch our DockerCon Europe 2017 Kubernetes Announcement
• Register for DockerCon 2018

Use Docker Compose to deploy a multiservice app on #Kubernetes w/ #Docker for Mac by @mikegcoleman
Click To Tweet

The easiest way to get Kubernetes on your desktop is here.

Simply check the box and go

What You Can Do with Kubernetes on your desktop?

Docker for Mac and Docker for Windows are the most popular way to configure a Docker dev environment, and are each used everyday by millions of developers to build, test, and debug containerized apps. The beauty of building with Docker for Mac or Windows is that you can deploy the exact same set of Docker container images on your desktop as you do on your production systems with Docker EE.

Docker for Mac and Docker for Windows are used for building, testing and preparing to ship applications, whereas Docker EE provides the ability to secure and manage your applications in production at scale. You eliminate the “it worked on my machine” problem because you run the same Docker containers on the same Docker engines in development, testing, and production environments, along with the same Docker Swarm and Kubernetes orchestrators.

With beta support for Kubernetes, Docker provides users end-to-end container-management software and services spanning from developer workstations running Docker for Mac or Docker for Windows, through test and CI/CD using Docker CE or Docker Enterprise Edition (EE), our container platform, through to production systems on-premises or in the cloud running Docker EE.

How to Get Started

A few things to keep in mind:

• Edge channel required
  Kubernetes support is still considered a beta with this release, so to enable the download and use of Kubernetes components you must be on the Edge channel. The Docker for Windows version should be 18.02 or later.
• Already using other Kubernetes tools?
  If you are already running a version of kubectl pointed at another environment, for example minikube, you will want to follow the activation instructions to change contexts to docker-for-desktop.

Things To Try

If you are new to Kubernetes and looking for some introductory exercises to try, here are a few resources:

• The Docker for Windows Desktop with Kubernetes page has instructions for getting an example app up and running
• Follow along with Docker Developer Advocate Elton Stoneman during his short video, demonstrating activating Kubernetes and deploying an application using both Docker compose and a Kubernetes manifest. (Note: the video shows Docker for Mac but the application works exactly the same in this beta of Docker for Windows…the power of Docker containers in action!)

Send Us Your Feedback

Send us your feedback, ideas for improvement, bugs, complaints and more so we can make Docker better on the Desktop. You can use the Docker community forums for general discussions and you can also directly file technical issues on Github.

#Docker for #Windows with beta support for using #Kubernetes as your orchestrator is here!
Click To Tweet

Learn More:

• Get Docker for Windows Desktop
• Sign-up to download the Docker EE beta with Kubernetes or try it in our labs
• Watch our DockerCon Europe 2017 Kubernetes Announcement

]]> Kubernetes in Docker for Mac Beta nonadult https://www.docker.com/blog/docker-windows-server-1709/ Mon, 25 Sep 2017 18:00:00 +0000 https://blog.docker.com/?p=18848 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”).

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:

1. Run Jenkins in a Docker Windows containers (no more hand-installing and maintaining Java, Git and Jenkins on CI machines)
2. 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

Exciting new things for #Docker with @Windows Server 1709
Click To Tweet

Running Docker Linux containers on Windows requires a minimal Linux kernel and userland to host the container processes. This is exactly what the LinuxKit toolkit was designed for: creating secure, lean and portable Linux subsystems that can provide Linux container functionality as a component of a container platform.

We’ve been busy prototyping LinuxKit support for Docker Linux containers on Windows and have a working preview for you to try. This is still a work in progress, and requires either the recently announced  “Windows Server Insider” or Windows 10 Insider builds.

UPDATE: LCOW support is available in Windows 10 Fall Creators Update and in Windows Server 1709. The simplest way to try it out on Windows 10 is to install the edge variant of Docker for Windows (details). On Windows Server 1709, install EE preview.

Running Docker Linux Containers on Windows with LinuxKit

UPDATE: The LinuxKit LCOW repo has a README with updated details for users interested in LinuxKit.

The instructions below have been tested on Windows 10 and Windows Server Insider builds 16278 and 16281.

Be sure to install Docker for Windows (Windows 10) or Docker Enterprise Edition (Windows Server Insider) before starting.

Setup Docker and LinuxKit

A preview build of LinuxKit is available by simply running the following commands in PowerShell (with Administrator rights):

$progressPreference = 'silentlyContinue'
mkdir "$Env:ProgramFiles\Linux Containers”

Invoke-WebRequest -UseBasicParsing -OutFile linuxkit.zip https://github.com/friism/linuxkit/releases/download/preview-1/linuxkit.zip

Expand-Archive linuxkit.zip -DestinationPath "$Env:ProgramFiles\Linux Containers\."
rm linuxkit.zip

Now get a master branch build of the Docker daemon that contains preview support for Linux containers on Windows:

Invoke-WebRequest -UseBasicParsing -OutFile dockerd.exe https://master.dockerproject.org/windows/x86_64/dockerd.exe

Start a new Docker daemon listening on a separate pipe and using a separate storage location from the default install:

$Env:LCOW_SUPPORTED=1
$env:LCOW_API_PLATFORM_IF_OMITTED="linux"
.\dockerd.exe -D --experimental -H "npipe:////./pipe//docker_lcow" --data-root c:\lcow

Try it

Run a Linux container:

docker -H "npipe:////./pipe//docker_lcow" run -ti busybox sh

Docker just launched a minimal VM running a LinuxKit instance hosting the Linux container!

Since this is an early preview there are some limitations, but basic Docker operations like pull and run work.

Looking ahead

Both Windows Server Insider builds and Docker support for Linux containers on Windows are in early preview mode. When GA, Docker Linux containers on Windows will improve the Docker Linux container experience for both Windows developers and server administrators. Developers will be able to more easily build and test mixed Windows/Linux Docker applications by running containers for both platforms side-by-side on the same system.

And IT-admins that prefer Windows will soon be able to easily run (mostly) Linux-only software like HAProxy and Redis on Windows systems by way of Docker Linux containers on Windows. For example, Docker Linux containers on Windows will make setting up Docker Enterprise Edition and Universal Control Plane (which relies on some Linux-only components) on Windows Server much simpler.

We hope this LinuxKit-based walkthrough will set you up to start experimenting. Feedback is always welcome! For general help and getting started with Insider builds use the Windows Feedback Hub (Windows 10), or the Windows Server Insiders Tech Community. For issues with LinuxKit and Docker support for Linux containers on Windows use the Docker for Windows issue tracker on GitHub. And let us know on Twitter if you build something cool!

More Resources:

• Read the complimentary post about Linux Container on Windows on the Microsoft blog
• Download Docker for Windows 10 and Docker for Windows Server
• Learn more about Docker Enterprise
• Attend the Linux Container on Windows and LinuxKit sessions @DockerCon

Preview @Linux Containers on @Windows using #LinuxKit by @neugebar cc @MS_ITPro
Click To Tweet

Webinar Recording

You can view the webinar on YouTube:

The recording clocks in at just under an hour. Here’s what we covered:

• 00:00 Introduction
• 02:00 Docker on Windows Server 2016
• 05:30 Windows Server 2016 technical details
• 10:30 Hyper-V and Windows Server Containers
• 13:00 Docker for Windows Demo – ASP.NET Core app with SQL Server
• 25:30 Additional Partnerships between Docker, Inc. and Microsoft
• 27:30 Introduction to Image2Docker
• 30:00 Demo – Extracting ASP.NET Apps from a VM using Image2Docker
• 52:00 Next steps and resources for learning Docker on Windows

Q&A

Can these [Windows] containers be hosted on a Linux host?

No. Docker containers use the underlying operating system kernel to run processes, so you can’t mix and match kernels. You can only run Windows Docker images on Windows, and Linux Docker images on Linux.

However, with an upcoming release to the Windows network stack, you will be able to run a hybrid Docker Swarm – a single cluster containing a mixture of Linux and Windows hosts. Then you can run distributed apps with Linux containers and Windows containers communicating in the same Docker Swarm, using Docker’s networking layer.

Is this only for ASP.NET Core apps?

No. You can package pretty much any Windows application into a Docker image, provided it can be installed and run without a UI.

The first demo in the Webinar showed an ASP.NET Core app running in Docker. The advantage with .NET Core is that it’s cross-platform so the same app can run in Linux or Windows containers, and on Windows you can use the lightweight Nano Server option.

In the second demo we showed ASP.NET WebForms and ASP.NET MVC apps running in Docker. Full .NET Framework apps need to use the WIndows Server Core base image, but that gives you access to the whole feature set of Windows Server 2016.

If you have existing ASP.NET applications running in VMs, you can use the Image2Docker tool to port them across to Docker images. Image2Docker works on any Windows Server VM, from Server 2003 to Server 2016.

How does licensing work?

For production, licensing is at the host level, i.e. each machine or VM which is running Docker. Your Windows licence on the host allows you to run any number of Windows Docker containers on that host. With Windows Server 2016 you get the commercially supported version of Docker included in the licence costs, with support from Microsoft and Docker, Inc.

For development, Docker for Windows runs on Windows 10 and is free, open-source software. Docker for Windows can also run a Linux VM on your machine, so you can use both Linux and Windows containers in development. Like the server version, your Windows 10 licence allows you to run any number of Windows Docker containers.

Windows admins will want a unified platform for managing images and containers. That’s Docker Datacenter which is separately licensed, and will be available for Windows soon.

What about Windows updates for the containers?

Docker containers have a different life cycle from full VMs or bare-metal servers. You wouldn’t deploy an app update or a Windows update inside a running container – instead you update the image that packages your app, then just kill the container and start a new container from the updated image.

Microsoft are supporting that workflow with the two Windows base images on Docker Hub – for Windows Server Core and Nano Server. They are following a monthly release cycle, and each release adds an incremental update with new patches and security updates.

For your own applications, you would aim to have the same deployment schedule – after a new release of the Windows base image, you would rebuild your application images and deploy new containers. All this can be automated, so it’s much faster and more reliable than manual patching. Docker Captain Stefan Scherer has a great blog post on keeping your Windows containers up to date.

Additional Resources

• Get everything Docker and Microsoft here
• Windows and Docker case-study: Tyco’s life-safety applications 
• Self-paced labs for Windows Containers from Docker
• Packaging ASP.NET 4.5 Applications in Docker

Our #Windows containers webinar is on @YouTube for you to #LearnDocker
Click To Tweet