When looking at configuration management in our daily DevOps activities, we look at the top tools available to us. In this 2021 comparison of configuration management tools, we will be focusing on the latest trends and information regarding Ansible vs Puppet vs Chef. Some see Terraform as a player in this domain as well, rightly so in our opinion (we also listed it as one of the best DevOps tools to use in 2021), however, since this blog post is already quite crowded, we decided to leave Terraform for another blog.
Adding Ansible into the mix, rather than just comparing Puppet vs Chef, as was traditionally done in the past, is relevant when looking at predictions for 2021 tools showing the support for Infrastructure as Code (IaC) in Ansible is gaining popularity.
Ansible vs Puppet vs Chef… What can I say? All three tools are similar in function. Today, we will look into the details of each in a way that helps educate on how and when it is being used in 2021. When it comes down to making the decision on what’s best for your team, much comes from your own experience in DevOps. Other factors involve keeping up on the latest and greatest tools for configuration management. It’s important to use continued education time to stay on top of the best that’s available.
Market share information that dates back to 2019 showed that Ansible has enjoyed almost 50% of the market share while both Chef and Puppet see about 40% usage, each. Now with the need to include container orchestration, it is important to understand how tools like these take things a step further to provide a more complete way to organize and work with resources.
Python Helps Ansible Slide to the Top
In just a small amount of time, Ansible’s usage has grown to the point that it has surpassed other products in the category. One of the reasons for this is the familiarity of Python. Python is used extensively in DevOps to help with automation tasks. Now it is also used to provide the services and infrastructure needed for Ansible to perform at its best.
Looking at how Ansible vs Puppet vs Chef compare to each other, Ansible is an agentless system that doesn’t require special security infrastructure. Meaning Ansible can be implemented with a very low amount of touch required. It does so using SSH as the underlying security. Ansible handles a wide range of automation tasks that include cloud provisioning, the configuration of those resources, and even the release and orchestration of the software deployed to it.
Those familiar with YAML will appreciate the lower learning curve necessary for the Ansible “playbooks” that are used to hold instructions for automation jobs. Using this in conjunction with proper cloud orchestration can provide a powerful combination to maintain proper configuration management across a large number of servers. Managing inventory with playbooks is a great step towards accomplishing IaC. This methodology helps with continuous delivery by ensuring the infrastructure and associated configuration are neatly checked in alongside the rest of the code.
Puppet Pulls the Strings for You
As a configuration manager, Puppet employs a language for its module files that are similar to Ruby. Time is spent focusing on the configuration aspect of an environment using a declarative DSL to set the configuration parameters for maintaining a specified state. This is quite a bit more in-depth than the playbooks used in Ansible.
Using a primary server/agent system allows for agents to poll the primary server to verify and update configurations. A major difference when looking at Ansible vs Puppet vs Chef is the way Puppet utilizes this “Puppet primary server” system to manage nodes using this method. The primary server is designated to be the “system of record” for the various configurations in your environment. It also helps control the flow of necessary files from file servers and provides metrics related to configuration.
The discovery portion of Puppet uses Facter to gather information about the systems meant for management. The communication back to the primary server allows the system to compile information based on its findings so it can compare it to the Puppet manifests. Instructions to get the node into parity are then sent back to the agent where the agent daemon completes the operations.
Chef Cooks up Automated Convenience
Since starting with Chef in 2008, the organization has kept in touch with the needs of IT and development. Remember what we spoke about moving to Infrastructure as Code? Like Ansible and Puppet, Chef also maintains strong direction to support IaC. Similar to Puppet, the Chef system depends on files that include instructions for the desired state. In Chef, these files are called Cookbooks.
Like cooking up a meal, you have to use a recipe. The combination of recipes, configuration details, tools, and other custom resources is what constitutes a full cookbook. These cookbooks have become increasingly complex over time. Chef provides many tools to help with complexity so it can be used to your advantage to gain a higher level of automation.
Let’s look at their lineup:
- Chef Infra – This is the main product that handles the heavy lifting. It is used in conjunction with other tools like Chef Server and Client to orchestrate the desired configuration.
- Chef Workstation – The workstation package has the tools needed to create the cookbooks and admin the system. Additionally, Chef Workstation provides a means to try out your recipes in a “test kitchen.”
- Chef Habitat – Habitat is more centered towards the state of the application itself vs the infrastructure. It is meant to enable the deployment of your Chef Habitat app on virtually any cloud or on-premise.
- Chef InSpec – To inspect a bit further inside, Chef InSpec allows for compliance verification by checking for items specified. For example, checking for a specific option for a database to ensure it aligns with data security policies.
Clearly, Chef has taken an approach that includes separating many aspects to accomplish different goals. For this reason, Chef is a good choice for those who can take the time to use all the tools to their advantage. When looking at Ansible vs Puppet vs Chef, all of them have differences in features that fit in a specific environment. The one to choose is highly dependent on current tool knowledge, its learning curve, but also its acceptability for use in your team’s workflow.
A Side-by-Side Comparison of Ansible vs Puppet vs Chef
| Ansible | Puppet | Chef | |
| Released | 2012 | 2005 | 2009 |
| Ease-of-Use | High | Moderate | Moderate |
| Feature-set | Low | High | Ondary (Through various tools.) |
| Supports Enterprise | Small | Large | Large |
| Failure Tolerance | Via Secondary Node | Uses Additional Master | Relies on Backup Server |
| Coding Style | Procedural | DSL | Procedural |
| Maintenance Difficulty | Low | High | High |
| Documentation | Low Documentation | Highly Documented | Highly Documented |
| App Deployment | Yes | Yes but Difficult | No |
With most implementations, it is critical to do a full comparison by using various POCs. A planning session to determine the level of administration needed for your stack is important to determine which product to choose. While some have the ability to complete the task, getting to that point may be more complicated than necessary.
To Summarize…
When you compare Ansible vs. Puppet vs. Chef, you will surely find the one that fits your team. Many Administrators are very comfortable with Ansible and Puppet while Chef may appeal more to the developers in the group. There’s nothing saying that a combination of the tools couldn’t be used in certain situations. For example, while you may enjoy the ability and tooling used for Chef, Ansible may be used to ensure the application side of things is handled.
Regardless of which product you choose, moving to a configuration management tool is sure to save a lot of time for the team. Anything that can provide an automated, guided process, is going to further the group towards the goal of continuous delivery using dynamically provisioned and configured environments.
