Ansible and Chef are two of the most popular configuration management tools in use today. While both tools can accomplish many of the same tasks, they each have different strengths, and they accomplish their tasks in markedly different ways. This article will explore the strengths and differences of these tools by the following parameters:
Playbooks vs Cookbooks
Source of Truth
Management of Host System Inventory
Before getting into the specifics of Ansible and Chef, it's worth briefly explaining what is meant by the phrase "configuration management." Very simply, configuration management is the maintaining of a certain state or states across your infrastructure. Suppose your infrastructure is divided into several different groups, each group containing anywhere from tens to hundreds to thousands of systems. All systems regardless of group, we may suppose, need to have one or two features in common -- perhaps having the same nameservers configured, for example; and members of each group need to be further configured such that all members of that group are identical to each other.
Perhaps all application servers need to have certain permissions set, and certain software installed, and load balancers all need to be configured in a specific way. To maintain the configuration of these systems -- that is to say, to manage their states -- is what is meant by configuration management. Configuration management tools like Chef and Ansible help eliminate so-called "snowflake" servers, or those servers that are unique and more or less impossible to replicate from a vanilla system, especially without documentation.
Besides making it drastically easier to maintain the state of your infrastructure, configuration management tools like Chef and Ansible provide two additional benefits that are worth mentioning:
The configuration files, called "cookbooks" with Chef and "playbooks" with Ansible, serve a kind of double duty: not only do they tell the tool what to do on a given system or systems, but given that they are text files that detail the step-by-step set of procedures to run on an infrastructure, they also serve as documentation. The problem with "snowflake" servers is that the documentary record of their configuration is unknown, and cookbooks/playbooks solve that explicitly.
The second major advantage is what is called "idempotency". Ansible provides a useful glossary of terms, and they define idempotency as the following: "An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions." Chef and Ansible both provide idempotency -- when the same play is run on a given host, these tools are able to detect whether the system is already at that state or not. If the system is not at that state, a configuration change is made to make it so; but if it is already at that state, no state change is made. This is a major advantage over simply using Bash scripts for configuration management, as running the same Bash script (or even the same Bash command) more than once does not guarantee that the system's configuration state remains the same the first time it was run.
Chef is the older of the two tools under consideration in this article, so we will begin with it.
Chef operates on a client-server model, where there is a Chef server that stores your cookbooks and on which is registered all of the servers, or nodes, that it is responsible for. This Chef server is often referred to as the "hub." The nodes themselves run the Chef client software, which is what actually performs the automation and configuration management on that system upon receiving instructions from the Chef server.
Chef clients regularly poll the Chef server for any changes to the cookbooks and, if changes are found, will perform the necessary state changes on their systems. A major benefit of this model is that it requires very little work for the Chef server, as all it needs to do is provide Chef clients with the relevant information when polled.
The Strength of Ruby
Chef cookbooks use the full power of Ruby, a common programming language, particularly among web developers. The strength of using a programming language is that, assuming you're comfortable with the language, you can perform complex configuration tasks that might be either unavailable or overly difficult when using YAML or JSON, such as Ansible, or scripting languages such as Bash. As a bit of a downside, however, Chef does require more overhead to learn, particularly with people who are more comfortable working with Python rather than Ruby.
Bottom line: Chef cookbooks are Ruby-based, thus, performing complex configuration tasks is easier than with YAML, JSON, and Bash.
The creators of Chef have developed an extensive set of cookbooks for interacting with OpenStack under several different architectural scenarios. Additionally, the OpenStack Foundation has also created example cookbooks that DevOps will find very useful for their environment.
Botton line: Chef and the OpenStack foundation provides extensive sets of cookbooks for OpenStack.
Ansible, like Chef, is also a general purpose, flexible automation tool that comes with numerous modules that allow it to interact with many of the services and applications that a Systems Administrator or DevOps Engineer could be expected to deal with.
It is quite unlike Chef in that it does not rely on a client-server model. Rather, Ansible is agentless, requiring nothing on target host systems other than ssh and Python. This makes it significantly easier to get started with Ansible than Chef, and of course, means that is one less service per system that you have to monitor and maintain.
Bottom line: getting started with Ansible is easy, requiring no agents on target host systems.
Playbooks vs. Cookbooks
Another major difference is its playbooks -- Ansible's version of cookbooks -- which aren't written using the full power of a programming language, like Ruby with Chef, but YAML, a human-readable serialization language that is used to transmit information that can be easily parsed by programs and programming languages. This makes it significantly easier to author new playbooks, as well as to read and understand those authored by someone else, but it does come with a restriction in that you aren't always able to perform complicated configuration tasks in ways that don't feel natural.
In fact, complicated tasks in Ansible can sometimes feel very "hackey," and you'll occasionally have to rely on Jinja2 for those purposes, a templating language for Python, which has syntax that is (on the whole) straightforward enough but can require a lot of documentation reading. On the other hand, sometimes Jinja2 templates can reduce the complexity of configuration tasks. Given that Ansible began development as recently as 2012, it's fair to expect that over time the occasional "hackey" workaround will give way to a more natural-feeling solution in later-developed releases of the software.
Bottom line: Ansible's Playbooks are much easier to create and understand, but limited in the complexity of configuration tasks you can perform with.
The Source of Truth
A crucial advantage of Ansible over Chef is how it handles the "source of truth," or the authoritative configuration of a given system or set of systems.
With Ansible, the source of truth is the playbook that you are deploying, and playbooks are perfect candidates for source control systems such as git. In other words, the source of truth for Ansible can be git itself. This gets to the heart of workflow management techniques.
With Chef, the Chef server itself is the source of truth. You have to upload updated cookbooks to one or more Chef servers, and there is not straightforward way of keeping them identical or even consistent in an easy way. Ansible, on the other hand, can just use the more sensible option of a source control system for its source of truth.
Bottom line: Ansible uses the more sensible option of a source control system for its source of truth, while with Chef, every Chef server itself is the source of truth.
Static and Dynamic Inventory
Another advantage of Ansible over Chef is how it manages its inventory of host systems. With Chef, hosts have to be individually registered on the Chef server. Ansible, however, offers several choices for its inventory source: a flat INI file, with hosts categorized under sections; a database; or another source that can be polled, as it were, for what current systems are on it. This flexibility allows Ansible to make use of inventories that are either static or dynamic.
Bottom line: Unlike Chef, Ansible can make use of dynamic and static inventories of host systems.
As with Chef, the OpenStack Foundation also provides an extensive set of example playbooks for DevOps that use Ansible. But perhaps what makes Ansible a better choice for OpenStack users is that Ansible provides native support for the platform with dozens of platform-specific modules that can be used to easily create your own playbooks to manage your unique infrastructure.
Bottom line: In addition to example playbooks, Ansible also provides modules to help you create playbooks for your unique OpenStack deployment.
Both Chef and Ansible provide a wealth of benefits for organizations looking for ways to handle their infrastructure using a configuration management model. While both tools have their own relative strengths and weaknesses, organizations will nevertheless benefit from lowering the cost of maintenance overhead that comes with these tools, in addition to being able to finally treat their infrastructure, and the states of the individual systems therein, as code.