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.

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.