Cooking Up Some DevOps With Chef

Magnus Hedemark

Before I started working for Bronto, I loved coming to the meetup groups hosted in Bronto’s Thunderdome. Perhaps the one that resonated with me the most was Triangle DevOps. So when I was asked to help behind the scenes with the group, it was a no-brainer. We’ve been really fortunate to draw big, engaged crowds and some of the best speakers in the United States. Now that I’m a Bronto Engineer, it’s really great to add host to the responsibilities I’ve taken on with this group.

One of our more noteworthy speakers came through late last month, and we set up an out-of-band special meetup just for him. I first met Nathen Harvey, the community director for Chef,  almost a year ago at the Surge Conference. Did he greet me with a handshake? No! Being the really warm guy that he is, he introduced himself with a hug. I want to endorse him on LinkedIn for hugging. One might call him the HugOps Rock Star of our time! If you’re ever lucky enough to meet Nathen, don’t shake his hand; just hug him and tell him I sent you.


Fast forward to July 2015. Nathen arrived at Bronto to get set up and, true to form, he deployed a world-class hug on arrival. Nathen was in great spirits and really ready to talk Chef with our group.

We usually kick off our meetups, though, with introductions. Todd Lewis from the All Things Open Conference came by to tell us that ATO would indeed be back in Raleigh again this October, and they were able to keep the two-day registration costs at $149. There was a good deal of excitement in the crowd that this home-grown celebration of Open Source is returning to the area.

Nathen then stepped up to the podium and, right away, we knew this was going to be different. The first slide was hanging around on the screen for a while and it listed his Twitter handle. His cell phone was left up on the podium, just under the podium mic. It dinged a couple of times. After a few rounds of this and some uncomfortable laughter from around the room, Nathen explained that he likes to do this so he can hear the Twitter notifications coming in from around the room while he’s talking. Immediately, some people tweeted to him to test it out, myself included, resulting in a bit more raucous laughter. The talk continued with Twitter notification sounds all night without detracting from the experience. This was a pretty cool touch I hadn’t seen at a talk before.

Nathen talked about the value of meetups: why it’s important to go to them, get involved, and not think of them as work. Watching the guy talking to a big crowd, it looked like he was hugging each one of them without actually hugging them. This guy is like the DevOps Whisperer.

He then talked about an underlying DevOps value that a lot of us have heard before: “Infrastructure as Code.”

“Code. Code.” Nathen repeated this word a couple of times for impact before explaining that if we’re thinking of our infrastructure like a software project, there are some best practices we ought to be following. The talk picked up an interactive flavor from this early point, with ideas coming in from around the room about what we should be doing if our infrastructure is a software project.

“We need a version control system!” And of course, there are jokes about .bak files.

“You can use any version control system you like, as long as it starts with G-I-T.”

“You’ve got to test your code.”

This went on for a bit before Nathen pulled out some more humor that actually turned out to be a really poignant observation about DevOps.

“DevOps is basically when Aerosmith met Run DMC in the 1980’s.”


Nathen’s point: Aerosmith and Run DMC were from really different worlds. They decided to come together to make the audience (their customers) happy. Aerosmith didn’t try to become rappers. Run DMC didn’t try to become rock artists. They each continued to do the things they could well. It probably would have ended badly for everyone if they tried to change their roles.

This left some questions hanging in the air about “DevOps Engineers.” Should we expect Software Engineers to take on an Operations aspect to their roles, or SysAdmins to become software developers? But before things could get too heavy, this side topic ended with another observation.

“Public Enemy is my favorite DevOps band of them all. Yeah. Flava Flav is really into monitoring. I mean, just look at that clock he wears!”

After the laughter subsided, we got serious again. We talked about unit testing and why it’s so important to write more unit tests and get really good at making them effective. And if we’re going to test our code, what does that look like in our Chef software project? How do we know that the Chef client converged successfully? Did it put the node into the desired state? Are resources properly defined? Does the code follow our style guide?

Introducing the ChefDK

The Chef Development Kit makes all of this easier. It’s kind of a new thing for a lot of us, which is why Chef has sent out the DevOps Whisperer to make it a lot more approachable and fun.

Nathen acknowledged right up front that managing dependencies in Ruby is a pain in the ass, but then pointed out that this is also true of Python and other languages. Part of the point of ChefDK is to make this a lot less painful.

He demonstrated by dropping out of the presentation and going into a live coding session. Let’s write a cookbook! He went through some of the basic Chef tools, how to use them to create a recipe, a cookbook. He upleveled the trolling fun a bit by using the atom editor, so vi and emacs were equally humiliated. Test Kitchen was added to the mix. “OK, should we do this on CentOS or Ubuntu?”

The audience engaged in a bit of fun debate and while it looked like Ubuntu might claim the death match, CentOS won. But only barely.

There was something really cool about watching Nathen writing live cookbooks without copy & paste and without a whole lot of predetermination about what he was going to do. This was a conversation with the room, one he clearly enjoyed having (as did the audience). This took some real courage, as live coding often goes badly, as a rule. It’s kind of like getting your lover’s name on a tattoo, which invariably condemns that relationship to go down in flames. Nathen went all honey badger on that taboo. Honey badger don’t care.

Lots of tools were demonstrated. Serverspec, knife, berkshelf, vagrant, testkitchen, rspec … all of these played key roles in building a successful well-tested Chef-based software project. And this was all very collaborative. Nathen’s talk felt more like he was joining a very large software development team and challenging them: “Hey, let’s build something really cool together.”

One of the most interesting moments in the night came when Nathen asked for a code review. I heard a familiar voice behind me point out a bug and offer some advice on how to fix it. It was Michael DeHaan, creator of Ansible (competitor to Chef). This was the Open Source community at its best, and very different from the proprietary software world. The founder of a rival open source project was in the room, offering positive contributions to this Chef cookbook, and helping make sure Nathen looked good when he ran his code. This is one of the aspects of the Open Source community that I really love. I will point out again and again that you can’t really have DevOps without Open Source.

Finally we used foodcritic to review the coding style.

Did our code run?

Not quite. At least, not on the first pass. There was a gem dependency that went unnoticed. This took a minute to resolve, and we all had a lot of fun and laughs making the last minor changes to get it all working as expected. It didn’t take much at all, but the unforeseen bits are part of what make live demos so fun and unpredictable.