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.