WSL was a great effort towards emulating a Linux Kernel on top of Windows. But due to certain differences between Windows and Linux, it was quite impossible to run the Docker Engine and Kubernetes directly inside WSL. So, the Docker Desktop developed an alternative solution with the help of Hyper-V VMs and LinuxKit to achieve the seamless integration.
On 16th June, Docker announced WSL 2 with a major architecture change where the company will provide a real Linux Kernel running inside a lightweight VM instead of emulation. This approach is architecturally similar to LinuxKit and Hyper-V but WSL 2 has an additional benefit that it is more lightweight and tightly integrated with Windows. Even the Docker daemon runs properly on it with great performance.
The team further announced that they are working on new version of Docker Desktop that would leverage WSL 2 and the public preview will be expected in July.
The official blog reads, “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.”
In context with integration of Microsoft the blog reads, “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.”
The future of Docker Desktop will have WSL 2
The team will replace the Hyper-V VM by a WSL 2 integration package. The package will offer the same features as the current Docker Desktop including automatic updates, transparent HTTP proxy configuration, VM: Kubernetes 1-click setup, access to the daemon from Windows, etc. This package will contain both the server-side components that are required to run Docker and Kubernetes and the CLI tools to interact with those components within WSL.
WSL 2 will enable seamless integration with Linux
With WSL 2 integration, users will experience seamless integration with Windows, but even Linux programs that are running inside WSL will be able to do the same. This creates a huge impact for developers that are working on projects related to the Linux environment, or with a build process for Linux.
Now there won’t be a need for maintaining both Linux and Windows build scripts. For 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.
The bind mounts from WSL will now support inotify events (inotify is a Linux kernel subsystem) and will have almost identical I/O performance as on a native Linux machine. This will solve one of the major Docker Desktop issues with I/O-heavy toolchains. This feature will benefit NodeJS, PHP and other web development tools.
Improved performance and reduced memory consumption
The VM has been setup to use dynamic memory allocation and schedule work on all the Host CPUs. It will be consuming lesser memory which would be in the limit of what the host can provide. Docker Desktop will leverage this for improving its resource consumption and use CPU and memory as per its needs. The CPU/Memory intensive tasks such as building a container will also run much faster.
Leveraging WSL 2 Docker desktop will support bind mount
One of the major problems that the users have with Docker Desktop is the reliability of Windows file bind mounts. The current implementation is dependent on Samba Windows service, which could be deactivated, blocked by enterprise GPOs or even blocked by 3rd party firewalls etc. But Docker Desktop with WSL 2 solves these issues by leveraging WSL features to implement the bind mounts of Windows files.
Few users seem to be unhappy with this news, one of them commented on HackerNews, “So, I think the main sticking point here is the lock-in of Hyper-V. By making a new popular feature completely dependent on a technology that explicitly disables the use of competitive hypervisors, they’re giving with one hand and taking with the other. If I was on VM-Ware’s executive team, I’d be seriously thinking about filing an anti-trust complaint and the open source community should be thinking about whether submarining virtualbox is worth what Microsoft is doing here.”
Others think that WSL 2 is a full Linux kernel that runs in Hyper-V. Another comment reads, “WSL 2 is a full Linux kernel running in Hyper-V rather than an emulation layer on top of NT.”
To know more about this news, check out the official post by Docker.