Dockerode features don't work with TCP daemon + certificates

I've setup a docker context using

docker context create machine --docker "host=tcp://192.168.99.120:2376,ca=/Machines/machines/default/ca.pem,cert=/Machines/machines/default/cert.pem,key=/Machines/machines/default/key.pem" --default-stack-orchestrator swarm

This works in my OS terminal and VSCode terminal, however VSCode Docker plugin says "Failed to connect. Is Docker running?"

I can have VSCode Docker plugin connect to my machine if I instead use this in my settings

  "docker.machineName": "machine",
  "docker.certPath": "Machines/machines/default",
  "docker.host": "tcp://192.168.99.120:2376",

But again, not with Docker context.

@atomi there's a lot of difficulty in mapping the certificate information from docker context into the options accepted by Dockerode; consequently we have not yet implemented it. There are two workarounds:

1. You can use the older docker.host / DOCKER_HOST + docker.certPath / DOCKER_CERT_PATH options (as you currently are).
2. You can use the docker.dockerodeOptions setting to set whatever you want to be passed to Dockerode, including CA settings.

Is there any progress on this issue? I am dealing with several docker contexts, some use SSH, others use TLS. SSH is working fine, but TLS fails to connect as mentioned by atomi.

The two workarounds from above don't work for me, as they would make all my contexts disappear except for the one and only "hard-coded" connection.

IMHO, instead of VS Code Docker plugin using the explicit settings "docker.certPath": "Machines/machines/default", "docker.host": "tcp://192.168.99.120:2376", it could 1) run 'docker context inspect ' 2) check whether "TLSMaterial" : "docker": [...] is non-empty => TLS 3) in case of TLS, a) set docker.host := value from "Endpoints" : "docker" : "Host" b) set docker.certPath := value from "Storage" : "TLSPath"

which would allow me to smoothly switch between my docker contexts.

Is my thinking too simple?

@thofil73 we're probably going to proceed with #3263, which as a side effect would fix this issue--basically, anything that the CLI could reach, would be reachable from the extension. Dockerode would no longer be needed.

Just a post that I tried setting up a Minikube context with:

docker context create minikube \
    --description "Minikube" \
    --default-stack-orchestrator kubernetes \
    --docker "host=tcp://127.0.0.1:64348,ca=$HOME/.minikube/certs/ca.pem,cert=$HOME/.minikube/certs/cert.pem,key=$HOME/.minikube/certs/key.pem,skip-tls-verify=false" \
    --kubernetes "config-file=$HOME/.kube/config"

And also saw Failed to connect. Is Docker running? Error: (HTTP code 400) bad parameter - Client sent an HTTP request to an HTTPS server.

The only downside to using native Docker CLI instead is that I couldn't seem to configure my Docker CLI to connect via the context either. I tried docker context use minikube but all I got was an asterisk next to the default config indicating it was the one in use when I ran docker context list. Docker contexts are incredibly frustrating.

Edit: discovered that if env variables are set, that overrides the context in use. The only way to switch contexts at CLI is to make sure no ENV variables are set to modify where Docker connects… I think. I was able to get docker context use minikube working by opening a new shell window.

Perhaps we can invent a way to switch docker configs within the Docker extension that doesn't use contexts? I'd like to be able to switch between Docker for Mac and Minikube within the extension but it doesn't seem easy/possible with the default configs. Minikube itself only supports environment variables via the minikube docker-env command's output. This is starting to feel like a different ask, that #2681 might be more appropriate to handle, namely to support multiple extension settings for docker endpoints and switch between them as an alternative to using contexts?

Second edit: an alternative (better) way of running Docker commands in a minikube context is to run minikube ssh first then just use the Docker CLI like normal. Works great. I’d probably have to use the Remote VS Code extension to mimic this in VS Code as if writing code in minikube directly. Not ideal.

With #3586 merged (fixing #3263), I'm going to speculatively close this issue, as it should be fixed.

Since we're using only the CLI to communicate now, as long as the CLI is working, the explorer views should too.

This has now been released in Docker extension version 1.23.0.