Allow using the local machine as the docker host with remote over ssh

[reem]

Perhaps I am just not clever enough but I couldn't arrive at a configuration that allows a host machine A to connect to a development machine B using vscode remote over ssh while having machine B configured to use machine A as its docker host, also via ssh.

Part of this issue may just be some kind of networking impossibility, since the docker extension (which is running locally on machine A) is trying to connect to the docker host, which is actually configured using the local network ip of machine A, which can't resolve its own ip.

Please advise, I may be missing something!

Related existing closed issues, that I don't think directly address this use case:

• Improve VS Code remote support when running as a "UI" extension #1260
• In order to use an SSH DOCKER_HOST on OS X and Linux, you must configure an ssh-agent. #1459

[karolz-ms]

@reem maybe you can elaborate on what your expectations are with regards to containers running on machine A and interacting (?) with stuff running on machine B, and how the Docker VS Code extensions fits into this picture

That said, the simplest workaround would be to just have an instance of VS Code running in "local" mode on machine A, and use Docker extension from that instance--it will show Docker resources and allow you to manipulate them, get logs etc., but some gestures might not work, like building an image from sources that are, presumably, on machine B

Alternatively you can try to install Docker extension remotely (on machine B, from within your "remote-SSH" instance of VS Code), and then try to make it work with daemon on machine A. This is, unfortunately, tricky, because the library we use to talk to Docker daemon, dockerode, imposes some extra requirements/limitations. All the known workarounds and tricks are described in this document. If that helps get you set up the way you want, great. If not, let us know what the specific issue/error is and we will try to sort it out.

[PavelSosin-320]

For today the answer is "Using applications running inside WSL VM as a server for other machines is absolutely impossible due to WSL networking architecture by its design (no bridge)." WSL has no stable global IP address and can't be discovered outside PC on which it runs. For example, ping to WSL VM from another machine never works. But it is another long discussion. In any possible network topology at least yet another Linux machine is required to manage the overlay network.
There are several Docker-less Container design& runtime solutions like Runc, Crun, Podman which are pure CLIs and don't need any server at all.

[reem]

Let me say a little more about my use case before diving in:

• Machine A is a workstation machine running Windows being used as a client for machine B, it also has significantly more compute resources than machine B so it is also being used as a remote docker host
• Machine B is a development machine running macOS, all development tooling, source code, etc. is installed here

Machine B is already configured to use Machine A for docker operations via docker contexts, when running operations from the CLI, or on a locally installed VS Code on machine B from the docker extension, everything works without a hitch.

The problem arises when I run VS Code on Machine A, the workstation, connected via Remote SSH to machine B, and try to access the docker extension. It's unable to resolve the context, since it's trying to connect to machine A's ip FROM machine A, where the extension appears to be actually running. Running docker operations using the CLI in the ssh session still works fine, I just cannot use the docker extension at all.

As far as I can tell this option "Alternatively you can try to install Docker extension remotely (on machine B, from within your "remote-SSH" instance of VS Code)" is no longer allowed, you can't install it in workspace mode.

I also don't believe this to be a WSL networking issue as when running VS Code locally on Machine B I can connect to the docker engine on Machine A without any problems using either the CLI or the docker extension.

EDIT: In this case I am primarily interested in using the machine just for docker builds so issues like opening ports and mounting files when actually running containers are not particularly pressing for me personally.

EDIT2: I believe what's happening is the extension is too smart and tries to parse the context directly and then connect to it from the local machine, when it should actually be connecting via the client machine, as the host machine is not guaranteed to have access to the context at all. (e.g. you could imagine a scenario with a machine C that can only be accessed from machine B and not machine A) I could be wrong here though.

[PavelSosin-320]

There is WSL networking limitation that makes using WSL as a server for remote machines not possible or not practical at least. The WSL running on Windows OEM home addition doesn't make it a "team server". The WSL VM IP address is not stable and can't be published. There is a separate very long-running discussed topic about the creation of a bridge between WSL VM and Host network. The standard WSL usage assumes that any TCP server running inside WSL VM must listen Ip 0.0.0.0, i.e. WSL owns Lo interface or Eth0 interface provided dynamically by the Lxss Windows service every time when the distro starts.

[karolz-ms]

@reem you said

As far as I can tell this option "Alternatively you can try to install Docker extension remotely (on machine B, from within your "remote-SSH" instance of VS Code)" is no longer allowed, you can't install it in workspace mode.

Can you tell us more about this--what exactly have you tried, what you expected and what happened instead?

You should be able to install the extension remotely. In fact this change removed the extensionKind designation from the extension, which should make it default to workspace extension kind.

[bwateratmsft]

You should be able to install the extension remotely. In fact this change removed the extensionKind designation from the extension, which should make it default to workspace extension kind.

Specifically, what that change does is it leaves the extension disabled if it is not installed in workspace mode, or otherwise explicitly configured to use UI mode. If users go to the extension tab they should see an option to install it in the remote workspace.

[bwateratmsft]

This issue has been closed because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!