Docker Community Forums

Share and learn in the Docker community.

Docker Desktop WSL2 and Visual Studio Code - Clarifications on how/when WSL2 is involved

Hi

I’m having issues with networking in WSL2 which brings me to wonder a bit about how WSL2 is actually used by Docker Desktop when “Use the WSL2 based engine” is ticked.

When running any WSL2 distro I have no working network access, but when running a supposedly WSL2 backed container it works, see issue on GitHub: https://github.com/microsoft/WSL/issues/5862

Is there any difference in starting code (with a dev container configured repo) from within the WSL2 terminal vs from the Powershell terminal?

How is networking set up in making it possible to access external network from within a container in WSL2 but not from the docker-desktop distro itself?

Starting VSCode with a repository that is configured to be used as with a development container it asks if you want to restart in container, when selecting yes it shows “>< Dev Container …” in the bottom left side.
Opening the docker desktop UI shows a container running: “vsc-vscode-remote-try-python…”
Using the built in terminal to check for network access is successful, able to ping 8.8.8.8 for example.

Looking at the documentation for Docker Desktop with WSL2 says you should start code from within the WSL2 distro terminal. All according to: https://docs.docker.com/docker-for-windows/wsl/#develop-with-docker-and-wsl-2
Once VSCode is up the bottom left indicates remote WSL: “>< WSL: Ubuntu 20.04”. Checking network access from the built in terminal by again pinging 8.8.8.8 fails.

Since I am opening the same folder as in the example above (but from the WSL2 distro terminal this time) I get the question if I want to reload in container. Doing this changes the connection info in the bottom left to “>< Dev Container …” once again. And if I take a look at the Docker Desktop UI I can see a running container again, same name as when starting it from outside WSL2

Once again testing external network access by pinging 8.8.8.8 is successful.

Attaching to the running WSL2 instance of “docker-desktop”

  NAME                   STATE           VERSION
* docker-desktop         Running         2

Trying to ping 8.8.8.8 fails, just as for any other WSL2 distro installed.

What makes the containers running within the docker-desktop WSL2 distro able to connect to external network but not the docker-desktop WSL2 distro itself? (I can see a lot of vpnkit* processes running)

/Kristofer

1 Like

You shouldn’t have to setup anything, network in WSL2 should be available. This is the point to start debugging, before you look into Docker and VS Code.

The difference is that VS Code automatically connects to your code folder with Remote if you start it from inside WSL.

Hi Tekki

I absolutely agree that the main issue is within WSL2 and I therefore have an open issue in the WSL github.
What I find to not be very clear is how different the network setup is when running a container using the WSL2 engine vs terminal directly in a distro.

Regarding the comment on starting a devcontainer from pwrshell vs wsl2 I was more wondering if dockers use of WSL2 differs in any other way than the folder mounting.

I attached to my debian distro(by accident, planned to do it in the docker-desktop terminal) and ran systemd-cgtop before starting a vscode devcontainer from pwrshell, and once the container was up an running systemd-cgtop started showing a new instance:
/docker/e15bdb189b9b3b805045fee24ffd08777b7c8f3f020d5f31d6f05dc658f7c602
When i realized i ran the command in debian and not in the docker-desktop distro I also tried the same in my ubuntu distro and saw the exact same contents, guessing all wsl2 distros share the same.

When I try to open the same vscode devcontainer again, in parallel, but this time from within WSL2, once I select reload in container the new VSCode instance closes and I’m switched over to the previously from pwrshell started instance of the same devcontainer. Apparently identifying that I have already opened it, and in a way also indicating that it’s handled the exact same way regardless of from where I open it.

1 Like

The network setup is something extremely complicated that happens behind the scenes and should ‘just work’. I’ve never looked into the source code of Desktop to find out how it is made.

Me, I always work in Debian. The distros with docker in the name are used by Desktop and I never touch them.
Docker is not docker. One part is the Docker service that runs somewhere in the mentioned distros and is available at localhost:2375, The other is the docker command line, the program that communicates with the service. You can compare it with mysql or psql and their corresponding databases. It doesn’t matter from where you start a container, you can even use powershell for that, it always runs at the same place.