Puppet, Chef, and Ansible: Open Source Configuration Management Tools

melissa • November 17, 2014 • 1 Comment

A key component of our policy driven data center of the future is configuration management.  With terms like cloud, orchestration, and DevOps being thrown around all over the place, how do we handle this?  How do we make sure that we’re doing things in a consistent way?  There are as many options as there are questions sometimes, and one of the things that can scare people away from diving into these tools is the amount of variety. Not to worry though, because we can focus on some of the core players in the configuration management space.

Let’s take a look at three common open source solutions that you are going to want to get to know.

Puppet, Not the Sock Kind
Puppet is one such tool for the job, and comes in a few different flavors, there’s Puppet Enterprise, and open source Puppet.  Both work under the same premise, tell Puppet what you want your end state to be, not how to get there.  This approach is becoming more common as we move towards our policy based future, such as in the case of Cisco’s OpFlex.  Puppet requires an agent on each of your nodes, and Puppet uses these agents to evaluate the sate of the node during “Puppet Runs”.  In the DevOps spirit, there is Puppet Forge, where you can download Puppet modules for your infrastructure, or learn to create new ones.  There are also Puppet modules available for OpenStack.

Chef, Not in the Kitchen
Chef is another platform for configuration management.  Also requiring an agent, Chef uses “recipes”, or basically reusable definitions to power infrastructures.  The Chef “cookbook”, full of “recipes” is a lot like an runbook an organization may have.  This means, in addition to configuration management, Chef can be well suited for automation and orchestration in an environment.  Chef, like Puppet also comes in multiple flavors based on the size of the infrastructure you wish to deploy it on.

Ansible, No Longer Fiction
Ansible also works on the premise of automating runbooks, or in this case, what they call playbooks, with a major difference from Puppet and Chef, there is no agent required, and it doesn’t require the use of root logins.  As Ansible says, SSH keys your friends, and while it is one of the main ways for Ansible to communicate, there are more options available.  Ansible is also known compatibility in the Windows domain, using powershell remoting rather than SSH, still not requiring an agent.

There’s a theme between these three tools, and that is policy as code.  While some orchestration and automation tools use drag and drop type interfaces, sometimes leveraging snippets of code underneath, these tools are taking a bit of a different approach.  We have many modules which are readily available in each of them, but these modules leverage Ruby-esque code snippets under the covers to get the job done.

There’s another theme here, the theme of a runbook.  Without knowing what configurations we want to manage, or what processes we need to automate or tie together, it is difficult to introduce a tool like Puppet, Chef, or Ansible into our environments.

Orchestration Inception
With these three products on our radar, the next thing we can do is use these tools as the underlying driver for a higher level orchestration platform.  Take OpenStack Heat for example.  Using Heat as an orchestration tool, you can trigger additional build processes that may be run using another tool.  A common workflow would be to use Heat to build out a virtual application infrastructure based on some pre-build instances, and when the instances launch, they use our configuration management tools.

It seems a little confusing sometimes, but using Heat to create an instance that then runs Puppet to configure itself, and runs Chef to deploy the applications is a great use-case.
AND, not OR
We aren’t in the “do you use product A, or product B?” age any more.  Most data centers are made up of a variety of tools and products that make the day-to-day operations work.  It used to be a matter of putting all of the work into one product and making it work, regardless of the efficiency and effectiveness.  This created a lot of shops that had a tool that was 60% good at everything, but not especially good at one thing. This doesn’t need to happen any more.

IMG_0351(It may take a combination of tools to get us here.  This was taken by the High Altitude Balloon I launched with Dan Grinkevich)

Using tools like Chef AND Puppet, or Puppet AND Ansible, or any combination of a multitude of tools, you can create a better overall management strategy.  Using two or three tools that are each 90-100% effective in the platforms they manage is really the better option, right?  This is why we have abandoned the concept of picking the one tool and making it work, because that one tool that does everything just doesn’t seem to exist.

The common theme we have here is we have to know what the use case is and apply the best possible tool or tools into the scenario. One way or another, configuration management is something that the modern sysadmin needs to get involved in.  If you hate doing things over an over again like I do, you’ll learn to like these tools for the benefits they give you, time to get back to the good part of what you do.


Song of the Day – Bastille – The Driver

Categories Open Source

1 Comment