Host configuration value should assume port 2375

[jlconnor]

I use a proxy between my development machine and my docker host. When I point the vscode-docker plugin to the proxied address I see this in the UI:

The API is returning 302 Found for the Docker API calls, but the plugin is not following the redirects.

[karolz-ms]

@jlconnor thanks for reporting the issue. What proxy software are you using?

[jlconnor]

@karolz-ms I'm using docker-socket-proxy. https://github.com/Tecnativa/docker-socket-proxy

[bwateratmsft]

@karolz-ms It's possible that Dockerode simply can't deal with redirects, or maybe there's an option you can pass that would make it possible.

[karolz-ms]

@bwateratmsft yes, that was my suspicion as well, I just did not have a chance yet to look into this 😔

[PavelSosin-320]

Dockerode doesn't support the recent Docker spec, i.e. context managed connection as I see in its documentation. Dockerode doesn't declare which spec it respects. It says only 1.40 API. When it works with the Daemon implementing the new spec 19.... and docker proxy following 19... spec it's hard to know where it fails. Did somebody test dockerode capability to work against the fresh reference docker daemon?

[PavelSosin-320]

@bwateratmsft It worsts to check the recent Dockerode release 3.2.1 from July before searching a bug.
Also ProxyConfiguration

[bwateratmsft]

It does seem unusual to me that the proxy is offering redirects instead of being transparent. That said, docker-modem definitely has code to follow redirects. It's not going to work if there is no location header in the response though, or if more than 5 redirects happen.

@jlconnor Can you verify if location is in the response headers and if it's not getting stuck in a redirect loop?

[PavelSosin-320]

If dockerode is built on docker SDK it is assumed that docker client is configured, i.e docker.config in ~/.docker : C:\Users\TheUser.docker\docker.config. Docker Desktop fills something strange, maybe because of its docker.exe doesn't support it. This file has a place to configure the proxy.

My home-made Docker-on CentOS creates the file with:
{
"auths": {},
"HttpHeaders": {
"User-Agent": "Docker-Client/19.03.12 (linux)"
},
"currentContext": "centos-ctx"
}
Does it look better? Maybe, worth to try.

[bwateratmsft]

Dockerode makes direct HTTP requests to the Docker daemon, so it doesn't care what's in ~/.docker/docker.config unfortunately.

[PavelSosin-320]

@bwateratmsft It looks not good because as I see in my docker.config Daemon expects a kind of handshake based on HTTP headers. The "standard" docker/kubernetes proxies require explicit in/out headers configuration and refuse to serve anonymous clients. Maybe, daemon REST API serves legacy clients differently on the different version end-points (/V1,23, /V1.40, etc. - Versioning )? HTTP and HTTPS end-points are served differently for sure.
Whether a specific proxy accepts the client's request can be tested using postman: send docker-info HTTP/HTTPS requests to the proxy and see what comes back. Postman processes redirect automatically - if everything is OK, protocol, headers, and body, it will show docker-info output.
Docker Desktop uses npipe end-point by default and it works for me only with Docker Desktop client only.

[PavelSosin-320]

@jlconnor I think that the following post Using docker behind the proxy can be helpful to you and it is perfect reference scenario which VSCode Docker plugin must support with zero gaps. The default docker end-point uses socket or npipe. It is integrated into the docker package. Proxy is needed to access services, to access Docker engine proxy is redundant. The proxy URLs in the Dcker.config is Reverse proxy. It doesn't do redirect.
I just made the direct check: Run my docker in WSL CentOS7 + add TCP socat TCP Listener and:
docker command from CMD using -H tcp:/localhost:2375 works! Postman REST request to localhost:2375 doesn't work!
Docker end-point is either TCP or NPipe end-point. Client which uses HTTP API as in Dockerod is wrong. Only pure TCP Proxies are allowed.

[jlconnor]

@bwateratmsft Ok, the mistake here seems two fold.

First mine. While trying to verify the return of a location header I discovered the proxy IS transparent. The redirect is coming from my web server hosted on the same server (80 and 443 both redirect to different ports)

Second VSCode. When I export DOCKER_HOST on the cli, docker automatically assumes port 2375. When I add the same value to the docker plugin's Host, it does not assume port 2375, but rather one of my redirecting ports (I'm assuming 80, but didn't verify).

When I explicitly add port 2375 to the Host configuration value, the plugin works.

Sorry about the confusion and I hope this is helpful.

[PavelSosin-320]

@bwateratmsft Anyway I used the chance to look into dockerod code and found that it uses docker-modem. Docker-modem uses HTTP and HTTPS NodeJS objects to send requests to Docker daemon. But Docker daemon end-points are sockets, Linux, Pipe, TCP, with or without TLS. It doesn't need all HTTP mechanics with content type, encoding, manifests, upgrades, and redirects. All these things are necessary for Proxies and Load balansers. NodeJS Socket object is the right interface for communication with daemon. Indead, sockat works without any HTTP.

[bwateratmsft]

@jlconnor I think this (with the new title) relates to apocas/docker-modem#121. Like #2164 (which created that issue in docker-modem), I think this becomes external, because docker-modem chooses the ports, not the Docker extension.

There is a setting in the Docker extension, docker.dockerodeOptions, which will allow you to pass any arbitrary settings object to Dockerode--it's heavy-handed but might work in this situation. If this setting is used we "blindly" pass it to Dockerode--no validation of any kind is performed other than to parse it as JSON.

[jlconnor]

@bwateratmsft Thanks for the help here. I think I'll just leave the explicit port number in the config. Probably better all around that wat