[worked around] Docker HTTP(S) API no longer available in beta9?

Expected behavior

There will be an HTTP(S) URL (or it will be possible to configure one) under which Docker API will be exposed.

Actual behavior

With docker.local removed in beta9 can’t seem to find such API. There’s of course unix:///var/tmp/docker.sock but due to https://github.com/docker-java/docker-java/issues/537 I can’t use it with IntelliJ

Any hints enabling me to use non-Unix socket API are welcome. TIA.

Information

  • the output of:
    • pinata diagnose -u on OSX

OS X: version 10.11.4 (build: 15E65)
Docker.app: version v1.11.0-beta9
Running diagnostic tests:
[OK] docker-cli
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Docker logs are being collected into /tmp/20160429-093730.tar.gz
Most specific failure is: No error was detected
Your unique id is: 4A2CE3DE-AD5B-41EB-AC87-332140BE12DA
Please quote this in all correspondence.

2 Likes

I have a similar issue. I have a library that uses tcp/http to connect to the daemon and it no longer works. In Beta 8, I was able to use 192.168.64.2.

Can you just connect to localhost? Beta 9 should be exposing your containers on localhost now.

Sadly, no. On beta9 ‘localhost:2372’ works on Windows, but not on OS X. This also breaks lots of third party libraries, such as the excellent testcontainers, which is used for lots of QA type workflows.

FYI @richnorth

Also see Docker4Max compatibility issues with java client libraries

Yes, testcontainers uses the docker-java/docker-java library which is unfortunately affected by this change. It’s the specific combination of Java, unix sockets and OS X that are the problem.

Basically, TCP socket support going away on OS X is a bit of a shock for Java library authors given that up until now it’s always been the first choice.

If any docker contributors are reading, I’m wondering:

  • if there was a strong reason why TCP connections to the daemon had to be removed along with nat networking mode, or was it simply an accidental casualty of the change?
  • are there any plans / options to reinstate TCP daemon sockets in a future beta, or is there a general intention to deprecate TCP sockets on OS X and/or other platforms?

Having a clearer understanding of these would help us understand and plan what to do about this, so we can do the right thing!

1 Like

The name “docker.local” is gone (it was a beta construct anyway). You can still do what you did on a different IP on onto the unix socket at “/var/tmp/docker.sock”.

IF YOUR TOOL IS IN A CONTAINER
…you can still get to the daemon. Try (from any container):

curl 172.17.0.1:2375/_ping
curl 192.168.65.2:2375/_ping

IF YOUR TOOL IS IN OSX
…you can still find another way. You can use “socat” to export the unix socket as a TCP socket:

brew install socat
nohup socat -4 TCP-LISTEN:2375,fork UNIX-CONNECT:/var/tmp/docker.sock &

…and to test it on OSX:

curl localhost:2375/_ping

BUT…
But before that I would try to set the DOCKER_HOST variable to “unix:///var/tmp/docker.sock” - these tools should be looking for this variable and trying the TCP port as a fallback. Try to curl into Docker for Mac unix socket (not TCP):

curl --unix-socket /var/tmp/docker.sock localhost:2375/_ping

If DOCKER_HOST works there will be no need to install “socat”, of course.

3 Likes

Yes I can, but that’s not the issue. What I need is a way to contact docker daemon API w/o using unix:// sockets. Andrevtg has proposed a successful workaround above.

Thanks for a successful workaround with socat. :slight_smile:

The TCP socket going away was an accidental byproduct of the networking changes, it is still there but you cannot at present reach it. It was not intended to be a permanent feature though, and will probably go away in a few weeks when Windows no longer needs it. We may add an https socket at some point, unconfirmed. I think you are best off using socat or running tools in a container, or using a container to forward the socket to localhost (ie socat in a container with published port) until Java is fixed to be able to understand sockets. There will be the same issue on Windows as new docker uses a named pipe there.

Thanks for the clarification! It’s also useful to know that TCP sockets may be going away on Windows too - that will help plan ahead.

Thanks for the workaround. You can also proxy the traffic using an ambassador container

docker run -d -p 2376:2375 svendowideit/ambassador 172.17.0.1 2375

Connect using docker -H localhost:2376

:slight_smile:

That will open port 2376 to the world. As there is no TLS this isn’t recommended. You might want to consider running with -p 127.0.0.1:2376:2375

1 Like

It’s also worth noting that @andrevtg’s solution has a similar problem as highlighted in Using pycharm docker plugin with docker beta

You’re right, it is better to adjust socat to expose the port in 127.0.0.1 only. I understand it was required for use in local build tools where TLS would be just a real pain, so exposing the socket in localhost would be good enough.

If you are doomed to work on corporate quarters this is usually a non-issue (ports are usually closed anyway, even to the person next to you), but on public wi-f they are not. I keep forgetting that :slight_smile: .

No offense, but this is a horrible policy to impose on developers - if it’s for security reasons we can use SSL (https). Aside from a security standpoint why remove TCP?