I see very long delays in resolving the IP of the container, is this expected?
$ time curl -o - http://192.168.64.2 > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 612 100 612 0 0 542k 0 --:--:-- --:--:-- --:--:-- 597k
real 0m0.017s
user 0m0.004s
sys 0m0.006s
$ time curl -o - http://docker.local > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 612 100 612 0 0 110 0 0:00:05 0:00:05 --:--:-- 152
real 0m5.561s
user 0m0.004s
sys 0m0.008s
$ pinata diagnose -u
OS X: version 10.11.4 (build: 15E65)
Docker.app: version v1.10.3-beta5
Running diagnostic tests:
[OK] docker-cli
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] lofs
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Docker logs are being collected into /tmp/20160331-225433.tar.gz.
Your unique id in bugsnag is: A5C65C17-C407-462C-AB01-8DECCFB46F44
Unfortunately yes this is outside our control, there seems to be a timeout of normal DNS before .local is tried. We may be going to switch away from using .local which would resolve this.
I’d like to vote for this issue as well. It makes docker.local pretty useless if it is so slow. We’ve had to resolve the ip on our own to account for this issue during the beta
to me this is a non starter. There is another thread for figuring out the IP by doing some greps and running an alpine container. It seems crazy that you have to jump through that many hoops just to be abel to get the IP in order to curl the box. Before I was able to run docker-machine ip default.
Same issue here - some commands seem to resolve the name very quickly, others take up to 10s.
With Docker Machine at least you could check for $DOCKER_HOST to find the IP, or assume localhost. Docker for Mac seems to be a step in the right direction with docker.local but resolution time of 10s makes it kind of useless for many applications.