Support connecting to docker containers over tunnels

[connor4312]

We've had multiple people ask for docker connections through tunnels. We should consider supporting this scenario magically ✨

On some machines, if Docker is running in a well known location and accessible by the current user (e.g. on /var/run/docker.sock) we could even have connections work without any additional configuration, if the Docker extension relays its traffic through the control server. (The control server is the server the CLI runs and processes messages from the tunnel)

[Chuxel]

@connor4312 Yeah, just to be explicit, there's two things here to track. Not sure if we want them in the same issue or not:

1. Spin up and attach to a remote Dev Container (like Remote - SSH and what Support dev containers through a Remote - Tunnel #7679 is saying).
2. Attach to an already running container or Dev Container.

For sure we want to do (1), and (2) is often requested for Remote - SSH as well. Forwarding the Docker socket is something we did initially, but the problem is that folder locations, etc are not natural, so the ergonomics wasn't awesome and auto-mapping source code didn't work. That's why Remote - SSH + Containers was implemented as more of a remote execution model.

[connor4312]

the problem is that folder locations, etc are not natural, so the ergonomics wasn't awesome and auto-mapping source code didn't work

hm, I'd be curious to dig more into this -- it sounds like some of these problems may be solvable, and think that undoubtedly some way to access docker containers over tunnels is valuable.

[Chuxel]

@connor4312 Yep, WSL + Containers and SSH + Containers works the same way, so this could follow suit.

The volume mapping problem is not something that can be fixed easily since it's managed by the docker host daemon, and the local machine has no idea what the remote filesystem looks like. So the key is executing the docker commands themselves on the remote host instead. The Dev Container CLI and everything uses pure docker/docker-compose commands to make this possible (and allows the use of alternate CLIs where appropriate). @chrmarti can explain - totally should be doable for Tunnels.

Another common request this approach solved is you don't need Docker installed locally to use SSH + Dev Containers. Technically for WSL it only needs to be present in WSL as well. Same should be possible here which would be even cooler.

We doc all this in VS Code docs including the old methods and their shortcomings: https://code.visualstudio.com/remote/advancedcontainers/develop-remote-host

[alexdima]

An interesting thing to explore would be the idea of resolver composition, like the following:

(UI machine) ---(ssh|remote-tunnels)---> (remote machine) ---(dev-containers|wsl)---> (workspace machine)

• on the remote machine we could spin up an extension host which would host the dev containers or the wsl extensions.
• we could encode 2 remote authories in one e.g. base64('ssh+{"dest":"machine","inner":"wsl+ubuntu20"}')
• the first level resolvers (ssh or remote-tunnels) would peel off the first layer e.g. ssh+machine
• they could then launch code server with a new argument e.g. ./code-server.sh --remote-authority=wsl+ubuntu20
• this could spawn an extension host which would host only dev-containers or wsl and then invoke .resolve() on them
• this could have the advantage of reusing the extensions as they are, but it has the disadvantage of potentially maintaining 2 remote extension hosts from the UI and it being a bit complicated to implement.

[jhrmnn]

In principle one can launch a Dev Container manually using the CLI and then create the tunnel from within the container, but of course it does create an extra friction, so I'm very much looking forward to have this implemented.

[jeremyn]

@jhrmnn Are you saying there's a way to get a tunnel inside a dev container right now? If I have VS Code open inside a container using the Dev Containers extension, and open a terminal, code tunnel doesn't find the new tunnel functionality, instead it just opens a file named tunnel in the container. If I exec into a running container from the host, code won't run at all, or gives a warning if I run code from its nested location within ~/.vscode-server.

If there's a way to get a tunnel running inside a container through some manual process, would you or someone else please sketch out how to do that, at a high level, as a workaround until this issue is resolved?

[jhrmnn]

I meant launching the container with https://github.com/devcontainers/cli, installing https://code.visualstudio.com/docs/remote/tunnels#_using-the-code-cli into it, and launching that. I tried that though and ran into issues with authentication. Not sure if that's specific to my setup or a more general issue

[chrmarti]

Dev Containers supports something similar with Remote-SSH, a similar approach could be taken here. With Remote-SSH the user first opens a workspace folder on an SSH server, creates a devcontainer.json in that folder and then reopens that folder in the dev container.

To create and attach to the dev container on the SSH server, the Dev Containers extension places an "Exec Server" on the ssh server through which it can spawn processes (like the Docker CLI) and a few other things. The Exec Server is generic and does not contain any functionality specific to containers (but is implemented in TypeScript). I wonder if the Rust-based VS Code CLI could implement similar functionality as that Exec Server, such that, the Dev Container extension could then use that to access the machine running the tunnel.

The Exec Server has the following functionality:

• (P0) Spawn a process with arguments, environment variables and optional cwd (current working directory) on the ssh server.
  • This forwards stdin, stdout and stderr streams between the spawned process and the extension.
  • When the process terminates, the exit code or process signal is returned to the extension.
  • There is a function for the extension to terminate the process.
• (P1) Spawn a process in a PTY with terminal dimensions (rows and columns), arguments, environment variables and optional cwd.
  • Similar functionality as above (no stderr stream).
  • Additionally there is a function for the extension to forward terminal resizing.
• (P2) A function for the extension to set default environment variables to avoid the need to resend these with each process.
• (P3) A function for the extension to connect to socket paths and ports on the ssh server.

Side note: To multiplex all of this functionality over a single connection, the Dev Containers extension is using the muxrpc NPM package. There is also a muxrpc crate for Rust, if these are compatible this might be useful for us.

The Dev Containers extension implements file operations using the Exec Server. I would make sense to implement these on the Exec Server directly to simplify cross-platform support.

[schiffy91]

Note that Remote-SSH doesn't allow connecting to Dev Containers running on a Windows server – it only supports connecting to a Linux/macOS server, which is a bit unexpected, given VSCode is a Microsoft product.

+1'ing this feature request, but I'd like to add that it would be great to allow tunnels to connect to containers on a Windows server, too, since, for whatever reason, that use case has seemingly been deprioritized by the VSCode team. I'm using Jetbrains Fleet/Spaces to handle this use case, but would prefer to keep everything simple with just VSCode.

[Goooyi]

@jhrmnn Are you saying there's a way to get a tunnel inside a dev container right now? If I have VS Code open inside a container using the Dev Containers extension, and open a terminal, code tunnel doesn't find the new tunnel functionality, instead it just opens a file named tunnel in the container. If I exec into a running container from the host, code won't run at all, or gives a warning if I run code from its nested location within ~/.vscode-server.

If there's a way to get a tunnel running inside a container through some manual process, would you or someone else please sketch out how to do that, at a high level, as a workaround until this issue is resolved?

Even this works, this approach has a limitation that each GitHub/Microsoft account can only have 5 tunnels registered, according to the doc

[chrmarti]

Dev Containers 0.312.0-pre-release adds support for connecting over tunnels when the tunnel machine is running Linux. Windows and Mac need additional changes.

[Apreche]

Dev Containers 0.312.0-pre-release adds support for connecting over tunnels when the tunnel machine is running Linux. Windows and Mac need additional changes.

Hooray! How does this work exactly? Is this correct?

1. Run VSCode on a Linux computer.
2. Have a project that uses devcontainers.
3. Open the project in the container.
4. Turn on remote tunnel access.
5. Go to another device and connect to the host through the tunnel.
6. Development will be inside the devcontainer?

[chrmarti]

You only run the tunnel on the remote host, everything else is done from a locally running VS Code:

1. Start tunnel on the remote host. (Can be done through VS Code CLI, no need for a desktop install.)
2. From your local VS Code connect to the tunnel.
3. Open a folder on the remote host.
4. Reopen folder in a dev container (F1 > Dev Containers: Reopen Folder in Container)

Feedback appreciated, thanks!

[aleleba]

I have created a docker image for create a tunnel from container: https://hub.docker.com/r/aleleba/vscode , this image come from ubuntu and make an installation of vscode and init a vscode tunnel. It also let you to install extensions on build, maybe this is a solution.

[chrmarti]

@aleleba That is another approach. The approach taken here allows you to use the Dev Containers extension to create a dev container on the tunnel's target machine. This now works when the host is running Linux. Will address Mac and Windows in a new issue. Thanks.

[jjcasmar]

Will this work on vscode.dev? I have just tested and apparently its not possible to install Devcontainer extension on browser

[Apreche]

You only run the tunnel on the remote host, everything else is done from a locally running VS Code:

1. Start tunnel on the remote host. (Can be done through VS Code CLI, no need for a desktop install.)

2. From your local VS Code connect to the tunnel.

3. Open a folder on the remote host.

4. Reopen folder in a dev container (`F1` > `Dev Containers: Reopen Folder in Container`)

Feedback appreciated, thanks!

Wait, is this container running on the client or on the remote host?
At least for me, the reason I want this feature is so I can use the vscode.dev web site on my iPad, but all the actual development is happening in a devcontainer on my workstation.

[aleleba]

For use my docker image you need to run the container and the container will create a devtunnel, the console will throw you a code you need to write on https://github.com/login/device to authenticate the tunnel with your account, then you can reach that tunnel from https://vscode.dev and you can connect from them. Also you can add a extension.json file whre you can specify the extensions you want to install, and it will install it on container creation before open the tunnel.

[vilgotf]

Will this work on vscode.dev? I have just tested and apparently its not possible to install Devcontainer extension on browser

You can locally install the Devcontainer extension after connecting to the tunnel.

Wait, is this container running on the client or on the remote host?

It's running on the remote host: client -> tunnel -> container.

[jjcasmar]

@vilgotf Can you explain how to install Devcontainer on locally? When I try to install it using the UI from vscode.dev, it just says that the extension is not supported on vscode.dev, even if I am installing on the tunneled machine.

[chrmarti]

The Dev Containers extension does not yet work with vscode.dev. You currently need to install it in the VS Code desktop app and can then connect through a tunnel to a container.

[schiffy91]

I switched to the pre-release version of dev containers on both my Mac (client) and Windows (server), both running the latest versions of their respective OS. When I connect to a remote tunnel and open a workspace with a .devcontainer, I now have the option to reopen it in a container. Only problem is it doesn't work. It just hangs, and when I press "Setting up Dev Containers (show log)" this is the output in the terminal:

[29217 ms] Start: Run: powershell -NoProfile -Command -
[29305 ms] Start: Run in host: id -un
[30833 ms]
[30834 ms] id : The term 'id' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:28

• [30836 ms] Start: Run in host: (command -v getent >/dev/null 2>&1 && getent passwd '' || grep -E '^|^[^:]:[^:]::' /etc/passwd || true)

[lattice0]

@chrmarti 😪 I'm on Samsung Dex, this is the only missing part for me to code

[jon77p]

@chrmarti 😞 Same here as others, but full support for using the Dev Containers extension with vscode.dev is the final piece to allow me to code remotely on iPad. Seems like the same response keeps coming up and it’s not much of a priority (I also had filed this here almost a year ago by now and might need to reopen the issue as it’s separate from this too).

[chrmarti]

We are currently tracking Dev Containers support for vscode.dev as #9059.

[lattice0]

@jon77p #9059 comment here to raise awareness. VSCode devs, please add this, so I can finally be free and code on my tablet 🙏🙏🙏🙏🙏🙏🙏🙏🙏, all x64 laptops get really hot and their batteries won't last. I want to use my tablet but don't wanna keep bounded to one specific computer neither I can pay for codespaces (too expensive in my country). Would be nice to code anywhere with the exact same environment
Thankssss

[donverduyn]

Much thanks for this fabulous feature!

I found out that automatic port forwarding currently doesn't work, when exposing ports from containers to the host if they are running inside a docker-outside-of-docker dev-container. With the docker-in-docker dev-container, this works fine!
It seems that the port detection fails when relying on the mounted docker socket, but i could be wrong.

Remote Host:
Pop!_OS 22.04 LTS
VSCode 1.83.1

Client:
MacOS Sonoma
VSCode 1.83.1

[chrmarti]

@DonnyVerduijn Could you open a new issue? This sounds like it should be independent of the docker-outside-of-docker feature.

[donverduyn]

@DonnyVerduijn Could you open a new issue? This sounds like it should be independent of the docker-outside-of-docker feature.

I'll wait for the 1.84 or 1.85 release to replicate. It seems insiders 1.84 currently has some unrelated problems that prevent replication.