𝗪𝗦𝗟 - 𝗪𝗼𝗿𝗸 𝘄𝗶𝘁𝗵 𝗟𝗶𝗻𝘂𝘅 𝗶𝗻 𝗪𝗶𝗻𝗱𝗼𝘄𝘀.

Part 1. About WSL.

𝗪𝗦𝗟 𝗶𝘀 𝘁𝗵𝗲 “𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗦𝘂𝗯𝘀𝘆𝘀𝘁𝗲𝗺 𝗳𝗼𝗿 𝗟𝗶𝗻𝘂𝘅” feature, and I was surprised to realize that many engineers still don’t know about it. It seems that in most cases only advanced software developers are aware of its power, while for the rest it still appears to be a bit of complex magic. However, it’s a powerful and easy-to-use tool that can save a lot of time (and even money in some cases).

Essentially, 𝗪𝗦𝗟 𝗶𝘀 𝗮 𝗛𝘆𝗽𝗲𝗿-𝗩 𝗟𝗶𝗻𝘂𝘅 𝗩𝗠 with a distro of your choice running inside that VM, 𝗱𝗲𝗲𝗽𝗹𝘆 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗲𝗱 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺. I believe that’s enough detail at this point. Let’s get to the use cases.

Let’s say your main OS is Windows, but you also need to run some binaries or scripts under Linux as part of CI/CD. Your pipelines may use either a Linux VM or a Docker container as an execution environment. The problem is that it usually takes a long time to debug the configuration directly on your CI/CD platform.

Before executing anything on a Linux system as part of a pipeline, you need to ensure that all packages, config files, environment variables, and so on are installed and properly configured. Getting this configuration right usually requires a few iterations, like any other debugging process. You prepare the initial version, execute what you need, check the result, and add corrections if necessary. The cycle is repeated until you get a fully functional setup that meets all requirements. The point is that if you don’t have a local Linux installation, you will inevitably have to perform these steps directly on your CI/CD platform. Each time you run a pipeline, it takes a while for all steps to complete before you can evaluate the result. Thus, the feedback loop is relatively long.

This is where WSL comes in handy.

WSL allows you to set up a local Linux instance based on the same Linux distro you use on your CI/CD platform. It can be a Docker image as well. In the case of Docker you just have to do a few more steps: install Linux under WSL and then install Docker inside that Linux VM. After that you get an autonomous debugging Linux workspace and the ability to create as many as you need. Now you can jump into the debugging process right away, which significantly reduces the feedback loop because you don’t need to wait for resource allocation, VM/container bootstrapping, etc., as typically happens on a CI/CD platform. You can do all debugging locally, identify all setup steps required and later add them to your CI/CD pipeline. The feedback obviously comes much faster in this case.

Part 2. My Experience with WSL.

Intro.

As you can see in my profile, I’m a Test Automation Engineer — a person who uses specific tools to automate checks and support testing. My previous project involved testing a highly customized Salesforce configuration. After detailed analysis we selected a tool that met our automation needs. At some point, we had to set up nightly test runs and our CI/CD platform was GitLab. Our GitLab configuration allowed us to use Docker images, and we decided Docker was the optimal solution for our case.

The Story

The automation tool came with its own sample Dockerfile, but we had a few reasons to build our own version:

1. The native Dockerfile was overcomplicated. It was very hard to read and understand even for experienced Docker users. I decided not to build anything on top of it and to create our own Dockerfile, which would be easier to read and maintain.
2. We needed to execute our reporting tools after test execution. They required additional packages, which resulted in extra steps for the system configuration.
3. We had to integrate some command-line tools for working with an internal secret storage to store and read Salesforce credentials safely.

From the very beginning of the image-building process I understood that it was better to compose and test the Dockerfile, along with the resulting container, on a local Linux workspace. What I didn’t know at that point was that I would also need to adjust some of the test tool’s execution parameters to handle certain Docker limitations. This also took me some time. In the end, running Docker under WSL allowed me to experiment and troubleshoot all the issues much faster than I would have been able to do directly on CI/CD.

But there are many more use cases for WSL. I shared just one of my stories and encourage you to try it yourself.

On working with Docker.

I would highly recommend that you try using the command line and not Docker Desktop — at least give it a try. 🙂 In my opinion, even a basic knowledge of Docker commands makes everything much clearer and faster for you compared to mouse-clicking in Docker Desktop.

Have fun! 😉