I ran some benchmarks to see if this was a timing issue and it is. [from Docker for Mac] NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS eu-central-1 - amazonec2 Running tcp://52.59.1 v17.07.0-ce us-east-1 - amazonec2 Running tcp://34.200.238.228:2376 v17.07.0-ce us-east-2 - amazonec2 Running tcp://13.59. V17.07.0-ce us-west-1 - amazonec2 Running tcp://54.193.92.177:2376 v17.07.0-ce us-west-2 - amazonec2 Running tcp://52.27. V17.07.0-ce real 0m3.955s user 0m0.457s sys 0m0.311s [from Release Page] NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS eu-central-1 - amazonec2 Running tcp://52.59.1 v17.07.0-ce us-east-1 - amazonec2 Running tcp://34.200.238.228:2376 v17.07.0-ce us-east-2 - amazonec2 Running tcp://13.59. V17.07.0-ce us-west-1 - amazonec2 Running tcp://54.193.92.177:2376 v17.07.0-ce us-west-2 - amazonec2 Running tcp://52.27. そろそろ Docker の使いドコロだなというタイミングが来そうなので、表題の通り、以前にインストールしていた Docker Toolbox をアンインストールして Docker for Mac を試してみることにした。. Docker Toolbox をアンインストールする. Docker does not run natively on a Mac, therefore a translation layer is needed, which affects the implementation. Docker Toolbox is old and clunky. Docker for Mac is far more elegant, and it almost feels like you are using native Docker on the Mac host. V17.07.0-ce real 0m4.594s user 0m0.063s sys 0m0.065s [from Brew] NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS eu-central-1 - amazonec2 Running tcp://52.59.1 v17.07.0-ce us-east-1 - amazonec2 Running tcp://34.200.238.228:2376 v17.07.0-ce us-east-2 - amazonec2 Running tcp://13.59. V17.07.0-ce us-west-1 - amazonec2 Running tcp://54.193.92.177:2376 v17.07.0-ce us-west-2 - amazonec2 Running tcp://52.27. V17.07.0-ce real 0m4.185s user 0m0.488s sys 0m0.246s • from Docker for Mac: 3.955s • from Release Page: 4.594s • from Brew: 4.185s I didn't see a significant differences between those docker-machine binaries. My location is at Sydney, Australia. Here are more tests. I decided to find out what is causing my timeouts. I ran wireshark against both brew and docker-for-mac versions. Brew: Docker for Mac: You will notice that Brew DNS is looking up ec2.amazonaws.com where Docker for Mac is looking up ec2.us-east-1.amazonaws.com. Which returns the CNAME ec2.amazonaws.com. I don't know why the brew one doesn't perform this DNS lookup and goes directly to the CNAME. Maybe it caches the results somewhere while the Docker for Mac doesn't and so it has to look it up every time? I hope this helps track down this issue. Java. I am very annoyed that restarting docker for mac always re-links the docker-machine and so I have to unlink and relink the brew one after restarts. The difference between the brew binary and the official Docker one might be the choice of (See a similar issue ). Could you try running GODEBUG=netdns=go docker-machine and GODEBUG=netdns=cgo docker-machine to see if it makes a difference to either binary? My guess is that the cache mentioned in is the cache in the mDNSResponder process. I think you can flush the Mac's DNS cache with sudo killall -HUP mDNSResponder -- I wonder if doing that before running the fast binary would cause it to be slow? Are you sure both netdns=go and netdns=cgo have SAME behavior? ![]() Could you double check it? Because, if I understand correctly, Brew binary is using netdns=cgo by default, which utilize the cache stored in mDNSResponder service, so that might be the reason, Brew one is faster for DNS resolving. And official released binary is using netdns=go by default. So, if the dns resolver is the cause of the difference, then by using netdns=cgo on official released binary, you should get the same behavior as the brew one, and vice versa. And applying netdns=cgo to brew binary should change nothing. To verify what's DNS resolver is used by default for the binary, just run the docker-machine command with netdns=2 debug value, such as. (d1) DBG| go package net: using cgo DNS resolver So, if they behave the same, please verify whether the netdns really changed the default DNS resolver or not.
0 Comments
Leave a Reply. |