Over a million developers have joined DZone.

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

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

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!

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

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.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}