VSCode Freezes During Dev Containers Initialization with Docker Desktop WSL 2 Tech Preview

[nimashoghi]

When I load Docker dev containers on Docker Desktop WSL 2 Tech Preview, VSCode hangs during the loading process.

• VSCode Version: 1.37.0-insider
• Local OS Version: Windows_NT x64 10.0.18945
• Remote OS Version: Alpine/Debian/Ubuntu (Doesn't work on any)
• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. Use Docker Desktop WSL 2 Tech Preview
2. Load any dev container (Note: Right now, docker-compose does not work with Docker Desktop WSL 2 Tech Preview, so you must use the regular Docker version here)
3. VSCode will hang during the initialization phase.

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

[egamma]

Notice that this is Docker Desktop WSL 2 Tech Preview which isn't supported and tested yet.

[Chuxel]

After debugging a bit, this appears to be due to this upstream issue: apocas/dockerode#526

While docker commands execute correctly, docker ps does not return the WSL context, so nothing appears to be started. VS Code is waiting for the containers to be running.

FYI @chrmarti on Docker on WSL2

[Chuxel]

I hacked in a change to docker-modem to so you can set DOCKER_HOST to the WSL named pipe to see if it works, and I was able to get a dev container up and running. Obviously this is all preview software, so mileage may vary, but at least right now these dependencies appear to be the primary problems.

[Chuxel]

To update the thread on the investigation here, it turns out this is an general issue with both the Docker extension and Remote - Containers when multiple local contexts are in use. It's actually not a WSL2 issue, it's just that most people only have one docker context configured: "default". Default is the also the context that pays attention to environment variables like DOCKER_HOST as well, so even if you are using docker-machine or pointing to a remote host, you're typically still in the default context.

You can see your current docker context by running docker context inspect. All contexts can be seen by running docker context ls. Here's what you will see with the WSL2 tech preview active:

NAME                DESCRIPTION                               DOCKER ENDPOINT                  KUBERNETES ENDPOINT   ORCHESTRATOR
default             Current DOCKER_HOST based configuration   npipe:////./pipe/docker_engine                         swarm
wsl *               Docker daemon hosted in WSL 2             npipe:////./pipe/docker_wsl

The problem is dockerode and docker-modem do not make use of the Docker CLI and therefore do not have any idea what the current local context is. Unfortunately, it also doesn't accept alternate named pipes in the DOCKER_HOST environment variable (due to an incorrect check), so setting it to the correct pipe there does not work either.

In order to resolve this fully, we will need to call docker context inspect (potentially among other commands) to get the correct context values to pass into the constructor of dockerode. The alternative would be deprecate the use of the node module in favor of CLI calls. This is easier said than done since there's a number of variations of the config that need to be tested and the constructor is invoked in a number of spots (some synchronously).

Some refactoring will be required to make this all work.

[nimashoghi]

@Chuxel You can also read from the Docker local config (~/.docker/config.json) and read from the currentContext key in that JSON object. If this key doesn't exist, then the context is the default context. Each context will be stored under ~/.docker/contexts/{id}/. This directory contains a meta folder which contains a meta.json file that like this:

{
    "Name": "test",
    "Metadata": {
        "StackOrchestrator": "swarm"
    },
    "Endpoints": {
        "docker": {
            "Host": "unix:///var/run/docker.sock",
            "SkipTLSVerify": false
        }
    }
}

We can use this to extract the proper Docker host.

I know Docker Compose had a similar problem which was ultimately rooted in the docker-py Python package. I submitted a pull request with a basic implementation of this a couple of days ago: docker/docker-py#2429

[Chuxel]

@nimashoghi Yeah one of the questions is whether the json files are intended to be consumed directly or if the files are considered "internal" and abstracted by the CLI. I'll be curious if the PR you submitted is accepted. It should be a lower overhead call - though even with the CLI approach it only is happening once per invocation.

[apocas]

Hi guys, dockerode developer here.

@Chuxel Do you want to contribute your hack to docker-modem? :)

https://github.com/Chuxel/docker-modem/commit/47e7a97a53b4a915e9a01d01e83421a0074b1e59

[Chuxel]

@apocas Yeah, was thinking about doing that part as you can see from the branch.

The bigger part of the work is to actually get the context information and pass the right information into the constructor.

Specifically:

1. Call docker context inspect to determine the correct context and parse the returned json object (or manually read the related json files out of .docker)
2. Implement logic to determine the correct path of the certs if not returned by the command (you can see IN MEMORY as the TLSPath)
3. Generate an object with the options to pass into the constructor

I could contribute this as well since I have a variant of this working for Remote - Containers. There's also a PR for the Docker extension here with part of this logic (it doesn't handle certs). microsoft/vscode-docker#1290

Are you interested in both, or just the tweak to allow alternate named pipes that is in Chuxel/docker-modem@47e7a97?

[bwateratmsft]

@Chuxel the down side to the above is that docker context inspect is going to take something like .5 seconds (or more)...so if dockerode was to take over this, constructing the dockerode object would go from microseconds to fractions of a second.

It's an issue on its own, but the Docker extension refreshes this object fairly often, enough that for it to result in a docker context inspect call every time would be bad.

Perhaps dockerode should only check docker context inspect if socketPath/DOCKER_HOST/etc. are all unset?

[Chuxel]

@bwateratmsft Yeah that's the problem - it would need to be an option (or a separate "getLocalDockerContext" static method) rather than always done since there is going to be some level of perf impact. I can send you the PR for Remote - Containers internally. It caches the context for 10s during activation to avoid repeated hits. After that, the dockerode objects are reused in the Remote - Containers case.

The alternative is to not rely on the CLI abstraction and try to read the json files directly as @nimashoghi suggested. You'd read config.json in the DOCKER_CONFIG folder (which defaults to ~/.docker), look at the context there, and then search for the matching meta.json by iterating through the sub-folders of $DOCKER_CONFIG/contexts/meta . Any logic the CLI layers in would have to be added to the code over time.

One other issue that this won't fix is that we won't be able to support (at least easily) scenarios where certs are stored in a Docker credential helper and a remote host. In that case, the certs are not in the file system to pass along. That said SSH URIs were introduced (and the PR for this was recently merged for docker-modem 🎉), so that would likely be what we recommend in these scenarios since it should actually be more secure.