Document usage of new DockerApi({host: '//./pipe/docker_engine'}); for windows

[davclark]

Or, make it the default when host is not specified on windows? Currently, the default is /var/run/docker.sock on all platforms, which is an error on windows.

Happy to submit a pull request to this effect. It's a trivial change. Dockerode implemented it a couple weeks ago, though it's been a known feature for a while - I'd recommend something almost identical:

datmo/datmo@7432d61

[davclark]

Sorry - ignore that link. Here is the relevant issue in dockerode, which will work if you set socketPath to //./pipe/docker_engine, and somehow that works, see: apocas/dockerode#290

Setting path in harbor-master to the same does not work. One fundamental point of my mystification is that I don't actually understand the meaning of the // in docker for windows. It seems to have been a temporary measure in referring to moby paths, that quickly fell out of usage again... except in this one case.

I guess the doc changes from that python repo (which is what I was looking at) are still pretty good though...

[styfle]

The linked issue appears to be talking about Docker Toolbox which is not recommended.

Docker Toolbox is for older Mac and Windows systems that do not meet the requirements of Docker for Mac and Docker for Windows. We recommend updating to the newer applications, if possible.

I have used docker-remote-api successfully with Docker For Windows which is recommended by the Docker team.

[davclark]

In ES6:

import DockerApi from docker-remote-api;
let docker = new DockerApi({host: '//./pipe/docker_engine'});

Works on docker for windows. I guess that wasn't clear. Sorry for the confusion!

[styfle]

It doesn't look like we have any tests that run on Windows so I don't think it would be a good idea to modify the code.

The user running the code can assign the host parameter as you put in your comment.

Is the windows host path documented anywhere? If so, you can go ahead a create a PR and add it to the README to show Windows Usage and link to the docker documentation.

Thanks 👍

[davclark]

I am unable to locate definitive documentation on this. As I often say, if I am somehow missing something, I would VERY MUCH appreciate a pointer to reliable Docker on Windows documentation.

Anyway, windows named pipe support is implicitly documented, e.g., in docker-py (one of the "official" clients, so probably will stay up to date). The named pipe path is defined here:

https://github.com/docker/docker-py/blob/899f3cf5a86784dc63eda9545bde73cffc236f0b/docker/utils/utils.py#L21

And used here, if there is no address defined for the Docker socket on windows:

https://github.com/docker/docker-py/blob/899f3cf5a86784dc63eda9545bde73cffc236f0b/docker/utils/utils.py#L219

So, does that count as documented? I would say no! But your call. I suspect this GitHub issue is probably enough for making this syntax somewhat discoverable...

[styfle]

@davclark Thanks for the explanation! Since this isn't officially documented, let's just leave this issue open for other users who run into the same issue (hopefully it's not many).

If other users start reporting this issue, this might be worth bringing complaints upstream to the Docker team so it can be officially documented. 🐳

[styfle]

Related: docker/for-win#1889

It basically says that the environment variable COMPOSE_CONVERT_WINDOWS_PATHS can be set to 1 to allow the default path /var/run/docker.sock to work on Windows.

The docs mention that Windows users should always set this.

I guess this is only applicable to Docker Compose.

[davclark]

Yeah - that's a whole other can of worms that broke lots of stock users of docker-compose on docker for windows! Hopefully the default behavior will return to "working" in the next stable release of docker for windows... (right now you need to explicitly set COMPOSE_CONVERT_WINDOWS_PATHS)