More Linux than Windows: El Reg takes Docker Desktop for WSL 2 preview out for a spin
Some gripes at this stage, but the potential is there
Hands On Container wunderkind Docker has released a preview of Docker Desktop for Windows Subsystem for Linux 2.
This peek at Docker Desktop 2 is based on the work Microsoft has done to make Windows Subsystem for Linux a full virtual machine (VM) with its own complete Linux kernel, instead of redirecting system calls as is done in the first version of WSL. This means that the docker daemon can run in WSL rather than in a separate Hyper-V VM.
The existing Docker for Windows creates a VM with 2GB of RAM. WSL2 uses dynamic memory and CPU, making it more efficient and flexible in terms of resource usage.
The current technical preview of Docker Desktop for WSL 2 has a number of annoyances. First, you need a recent "Insider" build of Windows 10, at least 18932. There are earlier builds that support WSL 2 – but not the new Docker. Second, the only supported Linux distribution is Ubuntu 18.04. Of course you also need to make sure that this is running in WSL 2 mode. You can convert it if necessary.
Once installed, you can toggle your Docker Desktop installation between the WSL 2 and traditional VM modes. The WSL 2 Tech Preview option on the Docker Desktop right-click menu lets you configure, start and stop the Docker daemon on WSL 2. Once up and running, you can switch between the two with the docker context command, for example:
docker context use wsl
There is another annoyance, though, which is that the docker-compose command does not yet understand this context. This means you might find Docker containers still running in the old Docker VM even when you thought it was configured for WSL. Having both running gives plenty of possibilities for confusion and port conflicts.
The solution suggested by Docker engineer Simon Ferquel is either to use a workaround using the DOCKER_HOST environment variable, or to use docker-compose from within WSL. This second solution is easy when using Docker with Visual Studio Code remoting, since you can have a terminal open in WSL within the editor. You can also take advantage of the high performance bind mounting in WSL 2 to access source files on the Windows side, or keep the source files on the Linux side.
This does raise the question of what value WSL 2 is adding over just using a Linux VM, running locally or remotely. The main rationale is to be able to use a full Linux toolchain while still using a Windows editor such as Visual Studio Code, and potentially having access to Windows applications like Microsoft Office, or Adobe's Creative Suite applications for design work, without having to switch machines.
WSL 2 does make this scenario almost seamless. You can use Docker tools on Windows or in WSL 2 and both access the same Docker Daemon. Ferquel also notes some features to come, including VPN connectivity, trusted certificate authority synchronisation between the host and WSL running Docker, and support for Kubernetes.
Docker Desktop for Windows also retains the ability to switch to using Windows containers, though this is intended mainly for legacy applications. Microsoft's efforts to support Linux with .NET Core and even SQL Server have the side effect of making Windows containers less necessary.
The current tech preview is for the brave, but when this is done the combination of WSL 2, Docker and Visual Studio Code remoting comes close to achieving Microsoft's goal of making Windows 10 an excellent solution for container-oriented development.
That said, conceptually it is about ensuring that building and running your code takes place on Linux rather than Windows – a strange but necessary path for Microsoft to take. ®