Seamless integration of Docker on Windows using WSL 2?

In this post I give a short summary of using Docker on Windows and a more detailed view into the newest Docker Desktop version in combination with WSL 2. If you would like to learn the basics of WSL 2, please take a look at my earlier post.

There is not ‘the’ single point of truth when working with Docker on a Windows machine. You have several options to choose from, each with their benefits and downsides. However, as Docker is a ‘Linux solution’ you will end up with some kind of virtualized Linux environment running on your Windows system. You can decide to run and set up your own full-grown virtual machine (VM) yourself. Or you go for the current ‘Windows solution’ and use Docker Desktop. If you don’t have the latest Windows 10 version, you may stick to Docker Machine, however, it is superseded for quite some time now.

As of May 2020 (release Docker Desktop is now also available for Windows 10 Home users, due to the new Windows Subsystem for Linux (WSL) 2 backend.

Docker on Windows: It’s your choice

The classic solution would be to set up your own virtual Linux machine, e.g. with VirtualBox and running Docker from there. Especially when you run a fully dockerized environment (and this in production), which does not care about any Windows application or service, this still seems to be the most reasonable solution. You can choose between virtualization tools like VirtualBox, VMware or Microsoft’s Hyper-V.

In theory you will need to set everything up like file-sharing, port-forwarding and networking in general. This is crucial especially when you want to have a smooth interoperability between your Windows host and your Linux machine. However, all virtualization tools will assist you there.

A small detour: Use Vagrant to set up your Docker VM
An even easier solution is, to make use of Vagrant to build and configure a custom VM. As long as you or someone in your project team knows how to write a Vagrant file, it provides quite a simple workflow to set up your docker environment. Once written, it allows to simply share a complete development environment without the need to share ‘full grown’ VDIs. However, you will still have a full VM running on your host.  This always leads to some overhead when you only want to run Docker on Windows. In addition, you now have two separate systems. There the interplay is not always as smooth as you want it to be, especially doing it for the first time.

I started playing around with Docker in the browser, which allows access to Docker within seconds. When I really began using it, I simply chose the ‘Windows solution’ and installed Docker Desktop. It required Hyper-V to run a VM in the background and was hence not available for Windows Home users (2019). It worked out of the box and for the first small projects I experienced quite a flawless usability. However, as a project required me to install VirtualBox I had to disable the Windows Hyper-V feature. Switching between both Windows states requires a full system reboot, so this was no option for me.

That’s why I moved to Docker Machine for a while. Instead of requiring Hyper-V, it allows to connect to a Docker engine on a remote system or within any VM. This ‘legacy’ solution has its flaws with respect to usability compared to Docker Desktop. For example, you cannot connect to your containers via localhost. However, for me it provided some valuable insights into working with a remote Docker daemon. It was also the only option for Windows Home users and still is if you do not run Windows 10! So, both applications rely on an actual Linux VM running. But they are running in the background and you don’t have to touch them yourself.

When I heard that Docker Desktop switched to WSL 2 instead of Hyper-V as backend, I gave it another try.

Docker Desktop on Windows using WSL 2

The advantages of WSL 2 over the previously used VM promises to improve the integration and a reduced footprint. As this is the way that Microsoft and Docker Inc. work on in cooperation, this is the solution I wanted to investigate further. If you don’t know about WSL2 in general, read my last blog post.

Just to mention it, Docker was trying to run its daemon within WSL1 but had big difficulties doing so as for example systemd is not available in WSL 1. Some hacky workarounds exist and it is possible to interact with the Docker daemon via Docker Desktop from within WSL.

Get Docker Desktop with WSL 2 backend


  • As a Windows Home user, you need at least Windows 10 version 2004 or higher.
  • Pro, Enterprise and Education need at least Windows 10, updated to version 1903 or higher.
  • In addition, ‘Virtual Machine Platform’ and ‘Windows Subsystem for Linux’ features must be enabled.

When you meet the requirements, you can follow these installation instructions. Next to the Windows features, ‘Virtual Machine Platform’ and ‘Windows Subsystem for Linux’, also check that WSL2 is enabled in your Docker Desktop settings (default by now).

The announcement to switch from the Hyper-V backend to WSL 2 triggered quite some attention. Especially from users that wanted to use Docker Desktop in parallel to third-party virtualization software bypassing Hyper-V.

However, WSL2 itself does rely on Hyper-V components. The problem with using additional virtualization platforms in parallel to Docker Desktop persists for now!

Another small detour: Hyper-V and third-party virtualization Using a third-party virtualization in parallel with Hyper-V is not possible. Therefore, current versions of VirtualBox (since 6.0) and VMware (since 15.5.5) offer to use Hyper-V as a fallback solution to their own virtualization technology. This allows them to still function when Hyper-V is enabled on the host system. However, in both cases this leads to a significant performance loss up to the point that you can’t boot your VM anymore. In my case for example I cannot boot a Windows 10 (x64) VM using VirtualBox. While when playing around with Docker on a small Linux machine, I set up using Vagrant, I didn’t directly notice a performance drop. So, there is still a way to go and from my experience and others I would make the statement:
Hyper-V needs to be disabled if you work with third-party virtualization 

Architectural design of Docker Desktop on WSL 2

The architectural approach to implement Docker Desktop on WSL 2 is quite close to the previous Hyper-V solution.

Previous Docker Desktop design.
Docker Desktop design using WSL 2.

Instead of running inside a ‘standard’ Hyper-V VM it runs in the light-weight utility VM provided by WSL 2. To adapt for the WSL 2 design, it had to handle that different user distros will be running in the same VM, sharing the same network namespace. Running two docker daemons in two different user distros would not work. Therefore, Docker Desktop comes with two customized distributions.

  NAME                 STATE     VERSION
  docker-desktop       Running   2
  docker-desktop-data  Running   2

docker-desktop is basically running the previous LinuxKit distro, now as a container inside a WSL 2 ‘bootstrapping’ distribution, which allows namespace isolation. The container services stayed the same, however the Linux Kernel is removed with the Kernel provided from WSL 2.

docker-desktop-data is used for data storage replacing the VHD. Its directories are bind-mounted inside the LinuxKit container. An API proxy allows to share data and the Docker daemon with other user distros. As this distro contains all the data needed by Docker, it can can get huge quite fast. The data is located at C:\Users\<username>\AppData\Local\Docker\wsl\data\ext4.vhdx. As described in my previous post, you should clean up some disk space from time to time using optimize-vhd (Hyper-V) or diskpart. For example when you had some big docker images in use which you don’t need any more. This seems to be way easier compared to a VirtualBox VM.

What is new with Docker on WSL 2

In terms of usability there is no obvious change when using Docker from the command line. However, you can now use the docker command either from Powershell on Windows or from within any Linux distribution you want. Therefore, you only need to enable it within Docker Desktop settings.

Windows Terminal to run docker either with powershell on Windows or use bash within WSL 2

Sharing the same Docker daemon and also the same Linux kernel and file system cache allows faster bind-mount performance as well. The directory /mnt/wsl/ is shared between all distros and contains also the shared mount points. This is achieved with the API proxy, intercepting container commands and rewriting paths to the shared ones.

The same applies as well to the Kubernetes integration into Docker Desktop.

Benefits from WSL 2

  • Docker Desktop is now available to Windows 10 Home users as well. It does not require the Hyper-V feature. It still uses Hyper-V components provided by ‘Virtual Machine Platform’ and ‘Windows Subsystem for Linux’ features.
  • Docker Desktop aims to provide a seamless operation of Docker on Windows. This boils down to achieve the highest possible integration of the underlying VM. The (Microsoft) WSL2 light-weight utility VM provides tighter integration on the Windows host as Docker’s previous Hyper-V solution.
  • The startup times for the Docker daemon on the WSL2 backend are way faster (~ 5-10x).
  • The Hyper-V solution offered tight integration of Docker into your Windows environment. WSL 2 provides integration of a full Linux development environment and Docker and your Windows host.
  • It is the way that Microsoft and Docker Inc. highly cooperate on. WSL2 is still evolving and promises more to come…

Drawbacks from WSL 2

The drawbacks are mainly connected to the WSL 2 integration to the Windows host. The Docker daemon is running within WSL 2 with almost native Linux performance. To benefit from that the code base should also be moved to the Linux file system. Issues with memory consumption were improved with the latest WSL 2 releases.


With WSL 2, Windows continues to move towards integrating a full Linux environment for Windows developers. This allows to integrate Docker within a mixed development environment. But does this finally allow a decision for the ‘Windows solution’ over the classical Linux VM? It certainly leverages the Docker user to additionally configure a VM and it works out of the box. The cooperation between Docker and Microsoft will improve and new features will be added. With the classic solution on the other hand, you will have more control over the configuration.

Thanks for reading and I hope I could motivate you to try out Docker with WSL 2.

Posted in Java Runtimes - VM, Appserver & Cloud | Leave a comment

WSL 2: The new Windows Subsystem for Linux

This post gives a general introduction with focus on the new version WSL 2. It provides some basic usage principles and outlines some advantages and disadvantages. In future posts to come, I will evaluate using WSL 2 as a software developer and especially to run Docker on Windows.

Windows Subsystem for Linux (WSL) adds Linux functionality, including command-line tools, utilities, and applications to Windows. It is the successor to the Microsoft Windows Services for UNIX. Technically it allows running unmodified L64 binaries on a Windows machine. You can also choose between the well-known user distributions directly from the Microsoft Store and then directly run bash and use tools like ssh and git.

The goal is to provide a seamless integration and interoperability of a Linux environment on a Windows machine especially for software development. This is needed due to the fact that many applications in web development run natively on Linux.

For more read here
Posted in Java Runtimes - VM, Appserver & Cloud | Tagged , | 1 Comment

Web UIs mit Kotlin

Was ich am aufregendsten an Kotlin finde, ist dessen Konzeption, ein einheitliches Toolkit (Sprache + Bibliotheken + Tooling) anzubieten, sich aber auch auf die native Umgebung zu verlassen, wo immer eine Kotlin-Anwendung läuft. Die Verwendung von Kotlin auf der JVM bedeutet eine vollständige Interoperabilität mit Java, im Browser können wir auf JavaScript-Bibliotheken zugreifen, und auch wenn es um die UI-Entwicklung geht, gilt Kotlin dasselbe Prinzip.

Continue reading
Posted in Uncategorized | Tagged , , | Leave a comment

Kommunikation zwischen Browser und Backend: Objektserialisierung mit Kotlin

Java bietet eine sogenannte Objektserialisierung, bei der ein Objekt als eine Folge von Bytes dargestellt werden kann, die sowohl die Daten des Objekts als auch Informationen über den Typ des Objekts und die im Objekt gespeicherten Datentypen enthält. Nachdem ein serialisiertes Objekt in einen Datenstrom geschrieben wurde, kann es aus diesem Datenstrom wieder gelesen und deserialisiert werden, d.h. die Typinformationen und Bytes, die das Objekt und seine Daten repräsentieren, können verwendet werden, um das Objekt im Speicher neu zu erstellen.

Continue reading
Posted in Other languages for the Java VM | Tagged , , | Leave a comment

Spring Boot mit Kotlin

Spring Boot makes it easy to create stand-alone, production-grade Spring-based Applications that you can ‘just run’.

Kotlin wurde so konzipiert, dass es gut mit dem Java-Ökosystem zusammenspielt, und es scheint mir, dass es die gleiche pragmatische und innovative Denkweise teilt wie Spring Boot, sodass sie gut zusammenspielen. In diesem Beitrag werde ich eine Spring Boot-Anwendung von Anfang an mit Kotlin als Hauptsprache erstellen. Man wird lernen, wie Kotlin mit Spring arbeitet. Am Ende wird man eine einfache Spring-Anwendung haben, die mit Kotlin implementiert ist. Mit jeder neuen Version von Spring Boot haben wir eine bessere Kotlin-Unterstützung und können Spring-Anwendungen mit minimalem Boilerplate programmieren.

Continue reading
Posted in Other languages for the Java VM | Tagged , | 1 Comment

Re-deploy your containerized Java application on Azure

In my previous post a while ago I showed you how to deploy your dockerized Java application on Azure. It was a step-by-step introduction switching from browser to IDE, to command line (Docker CLI or Azure CLI), to the Azure web interface. It worked out, but regarding that it was just about the deployment of your code it took quite some time, right? So what about re-deploying your application maybe after making small changes, like fixing a tiny bug? Do you want to do those steps

-> change your code
-> re-build your project
-> build a new docker image
-> tag the image correctly
-> push it to your remote repo
-> stop the running container (?)
-> re-deploy the new container to Azure

over and over again? No, certainly not!

You just want to change the piece of code and then run the following steps as automated as possible. Switching from one tool to another is also not what you want. There are faster ways to achieve this than executing all those steps by hand, depending on your actual environment and personal preferences. So as a Java developer you will most likely build your project with Gradle or Maven. This comes in handy as they offer great plugins to make your life easier. In the following I will stick to Gradle, however similar things are possible using Maven.

My goal was to see how far I could possibly push the whole build and deployment process.

Continue reading
Posted in Java Runtimes - VM, Appserver & Cloud | Tagged , , , | Leave a comment

Kotlin Multiplattform-Projekte für die Web-Entwicklung

Kotlin Multiplatform says that it will take care of the business logic and we just need to take care of the UI.

Laut GitHub war Kotlin die am schnellsten wachsende Programmiersprache des Jahres 2018, was die Verwendung in GitHub-Repositorien betrifft. Die Kotlin-Multiplattformfunktion ist seit Version 1.2, die Ende 2017 veröffentlicht wurde, Teil der Kotlin-Programmiersprache. Der Kotlin-Compiler bietet Unterstützung für die Kompilierung von Code in ein natives Zielformat. Folglich können Kotlin-Anwendungen in Umgebungen ausgeführt werden, die virtuelle Maschinen zum Ausführen von Anwendungen nicht unterstützen, z. B. Apple Smartphones mit iOS. Die unterstützten Plattformen für native Anwendungen sind Android NDK, iOS, Linux, MacOS, Windows und WebAssembly. Kotlin bietet auch Unterstützung für die Kompilierung nach Javascript.

Continue reading
Posted in Other languages for the Java VM, Web as a Platform | Tagged , | 1 Comment