Support opening Dev Containers when running from within WSL or SSH

[chrisdias]

This was the first scenario presented to me at PyCon:

Insiders on Windows (for now)
F1, Select Default Shell -> WSL
Open a terminal inside VS Code, you get the WSL shell on /mnt/c/...
git clone a repo with a .devcontainer folder (and Dockerfile, etc.)
cd into the folder and reopen with code-insiders .

The folder is opened in WSL, which makes sense.

However, what if I want to actually open the folder in a container? The expectation was that I would get the prompt to reopen the folder in the container.

To work around this, I would have to go to a cmd shell or power shell and do the clone/open from there. But, I'm simply using the WSL terminal as my default terminal everywhere on Windows, so this is unnatural.

//cc: @sptramer

[egamma]

@chrisdias Work around from WSL:

• New Window
• Open Folder in Container
• Navigate to the Linux file system location.

[Chuxel]

While the issue is about WSL, SSH is also mentioned. The SSH flavor of this is tricky, Right now you can use a remote docker host from a container by creating a local devcontainer.json and forwarding the Docker socket. To accomplish what we're describing here, we'd need to automatically create this tunnel and then add extra logic to automate the required alterations to the source code mount point.

[mhykes]

I just tripped over this. I used Remote-SSH to remote into an ubuntu server where I have docker swarm running. I was expecting to be able to then easily launch and connect to a dev container running on the remote server.

If the intent of using Remote-Containers is to open a repository on the remote server's docker container for consistency, it seems counter-intuitive that I should have to install git and clone the repository locally before I can then open it in the remote container.

I'll try Chuxel's link and see if I can get that to work. If the Remote extensions could handle this natively it would make life a lot easier.

[Chuxel]

@mhykes Yeah, the optimized use case is remotely accessing local containers, rather than remotely accessing remote containers. (We don't have Remote OS to Remote Container OS optimized... or Remote - Remote - Containers if you prefer. ) As described in the link above, you can configure local docker to connect to a remote host. At that point attach works. To use devcontainer.json, you have the added step of telling VS Code where to find the source code.

[mhykes]

The ideal would be a situation where all any developer has to install locally is VS Code and the Remote Extensions. More work for preparation would need to be done on the container server, but that's a better use of time because the work only has to be done once and then all developers on the team can benefit.

[lbssousa]

I'm currently working with a laradock-based project using Docker Destop with WSL2 backend. My project is entirely within my WSL2 distro i.e. my project files are in WSL2 root filesystem (VolFs) and I prefer to use WSL-side docker binaries to start my containers, because Windows-side docker binaries still mess up file ownership/permissions of my shared volumes.

In order to use VSCode properly with Remote Containers in my project, I currently need to open a WSL terminal and bring up my containers manually from there before opening VSCode, because Remote Containers will try to bring them up using Windows-side docker binaries.

Please add a feature to allow Remote Containers to bring up containers from within WSL VolFs using WSL-side docker binaries!

[dzegarra]

Like @lbssousa, I also have my source files within the WSL2 virtual drive. That's because the performance for shared drive between the WSL2 machine and the host is still very slow compare to the native Linux system.

That's the main reason I had a dual boot with Linux just to work on my Javascript projects. Compiling my JS projects under Windows or in WSL2 under Windows is at least 5 times slower.
I'm already benefiting from the RemoteContainers extension but I manually have to create the docker container environments for my projects.

When I try to create the Docker container environment from a devcontainer.json file VSCode v1.42.1 always tries to find in the Windows file system the current folder which is within WSL. And it fails inmediatelly of course.

[stuartleeks]

My main reason for wanting this is preference for working in bash with WSL. Recently I've found that there are some codebases are not usable with devcontainers on Windows due to the performance overhead of the translation layer when mounting windows volumes in Docker. An example is https://github.com/lawrencegripper/azbrowse/ where hitting <Enter> in the integrated terminal takes many seconds to re-display the prompt (it uses bash-git-prompt to give a rich environment, but the overhead of getting the git status is unusable).

Is there any timeline for enabling this scenario?

[guillemglez]

Coming from the previous conversation, I'd like to add some points to better translate this into a feature request more pointing to the SSH remote host use case.

Feature request

When connected through SSH in a remote development session, host’s Docker containers should be discoverable and VSCode should be able to use its Docker daemon for container remote development.

Motivation

A common setup is SSH-tunneling a Docker daemon of a shared Linux development server.

This is described in these pages:

• https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host

• https://code.visualstudio.com/docs/containers/ssh

When using remote container development many lacks are found, e.g. UID/GID are not updated when using dev containers in this context. Two workarounds are possible:

• Create a container with a postCreateCommand by hardcoding UID/GID in .devcontainer.json. Also include a bind to an absolute path to a copy of the workspace in the remote drive (these parts of the file are not to be committed in SCM).

• Create a container manually, create a user and map UID/GID, mount workspace; then attach VSCode with a custom configuration file specifying remoteUser.

This feature would bring the user experience to the same level as when using a local Docker daemon.

[stiiz]

This tutorial on how to setup vscode to open containers on a remote virtual machine is not clear

https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host

Can you make a step by step tutorial/example on how to achieve this?

[egamma]

Support for opening a remote container is in the April release.

[tkislan]

@egamma Issue mentioned opening in containers through SSH as well .. do you plan on adding support for that as well?

[davidbarton]

Same question. It seems only WSL support was added and issue has been closed as resolved. Is the SSH support included as well? Where can we find setup instructions?

[chrmarti]

We continue tracking the SSH case in #2994.