eval "$(docker-machine env default)"

Question

I have issues with launching docker with docker-compose.

When I run docker-compose -f dev.yml build I following error >

Building postgres
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`.

However if I run docker-machine ls machine is clearly up >

NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
default   -        virtualbox   Running   tcp://192.168.99.100:2376           v1.12.1

I fixed the error by running eval "$(docker-machine env default)" after which docker-compose -f dev.yml build completes successfully.

My question why did this work, what actually happens and how do I undo it?

Also is this a safe way to fix this? Right now this just my laptop, but these containers are supposed to hit company servers in near future.

I am not super fluent with bash but I been always told not to run eval and especially not to run eval with "

Solution 1

When you run docker commands, the CLI connects to the Docker daemon's API, and it's the API that actually does the work. You can manage remote Docker hosts from your local CLI by changing the API connection details, which Docker stores in environment variables on the client where the CLI runs.

With Docker Machine, your Docker engine is running in a VM, which is effectively a remote machine, so your local CLI needs to be configured to connect to it. Docker Machine knows the connection details for the engines it manages, so running docker-machine env default prints out the details for the default machine. The output is something like this:

 $ docker-machine env default
 export DOCKER_TLS_VERIFY="1"
 export DOCKER_HOST="tcp://172.16.62.130:2376"
 export DOCKER_CERT_PATH="/Users/elton/.docker/machine/machines/default"
 export DOCKER_MACHINE_NAME="default"

Using eval executes each of those export commands, instead of just writing them to the console, so it's a quick way of setting up your environment variables.

You can undo it and reset the local environment with docker-machine env --unset, which gives you the output for unsetting the environment (so the CLI will try to connect to the local Docker Engine).

Solution 2

This is indeed the expected way to use Docker on a machine that does not natively support Docker, e.g. on Windows or Mac OS X.

The Docker documentation includes this step in its description for using Docker Machine here: https://docs.docker.com/machine/get-started/

What this step does (I suggest you also try this yourself):

• Run docker-machine env default.
• Take the output of that command and execute it in the current shell session.

If you run docker-machine env default yourself, you will see that it simply suggests to set some environment variables, which allow the Docker commands to find the VM running the Docker daemon. Without these variables set, Docker simply does not know how to communicate with the Docker daemon.

In a server environment (Linux), you will not need Docker Machine, since the Linux kernel natively supports running containers. You only need Docker Machine (a small VM running a Linux kernel) on operating systems that don't natively support running containers.

Comments

[Kimmo Hintikka]

Ah, so do I get this right, without this my docker command would only really work if I had SSH session open to docker VM?

[Elton Stoneman]

Yes, if you SSH to the VM and run docker commands, they'll execute against the local Docker Engine. You can use the environment variables to work with a remote Docker Engine - Docker Machine just makes it easier, and takes care of securing the connection too.