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.
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.
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.
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!
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):
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):
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.
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.
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 .
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?
