Docker-compose very slow

Docker Desktop
1

Expected behavior

docker-compose up should bring up container immediately

Actual behavior

takes a minute or more to bring up container

Information

pinata output:

OS X: version 10.11.5 (build: 15F34)
Docker.app: version v1.11.1-beta13.1
Running diagnostic tests:
[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/20160531-225631.tar.gz
Most specific failure is: No error was detected
Your unique id is: B94632E8-1BF2-48E4-9238-5A9B0E3CE26D
Please quote this in all correspondence.

docker-compose file:

version: '2'
services:
    ubuntu:
        image: ubuntu:16.04

Steps to reproduce the behavior

  1. run docker run --rm ubuntu:16.04 /bin/bash and observe container comes up quickly after downloading image
time docker run --rm ubuntu:16.04
real	0m1.215s
user	0m0.013s
sys	0m0.012s
  1. with image already downloaded run docker-compose up on the above docker-compose file
  2. docker-compose up takes significantly longer to bring up container
time docker-compose up -d
Creating network "test_default" with the default driver
Creating test_ubuntu_1
real	1m11.591s
user	0m0.429s
sys	0m0.121s
  1. with a remote docker engine running on a bare metal ubuntu 16.04 node (provisioned with docker-machine -d generic) has the following run times
time docker run --rm ubuntu:16.04

real	0m0.693s
user	0m0.032s
sys	0m0.017s

time docker-compose up -d
Creating network "test_default" with the default driver
Creating test_ubuntu_1

real	0m1.022s
user	0m0.271s
sys	0m0.065s
2

After a “Reset to factory defaults” of Docker for Mac Beta this problem still persists

3

Hi,

Just fyi, I tried to reproduce and was unable. I am running the same OS X version and same Docker for Mac version.

OS X: version 10.11.5 (build: 15F34)
Docker.app: version v1.11.1-beta13.1
Running diagnostic tests:
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x

time docker-compose up -d
Creating network "tmp_default" with the default driver
Creating tmp_ubuntu_1

real	0m0.796s
user	0m0.230s
sys	0m0.060s

There’s something more to this… ! Let me know if you have the same docker-compose version as I do:

$ docker-compose --version
docker-compose version 1.7.1, build 0a9ab35

$ which docker-compose
/usr/local/bin/docker-compose

$ env | grep -i dock
#nothing
4

That’s odd, here’s the docker-compose version I’m running, which looks the same

$ docker-compose version
docker-compose version 1.7.1, build 0a9ab35
docker-py version: 1.8.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

5

Could it be that this topic is related to this one: Docker-compose un-usable on Mac Beta ?

6

that does look related, I added localunixsocket.local to my /etc/hosts file and it cut down the time significantly

sh-3.2$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
sh-3.2$ time docker-compose ps
Name   Command   State   Ports
------------------------------

real	0m10.411s
user	0m0.244s
sys	0m0.078s
sh-3.2$
sh-3.2$
sh-3.2$
sh-3.2$
sh-3.2$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost localunixsocket.local
255.255.255.255	broadcasthost
::1             localhost
sh-3.2$ time docker-compose ps
Name   Command   State   Ports
------------------------------

real	0m0.320s
user	0m0.233s
sys	0m0.069s
sh-3.2$

That looks broken to me, to have to add a static localunixsocket.local entry to my /etc/hosts in order to have docker-compose work well. I do not have to do this in a Linux system, for instance.

7

Thanks for the answer: localunixsocket.local in the /etc/hosts file worked flawlessly for me.
I just noticed the problem today, after having changed my lan domain name to ‘local’ due to a change in modem.

I agree that it seems broken. As far as I can see it has to do with the fact that OSX uses the .local domain for it’s Bonjour-networking feature, which causes your Mac to first search the Bonjour network for the host and after the timeout it will go on with the docker socket.

At least with adding it to the hosts file, it works again.