By: Thu Nguyen
Read Time: 7 min
Configuration management is an essential process for DevOps teams. It allows engineers to manage dozens, hundreds, or even thousands of machines in a consistent and automated way. While there are many configuration management tools available, three of the most popular are Chef, Puppet, and Ansible. In this post, we’ll explain how these configuration management tools work and the unique benefits that they offer.
Before looking at the differences between these configuration management tools, let’s explain their similarities. These configuration management tools enable a process known as infrastructure as code (IaC), where the state of an IT environment is represented as code. DevOps engineers can declare the final state of the environment using a programming or configuration language, and the tool automates the actions necessary to match the environment to this state. This can include actions from installing software to adding users to partitioning storage devices.
Each tool differs in a number of ways including:
We’ll look at each of these factors in more detail so you have a better understanding of each configuration management tools’ requirements and behaviors.
Recently, the growth of container runtimes and orchestrators like Docker and Kubernetes have shifted configuration management from the host to the application. Developers define their target configuration in a Dockerfile, and Docker and Kubernetes handle the process of provisioning the necessary resources. This doesn’t make them mutually exclusive, however. In fact, Chef, Puppet, and Ansible all have definitions available for deploying and managing Kubernetes clusters.
Whether you choose a configuration management tools, a container orchestrator, or both, depends on your particular application and infrastructure.
Chef is a popular configuration management tool initially released in 2009. It uses an imperative model to define infrastructure, in which engineers define the individual steps needed to manage each individual machine. Chef’s definition files are called recipes and can be combined with files, attributes, libraries, and other recipes to create cookbooks. Although recipes use a domain-specific language unique to Chef, they support scripts written in plain Ruby.
Each Chef deployment consists of three main components:
Chef is unique in that it also supports an declarative to IaC. This lets engineers define the desired state and leave the implementation details to Chef. Declarative models offer less control, but provide a much easier and less verbose tool for engineers.
Chef supports a large number of operating systems and platforms. Pricing for a hosted Chef instance starts at $120/month for 20 nodes.
First released in 2005, Puppet is the oldest of the automation tools in this list. Like Chef, Ansible uses declarative files (called modules) to define the final state of your systems. A Puppet deployment consists of client machines (Agents) that periodically poll controllers (Masters) for new modules and updates to existing modules.
Puppet uses a unique configuration language inspired by the Nagios configuration file format. It supports common constructs such as variables, condition statements, arrays, classes, and functions, as well as functions written in Ruby. Modules can also contain manifests, which are individual classes or tasks. Modules and manifests are reusable and shareable, allowing you to piece together a deployment from existing components.
Despite only being released in 2012, Ansible is the most popular of the three tools and arguably the most favored among engineers. Unlike the other tools, Ansible doesn’t require agents to run on target machines. Instead, it uses existing remote administration solutions such as SSH and PowerShell to connect to nodes and run commands. This makes deploying Ansible much easier compared to Chef or Puppet, which require you to deploy and maintain both a controlling service and agents.
Ansible configurations (playbooks) are formatted using YAML and follow an imperative model. Like Puppet modules, playbooks support constructs such as variables, condition statements, loops, and error handling. You can define new tasks by creating modules, which execute Python, Powershell, and even binary applications on a node. Ansible also provides a Python API for controlling nodes, responding to events, creating new plugins, and more.
Because Ansible uses an agentless model, changes must be pushed from Ansible to each target machine. While this means target machines won’t be able to periodically check for changes, it allows engineers to deploy configuration changes instantaneously. Ansible tracks agents using a simple configuration file, allowing engineers to manage an infrastructure from any device with Ansible installed.
Ansible runs on almost any machine capable of running Python 2 or higher except for Windows machines. It can manage Linux, BSD, and Windows machines.
Each of these three DevOps tools takes a slightly different approach to automation. While there is no one-size-fits-all tool, knowing the benefits that each tool offers can help you decide which is best suited for your infrastructure.
Isn’t all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system…...
First published on www.ibm.com on October 7, 2019. Written by: Norman Hsieh, VP of Business Development, LogDNA You know what they say: you can’t fix what you can’t...
First published as a case study on www.ibm.com on October 3, 2019. What is Log Analysis? IBM Cloud™ Log Analysis with LogDNA enables you to quickly find...