Posts My First Experience with WSL2 (With Mirrored Network Mode)
Post
Cancel

My First Experience with WSL2 (With Mirrored Network Mode)

My First Experience with WSL2 (With Mirrored Network Mode)

Recently, I decided to switch to using Windows Subsystem for Linux 2 (WSL2) for my development environment. As someone who frequently works with Ruby on Rails and Docker, I was curious to see how WSL2 could streamline my workflow. What stood out the most in my first experience was the mirrored network mode, which made handling VPNs and network configurations incredibly easy.

Initial Setup: Choosing the Right Environment

The first step was setting up WSL2 with Ubuntu 22.04 LTS. I chose this version for its long-term support and stable environment, which is ideal for development. Getting started was simple. After installing WSL, I used the following command to set up Ubuntu:

1
wsl --install -d Ubuntu-22.04

Once installed, I had access to a full Linux environment directly within Windows, which felt like a seamless transition.

Managing System Resources and Enabling Mirrored Network Mode

One of the key things I wanted to manage from the beginning was how WSL2 handled system resources. By default, WSL2 can use all available CPU and memory, which might lead to performance issues on systems with limited resources. I also needed to manage VPNs and networking easily, which is where mirrored network mode came into play.

Mirrored network mode ensures that the network configuration from Windows is mirrored inside WSL. This makes VPNs and other network settings much easier to handle because the WSL instance will automatically inherit the network configuration from Windows.

To configure this, I created a .wslconfig file in my Windows home directory (C:\Users\<username>) with the following content:

1
2
3
4
[wsl2]
memory=24GB
processors=6
networkingMode=mirrored

This configuration limits WSL2 to 24GB of RAM, 6 CPU cores, and uses mirrored network mode to simplify VPN and network integration.

Why Mirrored Network Mode Is a Game-Changer

Before using mirrored network mode, I would have had to manage VPN connections directly inside WSL2, using tools like openconnect or vpnc. While this works, it adds complexity, especially when dealing with multiple VPNs. With mirrored network mode, everything just works. Windows manages the VPN connection, and WSL2 inherits that configuration, allowing for seamless access to resources across different networks.

This is especially useful for developers who need to connect to different environments or services through VPNs while working on multiple projects. The ability to use multiple VPNs simultaneously, without manually configuring them inside WSL, has significantly improved my productivity.

Setting Up Docker in WSL2

Another important part of my workflow involves Docker. Initially, I thought about using Docker Desktop, which integrates with WSL2, but I found that running Docker natively inside WSL2 offers better performance and avoids some of the resource conflicts I had experienced with Docker Desktop.

Here’s how I installed Docker inside WSL2:

  1. Install Docker:

    1
    2
    
    sudo apt update
    sudo apt install docker.io
    
  2. Configure Docker to Run Without Root:

    1
    
    sudo usermod -aG docker $USER
    
  3. Restart your WSL environment to apply the changes.

With Docker running natively inside WSL2 and mirrored network mode enabled, I was able to access external services, such as private registries, without manually handling network configurations.

Developing with Rails in WSL2

Once Docker was set up, I focused on getting my Rails projects up and running. The most important decision was to store all my code inside the WSL environment. This way, I avoided the performance issues that can arise from working with files stored on the Windows filesystem (\wsl$\). Running everything inside WSL was noticeably faster.

I also set up my version manager, rbenv, with the following command:

1
export PATH="$HOME/.rbenv/bin:$PATH"

With Ruby configured, everything worked as expected, and I was able to debug my Rails applications using RubyMine, my preferred IDE.

Workflow Optimizations: Choosing the Right Mode

I explored several workflows to find what worked best for me inside WSL2:

  1. Native Rails inside WSL2: This setup allows you to run everything inside WSL2 like a normal Linux machine. This mode is great if you want to keep everything isolated and run commands like rails s directly inside WSL2.

  2. Running Ruby from WSL while Editing from Windows: This hybrid mode lets me use Ruby and the code inside WSL2 but allows me to use Windows tools like RubyMine to manage the code. This strikes a good balance between speed and convenience and supports debugging.

  3. Full Docker inside WSL2: I also experimented with running everything inside Docker containers, including Rails and Ruby. While this requires more configuration, it provides the benefits of containerization and easier management of dependencies across different projects.

Final Thoughts: Why Mirrored Network Mode Is Essential

After using WSL2 with mirrored network mode, I can confidently say that it simplifies many aspects of development, especially when working with multiple VPNs and complex network configurations. If you’re someone who needs to connect to different environments simultaneously, mirrored network mode is a must.

Final Tips

While WSL2 has proven to be a great tool for development, I always recommend having a fallback. Keeping a separate Ubuntu LTS environment (either as a VM or dual-boot) is a great way to ensure that you have a stable, reliable setup if anything goes wrong with WSL2.


References:

This post is licensed under CC BY 4.0 by the author.