I wrote an article recently about utilizing Remote Containers in Visual Studio Code with the Serverless Framework. I personally love working with a local container to create a consistent, isolated build and development environment for my team. While happy with my initial setup, I noticed that build times were slower than I would like. This article discusses how I configured my local development environment to give me blazingly fast performance.
Contents
DOCKER VOLUMES
Your development container will need access to your source files to build them. Docker makes this possible by using volumes. When using a remote container, your entire project directory is mounted as a volume. Depending on the type of project you have, this can equate to a lot of files. If I mention the word “node_modules,” you should understand the gravity of the situation.
WINDOWS SUBSYSTEM FOR LINUX (WSL 2)
WSL 2 provides a Linux-compatible kernel interface for Windows. Linux containers require a Linux host. Using WSL 2 allows Docker Desktop to support Linux containers without requiring a Hyper-V VM running in the background. If you are still using Docker Desktop with Hyper-V, I highly recommend switching to WSL 2.
Now, back to our conversation on volumes. Microsoft recommends against mounting across operating systems as this will reduce performance. Docker’s documentation also reinforces this position by suggesting we keep our source code and other bind-mounted data in the Linux file system instead of the Windows. This is precisely why I wasn’t getting the performance I wanted out of my remote container. Moving my source code into WSL 2 gave me significant performance improvements.
MOVING TO WSL 2
There are several ways to interact with WSL; however, I prefer using Windows Terminal. I still do a fair amount of work with PowerShell, and Windows Terminal allows me to work with both easily. Regardless, whether you are using the WSL command prompt or Windows Terminal, managing your source code in WSL is easy if everything is in GIT. A simple git clone command and voila! To edit our project, we need to open Visual Studio Code, which is easy if you have the Remote – WSL extension installed.
BEFORE AND AFTER
To see how much better the performance is with our source in WSL, we can make a quick comparison. I generated two empty Angular projects, one in my Windows file system and one in Ubuntu. When running in a remote container with my source files in Windows, npm start takes about 65000ms to complete. In Linux, it takes 437ms! Even in this simple case, we get significant performance improvements by keeping our source code in WSL 2.
ACCESS FROM WINDOWS
The great thing about WSL is that we can still access files stored in our Linux distros from the Windows file system. For example, while I primarily stick to the command-line, I occasionally will view the history of my GIT repositories using a tool like SourceTree or GitHub Desktop. In both cases, I can open the repository by navigating to the directory using the \\wsl$\DISTRO_NAME\… convention.
IN CLOSING…
This is a relatively short article; however, the amount of time that can be saved made me feel it was worth sharing. Even when looking at an empty Angular template, we saw that the performance is significantly increased. I can only imagine this will improve with the size of the project.
