Chef vs Puppet vs Ansible: Comparing Configuration Management Tools

Traditionally, developers would configure an environment to manage code, but this led to human errors and misconfigurations that could leave an application server vulnerable to cyber-attacks or unforeseen bugs. DevOps teams work with tools that automate the process to compensate for mistakes and improve management of deployed application configurations. Three popular tools automate deployments: Chef, Puppet, and Ansible. We’ll discuss all three to help you decide which one is best for your organization.

Why automate infrastructure configurations?

DevOps is a relatively new concept where operations people and developers form one team in charge of streamlining application deployment, mainly with automation. Good automation can turn considerable delays in development times to only a few minutes. Every organization automates uniquely, and deployment times might differ depending on the application, but overall, DevOps streamlines the entire Software Development Lifecycle (SDLC).

Configuration management tools are part of the process, and they are used to program automation across the infrastructure. These tools are standard in any DevOps team, so you’ll find at least one of them installed in an environment. As you look for a tool, keep three factors in mind:

• How it integrates into your infrastructure and if it works with current applications and servers.
• How well the tool can configure targeted servers and the reporting features available.
• The push or pull model when making changes to targeted infrastructure.

Chef

For DevOps people who are open to learning a new language, Chef has a language that builds “cookbooks” with executable instructions. The language is closely related to Ruby, so developers familiar with the language will have an easier time acclimating to the tool. While this means there is a learning curve for people who will work with it, it’s also the most popular for its flexibility and ability to work with any target server.

Terminology in Chef plays off kitchen elements. The files that contain configurations are called “recipes.”  A collection of attributes, declarations, files, and dependencies is called a “cookbook.” The command-line tool used to communicate with a Chef server’s repository is called a “knife.” DevOps customizes declarations and stores them on Chef servers, where they can then deploy configurations to nodes.

Chef incorporates three factors into its automation model:

• Workstations are where coders or operations people create their recipes.
• Recipes and cookbooks are stored on Chef servers. When a new cookbook is created, it’s stored on the server as the most recent version, and any changes are pulled down to the nodes.
• Nodes are target machines where we deploy configurations.
  

Chef Pros:

• Repeatable solutions for full automation.
• Test kitchen environment for testing.
• Chef works with most cloud providers such as Google Cloud and Amazon Web Services.
• A marketplace for downloading pre-created cookbooks.
  

Chef Cons:

• Proprietary language requires some training, especially if users are unfamiliar with Ruby.
• Cookbooks that depend on each other can create difficulties ensuring that any updates do not affect other cookbooks.
  

Puppet

In a large heterogeneous environment, Puppet is often the automation tool of choice. It not only supports the cloud, Linux and Windows, but it also supports other infrastructure such as Cisco hardware, mainframes, and macOS. Puppet also has a declarative language similar to Ruby, so its scripts are different from Bash or PowerShell.

Puppet uses a client-server approach. Developers create manifests and upload them to the server. Agents running on targeted infrastructure collect data about themselves and then send the information to the Puppetmaster. The Puppetmaster compares the current node configurations with manifests and sends data back to the agent to configure the local device if we need to make changes.

Puppet Pros:

• Puppet works with a variety of platform operating systems and infrastructure.
• The language is abstracted directives that don’t depend on the operating system.
• Puppet is highly scalable, as servers can work with numerous targeted machines.
• Transactions only happen when necessary, freeing resources.
• Open-source with an active community.
  

Puppet Cons:

• The declarative language is similar to Ruby, so it requires training.
• No reporting system for reviewing errors.
• It’s often considered more complex than Chef and Ansible, so only large enterprises deploy it.

Ansible

One noticeable difference between Ansible and the other two solutions is that it does not require agents running on target systems. Depending on the environment, it uses SSH and PowerShell to connect to remote machines - a blessing or a curse. It does, however, make it easier to deploy and cheaper since no main servers are necessary.

Ansible has more options for programming its modules. It works with Python, PowerShell, and even binaries. It also has a Python API for controlling nodes. It works as a “push” controller that sends changes to infrastructure instead of the other two that collect data and send their status back to the main server.

Ansible Pros:

• No agent is running on target machines, so it’s easier to configure.
• YAML-based playbooks, so the JSON-like language is easier to learn.
• Beneficial for smaller organizations that need a solution that requires fewer resources.
  

Ansible Cons:

• No tracking of the target state, so it simply executes instructions without getting feedback from an agent.
• Windows support with PowerShell requires more difficulties than simple SSH in Linux, making working within a Windows environment harder than the other two solutions.
• Built for smaller organizations but can’t handle scale.
  

Which one is right for your organization?

If you need scalability for a large enterprise, Ansible and Chef are likely the better solutions. You’ll need the infrastructure and resources to run both options, so prepare to provision and deploy additional resources to run both these solutions. Your DevOps team will also need some time to train and understand the programming language.

For smaller organizations, Ansible is usually the better option. It’s easy to deploy and doesn’t require as much overhead. You’ll need to configure targeted servers to support PowerShell or SSH connections, but no agents are required to run on configurable devices.