Improve default behavior in VS Code Remote scenarios

[ejizba]

Currently, the Docker extension is defaulting to a UI extension in all scenarios (SSH, Dev Containers, and WSL). That means it will show local containers/images, but anything accessing the file system or a terminal will fail. If users want to access remote containers/images, they must run as a workspace extension by adding this to their settings:

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": "workspace"
}

Here is my opinion of the ideal behavior for all three VS Code Remote scenarios:

SSH

This should default to a workspace extension. This would display containers/images from the remote machine and most things should "just work". It sounds like users want this as well (see #924).

Dev Containers

Running as a workspace extension (aka "Docker in Docker") is generally confusing and so we want to avoid it. However, this scenario inherently deals with a "Dockerfile" so we can't completely ignore it. Ideally this defaults to a UI extension. The explorer will show containers running on the local machine and we should show an understandable error if the users tries to run a command that requires the terminal or needs access to the file system.

This scenario could be improved if VS Code gives us the following:

1. An API to create a terminal on the local machine (instead of in the container) to run commands like "Build Image"
2. An API to access the file system in the container so that we can run commands like "Add Docker Files"

If the user is running as a workspace extension, we should show a custom message instead of the default "Unable to connect to Docker.". It should direct users to either switch to a UI extension or set up docker in docker (if they're feeling adventurous).

WSL

The ability to run docker inside WSL is pretty recent and it's unclear how well it's supported. If we were in an ideal world and docker worked great in WSL, I think this behavior should be similar to SSH. Otherwise, I think it makes sense to just pick a default and document how to change it if desired.

Questions for VS Code Remote team:

1. Can we have a different default for "Dev Containers" (UI) vs "SSH" (Workspace)?
2. How do we detect if our extension is running in remote - and what kind of remote? (So that we can customize the error message)
3. Is there an official API to create a terminal on the local machine as a UI extension?
4. Is there an official API to access the file system inside a container when running as a UI extension?

[egamma]

@EricJizbaMSFT

Distinguishing between the SSH and the Container context makes sense.

Can we have a different default for "Dev Containers" (UI) vs "SSH" (Workspace)?

The default will remain static, what is important is that the extension adapts to the different contexts. See the next question for how this can be done.

How do we detect if our extension is running in remote - and what kind of remote? (So that we can customize the error message)

vscode.env.remoteAuthority allows you to determine both whether the extension is running remotely and under which remote authority it is running. The API will be in 1.35. Please see the API doc.

The Resolver mechanism is documented here https://github.com/microsoft/vscode/blob/afb08370356e0625b40d2ea42aa7dc0513aa2c39/src/vs/vscode.proposed.d.ts#L131.

For example, the VS Code Remote Containers extension contributes a 'dev-container' and 'attached-container' authority resolver https://github.com/microsoft/vscode-remote-containers/blob/7211cca5161cb3ca74749de1e597a925f664afd4/src/extension.ts#L27.

Is there an official API to create a terminal on the local machine as a UI extension?

Please see the PR #907.

Is there an official API to access the file system inside a container when running as a UI extension?

Not yet, but this is on our backlog. Until this is in place you can disable the commands that need file system access as is done in the PR #907.

//fyi @Chuxel @RMacfarlane @kieferrm @jrieken

[jrieken]

small refinement to the new API: microsoft/vscode#74188 (comment). The vscode.env.remoteAuthority is now either undefined or an object of type { prefix: string} - instead of being just a string. It toString's to the full value tho. Reason being is that a remote uri usually looks like this vscode-remote://ssh+something-machine-specific/path and that only the ssh part of the authority is important.

[jrieken]

FYI: For 1.35 will not ship with vscode.env.remoteAuthority. Full background here: microsoft/vscode#74188 (comment). You can use the proposed api ExtensionContext#executionContext

[ejizba]

The default will remain static, what is important is that the extension adapts to the different contexts.

@egamma So you're saying we can only specify one default of "ui" or "workspace" in our package.json? That's understandable, but then we need to decide on the default. We received feedback in #924 that users expected us to default to "workspace". Would that make sense to you? (Assuming we improve the error messages in the Dev Containers scenario first). Specifically, a few of the comments that stood out to me:

... the most strange behavior is that this extension is one of the few no-theme related extensions that installing on ssh is disabled, it only allows to install locally.

My expectations were also that it would use the docker socket in the remote, but it didn't work like that.

[pd93]

@EricJizbaMSFT My expectation is that it would, by default, use the remote docker socket over SSH and the local socket for WSL and/or Containers. This is because current WSL/Container development scenarios require that we connect the docker binary to the Docker for Windows TCP port - so we are essentially using local docker.

A bit of forethought though. When WSL 2 comes out, users might want to connect to the remote docker socket within the WSL itself - not sure if this effects the default setting, but it stresses the need for the user to configure the default themselves.

[egamma]

@egamma So you're saying we can only specify one default of "ui" or "workspace" in our package.json? That's understandable, but then we need to decide on the default.

The default would remain "ui" for now.

We received feedback in #924 that users expected us to default to "workspace".

This is great feedback, but we have tried this default in the past and it didn't work well (I can dig out the feedback). A UI extension also has the benefit, that it is just available and doesn't have to be installed into each container. For this reason our proposal is that the docker extension remains a UI extension for now. We are discussing improvements for extensions that could run on both sides (e.g. the Chrome Debugger Extension also belongs into this bucket).

[egamma]

@pd93 have you tried to keep the docker extension running as a UI extension but you define the docker.host setting to point to the remote docker socket over SSH?

[benc-uk]

I have Docker running in WSL2 (seems to run great BTW) so naturally I tried to set
"docker.host": "/var/run/docker.sock" but that results in an error

[Chuxel]

@benc-uk @pd93 @egamma Yeah, WSL2 is likely going to feel more like running it in a remote VM is my bet.. Unless Windows put specific code in place, sockets local to the Linux OS wouldn't show up in Windows -- and they'd need to be translated to named pipes too. (They didn't do it for WSL1 - you had to expose a Docker TCP port..)

I need to get a WSL2 machine up to see more -- but my bet is for WSL2, you'll want the option to run as a workspace extension.

On a related note, from the Remote - Containers extension, this will probably look like a remote docker host too (which we're not optimized for but support). Depending on uptake, it could increase the priority of that scenario.

[benc-uk]

I fixed it by putting

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

In my user settings.json, forcing the extension run remote in WSL, and I didn't set anything for docker.host or the DOCKER_HOST env var. It picks up the socket automatically

[jiayaoO3O]

@benc-uk Hello, if my remote host has docker installed and the local computer is not installed, can I use remote-ssh to connect to the remote development server and then use the docker of the remote server by the remote-container mode,so that it works like a local docker?Does the remote-container mode require docker to be installed on the local computer?

[Chuxel]

Hello, if my remote host has docker installed and the local computer is not installed, can I use remote-ssh to connect to the remote development server and then use the docker of the remote server by the remote-container mode,so that it works like a local docker?Does the remote-container mode require docker to be installed on the local computer?

The Docker CLI is required locally to use the Remote - Containers extension. However, you can use the Docker extension with Remote - SSH without the extension being local using "remote.extensionKind" as described above.

See here for details on using Remote - Containers on a remote docker host.

[jiayaoO3O]

Hello, if my remote host has docker installed and the local computer is not installed, can I use remote-ssh to connect to the remote development server and then use the docker of the remote server by the remote-container mode,so that it works like a local docker?Does the remote-container mode require docker to be installed on the local computer?

The Docker CLI is required locally to use the Remote - Containers extension. However, you can use the Docker extension with Remote - SSH without the extension being local using "remote.extensionKind" as described above.

See here for details on using Remote - Containers on a remote docker host.

But the function I want is: the local computer does not install docker, and the remote computer installs docker. After my local computer connects to the remote computer through remote-ssh, the remote-container function is used on the remote computer,the behavior is the same as using remote-container on the local computer

[benc-uk]

Just an observation on the comment "The ability to run docker inside WSL is pretty recent and it's unclear how well it's supported"

Docker recently posted about the future of Docker on Windows 10, and the summary is - running Docker in WSL (i.e. WSL v2) is going to be the default way of running Docker going forward
https://engineering.docker.com/2019/06/docker-hearts-wsl-2/

I think supporting Docker running in WSL is very important

[ejizba]

FYI - our current plan is to change the default from "UI" to "Workspace".

The only scenario where a default of "UI" makes sense is the Dev Container scenario. However, we view Docker as a "Workspace" extension in SSH/WSL much more compelling than Docker as a "UI" extension in a Dev Container. The former enables new functionality not possible before VS Code Remote was launched. The latter provides the same functionality that can already be achieved with a local VS Code instance.

Plus we just keep getting feedback that users expect the docker extension to run in their remote machine and it's not obvious how to switch from local to remote.

@egamma you seem to be the main person on this thread advocating for a default of "UI" so feel free to chime in. In regards to your comments:

This is great feedback, but we have tried this default in the past and it didn't work well (I can dig out the feedback).

If you can dig out the feedback that would be great. I'm guessing the feedback was only related to the Dev Container scenario. We don't expect it to be perfect, but we do hope to make that as painless as possible when defaulted to "Workspace" (clear error messages, etc.).

A UI extension also has the benefit, that it is just available and doesn't have to be installed into each container.

I see your point, but this is how the vast majority of extensions work with VS Code Remote today, so it doesn't seem like a deal-breaker.

[pd93]

FYI - our current plan is to change the default from "UI" to "Workspace".

Haven't been using this extension recently because I've been doing all my work in Remote SSH/WSL environments. This is good news!

[ejizba]

@pd93 regardless of the default, you should be able to use this extension in SSH/WSL environments with the setting mentioned above:

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": "workspace"
}

[ksawerykarwacki]

@EricJizbaMSFT this works for remote development but what about scenario when I work local but only uses wsl for docker? On current tech preview this doesn't show anything. Are there any plans to support docker context?

[ejizba]

@ksawerykarwacki have you tried the above setting? You can do either "workspace" to have the docker extension run in WSL or "ui" to have it run outside of WSL. Note, you have to reload VS Code after changing that.

[parence]

I am able to see all of my containers and images in an SSH environment when using:

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": "workspace"
}

Running images, viewing container logs, stopping containers and attaching a shell works, however the only thing that does not work for me is right clicking on a running container and selecting 'Attach Visual Studio Code'. This fails because I don't have the docker cli on my host system.

Since I am running the extension in 'workspace' mode on my remote (ssh), is there a way of using the remote docker cli for this purpose too?

[bwateratmsft]

@parence The "Attach Visual Studio Code" command is part of another extension, their repo is here: https://github.com/Microsoft/vscode-remote-release. Can you file the feedback about that command there?