boot2docker vs docker-machine: who cares?

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
  fi
}

Now when I run our scripts locally, boot2docker ip is just an alias to docker-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!

 
52
Kudos
 
52
Kudos

Now read this

Chef integration testing with serverspec

Most resources discussing testing with Chef deal with unit testing. Unit testing your Chef recipes is a very good idea, but will only get you so far. You can have 100s of passing unit tests and your Chef converges will still fail.... Continue →