Remote WSL and Docker Extension limitations

[thernstig]

Regarding https://code.visualstudio.com/docs/remote/wsl#_docker-extension-limitations

The docker daemon (dockerd) is currently not well supported running inside WSL. A common workaround is to install Docker for Windows and then inside WSL install docker just to get access to the docker CLI. The docker CLI is then connected to Docker in Windows via localhost:2375. This can be seen here https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

I am thus wondering if this section about the docker limitation in WSL is a bit misleading. It seems to be a copy&paste from the other two remote options. As an example, check this text, where container should probably say WSL.

This enables the extension to work with your local Docker installation when you are developing inside a container.

Should the section be more explicit about that docker extension running locally in a WSL setup might "not" be a problem, due to the above mentioned reasons?

[AngellusMortis]

These docs are likely copied and pasted from https://github.com/Microsoft/vscode-dev-containers/tree/master/containers/docker-in-docker

That does not mean they do not apply. The "Docker Extension" itself is considered to only be a "local" extension. It cannot be installed on a "remote" like WSL. This section in the docs refer to that point. The settings snippet they give allow you override the default behavior and tell VS Code that Docker is in fact a remote extension.

I do not have Docker installed on my Windows machine, but I did play around with it a bit using the link from above. What you should be able to do is add the following to your User Settings on your Windows 10 host:

"remote.extensionKind": {
    "peterjausovec.vscode-docker": "workspace"
}

Then inside of a WSL install with Docker set up and configured according to the article you linked above, add the following to your Remote settings inside of your WSL host:

"docker.host": "localhost:2375",

This should make your Docker side-bar tab and extension function. However it is imporant to know, that I have noticed that you cannot nest Remotes. So you cannot do anything with the Remote - Container extension while you are already using the Remote - WSL extension. You will not be able to use the "Attach Visual Studio Code" feature from the Docker side-bar tab. If you want to attach VS Code to a container and use the Remote - Container extension, you will have to attach VS Code manually from the Docker side-bar tab before you connect to a WSL host.

[thernstig]

I am not saying the guide does not apply or does not work, I am saying it is in fact superfluous in a WSL setup.

The "Docker Extension" itself is considered to only be a "local" extension. It cannot be installed on a "remote" like WSL.

As far as I am aware, the extension can be installed in WSL. But it does not matter, because you are effectively still using the docker CLI in WSL which will call your docker daemon in your Windows Docker install, thus neglecting the need to even install the docker extension remotely in the first place.

In addition, with the setup according to the article (which is the most common way afaik), you will not need to set "docker.host": "localhost:2375", as it is already set as an environment variable.

[AngellusMortis]

But it does not matter, because you are effectively still using the docker CLI in WSL

Huh, I swear it was not working like that Friday night when I set everything up. It might have been, it was pretty late when I set it up. I thought that the Docker side-bar tab was not appearing unless you have the extension installed on the remote (in this case inside of WSL). Maybe you should make a PR to the docs to update them then, the author of the docs was probably just following the same assumption as the person who made the docker-in-docker example.

you will not need to set "docker.host": "localhost:2375"

You definetely still do. Your environment variable is only in your bashrc. Your bashrc will only get executed when you "log in" to your shell (the -i option). VS Code started inside of Windows so that means it only inherits you Windows environment variables. When it installs the VS Code Remote server in WSL, it does not "log in" to WSL. It just runs it directly against your WSL install. This means VS Code will never see your DOCKER_HOST environment variable so it still has to be overwritten manually in your settings. I did a quick sanity test to verify that is the case.

An example if you would like to test yourself:

In Windows (CMD):

C:\>wsl -e "env | grep DOCKER_HOST"

C:\>

You can see it did not source your bashrc because it did not do a "log in".

In WSL:

1. Make change to your .bashrc to change your DOCKER_HOST variable. Like change the 2375 to a 2376.
2. Run

 ~  bash -c env | grep DOCKER_HOST
DOCKER_HOST=tcp://localhost:2375
 ~  bash -ic env | grep DOCKER_HOST
DOCKER_HOST=tcp://localhost:2376
 ~   

You noticed that without the -i option, the new shell inherits the existing DOCKER_HOST, which means it did not source your .bashrc.

[Chuxel]

@thernstig WSL is very much like containers. You can't run the docker daemon in a container either, but you can still control and deploy to another docker host using the CLI. This gives you the ability to do things like Docker build from the Linux side. You install the Docker CLI (not the docker daemon) and then connect to a host -- which as you pointed out can be done via TCP. In the containers case you forward the docker socket, but its a similar concept.

We can refine the document to be more explicit about this last part. You can install the CLI without the daemon in the Linux world pretty easily (unlike Windows and mac where the two are bundled together in Docker Desktop).

[Chuxel]

Updated in docs. Next time there's a push it will go out. Thanks for point it out!