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.
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.
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.
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.
How to push Docker images to AWS’ Elastic Container Registry(ECR) [Tutorial]
All Docker versions are now vulnerable to a symlink race attack
Docker announces collaboration with Microsoft’s .NET at DockerCon 2019