Docker recently released
docker-machine to make managing multiple remote machines locally easier. Docker distributes binaries of
docker-machine for most major architectures ready-to-go, potentially making it easier to get started on Windows and Mac as well.
Set credentials in environmental variables so we don’t have to pass them on the command line each time:
DIGITALOCEAN_ACCESS_TOKEN = XXX
and create the docker-machine:
docker-machine create --driver digitalocean --digitalocean-size "1gb" server-name
server-name is any name you want to give your server and
DO_PAT is your access token (say, saved as an environmental variable). Here we launch a 1GB instance, the default is 512MB on digitalocean. Many other providers work just as well (including virtualbox). You need to set your terminal to use the active
docker-machine for all
docker commands, instead of the local
eval "$(docker-machine env server-name)"
sets three environmental variables that point your
docker commands to the new remote machine,
server-name. Wow. We can now launch any service of interest:
docker run -d -p 8787:8787 -e PASSWORD=something rocker/hadleyverse
and it will run on the server. Get the IP address of the active machine with
docker-machine ip, e.g. open the server in the browser (from a Ubuntu-based client)
xdg-open https://`docker-machine ip`:8787
When we’re finished with the instance, we can destroy the machine so we will no longer be billed, using the same syntax as we would for a container:
docker-machine rm -f server-name
If we have a locally installed docker instance, we may also want to unset the environmental variables set by machine:
unset DOCKER_TLS_VERIFY unset DOCKER_CERT_PATH unset DOCKER_HOST
You can see a list of active machines with
docker-machine ls and switch between machines with
docker-machine env as shown above.
Spawning a new machine adds a bit more overhead than launching a container on an existing local or remote server instance, but not much; and is easily scripted. Of course the latency is higher too: the start-up time for the DO instance takes two minutes, and pulling a sizable image onto DO machine takes another two minutes or so.
docker-machine actually prints the start-up time in seconds as it brings up the machine, in case you want to compare between services.
Docker compose is just fig, which is just a yaml config file / wrapper for (some of) the
docker run command-line options. As with
docker-machine, this simplicity is definitely a strength. Rather intuitively,
docker-compose, in that after setting the environmental variables as described above,
docker-compose up runs on the remote machine, just like
docker run does.
Docker swarm is rather analogous to CoreOS; it’s essential feature being a discovery service that allows the cluster to form. Swarm is mostly easily set up using docker-machine, though in my googling most tutorials fail to mention this. The official docker-machine docs are probably the best reference on this.
Docker swarm provides rather limited functionality so far. A nice docker blog post on swarm In particular, it doesn’t yet support two key features found in CoreOS scheduling: fault-tolerant scheduling; which can move a container to another host if a machine goes down; nor does it yet support Master election; so the swarm breaks if the master goes down.
It currently provides only relatively obvious scheduling – a bin-packing algorithm if you put constraints on resources a container can use, affinities to make sure
--volumes-from and other such containers end up on the same instance. Instances can be annotated with labels that can be used as constraints, such as
storage=ssd, though it’s not clear how to add these from docker-machine. As long as swarm does not support fault-tolerant scheduling and master election though, these features are not as essential. Dynamically moving a container when a machine has failed means that no human is around to consider what resources the swarm has and where to schedule the container. But for merely adding a new container to an existing swarm, it’s not particularly hard for a human to look at the existing resources and just pick manually where to stick the container without the help of swarm’s algorithms.
Swarm doesn’t really understand docker-compose yet either, in that compose is essentially written as a single-host tool.