boot2docker vs. docker-machine: Who Cares?

DZone 's Guide to

boot2docker vs. docker-machine: Who Cares?

When some teammates are using boot2docker and others are using docker-machine, what can you do to make everything run smoothly?

· DevOps Zone ·
Free Resource

We’re using Docker a lot now at Conjur. Jenkins integration tests - Docker, dev environments - Docker, shipping a virtual appliance - Docker. You get the picture. A lot of our scripts have lines like this in them:

chef-runner --ssh Port=2200 -H root@$(boot2docker ip) mycookbook

I develop on OSX, so I have been using boot2docker for a while now. But I really liked the feature set of docker-machine when it was announced. It allows deployments to more than just VirtualBox and folds together nicely with the other Docker tools. For the last couple months, I have used docker-machine exclusively.

But now we have a problem.

The dev team is split: some of us are using boot2docker and some docker-machine. Our automation code assumes a boot2docker VM is up and running. When this sort of issue comes up, we have three choices.

  1. Write code. Update our automation code to be smarter and switch commands depending on the tool available.
  2. Standardize. An authority makes the decision. Or we have a team huddle and stress everyone out by arguing for the ‘one true way’.
  3. Defer. Don’t change any code. Let the team find a solution on an per-individual basis.

I chose #3 for this situation. I added this function to my ~/.zshrc:

boot2docker() {
  if [ "$1" = "ip" ]; then
    >&2 echo "using docker-machine"
    docker-machine ip boot2docker-vm

Now when I run our scripts locally, boot2docker ip is just an alias todocker-machine. I print 'using docker-machine’ to stderr so I don’t forget that this is an alias. The automation code only reads stdout.

No code changes or meeting required, I just share with the team how I’ve solved the issue.

How groups make decisions is fascinating to me. Several engineering teams into my career, I observe that we naturally evaluate our options in this order:

1. Write code. 2. Standardize. 3. Defer.

But I have observed that often the simplest, most elegant solutions have come from this order:

1. Defer. 2. Standardize. 3. Write code.

I am not against standardization or writing code. Some degree of architectural and tooling standardization is necessary for your team to function. And I’d be out of a job if writing code wasn’t often necessary. Deferring a decision does not mean defeat, though. Velocity doesn’t mean anything if you’re writing code that doesn’t matter. I’ll explore this more in a later post. Thanks for reading!

devops, docker

Published at DZone with permission of Dustin Collins , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}