Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?

5 min read

Choosing an Infrastructure as Code tool.

Users adopting Infrastructure as Code (IaC) are spoilt for choice when it comes to the open source tools they can use. In some shape or form, ChefAnsiblePuppetSaltStackTerraform, and more are all tools that can be used as part of a DevOps toolchain to implement provisioning of app environments and infrastructure.

If you are not familiar with the idea of IaC, see my blog, “Infrastructure as Code Accelerates Application Deployment,” the IBM Cloud Learn Hub page "What is Infrastructure as Code?" and the video below:

The choice of IaC tool matters. All of the referenced tools were developed with a specific purpose or intent in mind. Over the years, most have also evolved to address a wide set of use cases and can comfortably fulfill most IaC needs. To meet your requirements and fit with available in-house skills, one tool may be a better fit than another.

Choosing the most appropriate tool requires a way of understanding the many tasks involved in app and infrastructure provisioning. Tasks are generally divided into the domains of configuration management and configuration orchestration. I’m going to look at these two domains so we can then position the different tools.

Configuration management

Generally, Ansible, Puppet, SaltStack, and Chef are considered to be configuration management (CM) tools and were created to install and manage software on existing server instances (e.g., installation of packages, starting of services, installing scripts or config files on the instance). They do the heavy lifting of making one or many instances perform their roles without the user needing to specify the exact commands. No more manual configuration or ad-hoc scripts are needed.

Configuration orchestration

Tools like Terraform are considered to be orchestrators. They are designed to provision the server instances themselves, leaving the job of configuring those servers to other tools. Orchestration addresses the requirement to provision environments at a higher level than configuration management. The focus here is on coordinating configuration across complex environments and clusters.

Which is best?

Configuration management (CM) tools are great at the config nodes but less good at coordinating complex tasks. Orchestration tools tend to leave configuration to specialist tools. There is overlap in these roles and capabilities, and most tools can be used in both roles. In practice, some of the tools are going to be a better fit for certain types of tasks. The table following compares the most popular open-source tools.

Configuration management (CM) tools

Important differences

There are a number of important differences between these tools that are worth drawing out.

Chef and Ansible use a procedural style language where you write code that specifies, step-by-step, how to achieve the desired end state. The onus is on the user to determine the optimal deployment process. Terraform, SaltStack, and Puppet use a declarative style where you write code that specifies the desired end state. The IaC tool itself then determines how to achieve that state in the most efficient way possible. Procedural languages are more familiar to system admins who have backgrounds in scripting. Declarative tools are more familiar to users with a programming background.

Mutable or immutable? Traditional server environments are mutable, in that they are changed after they are installed. Administrators are always making tweaks or adding code. CM tools evolved to manage this complexity and bring order to the configuration and updating of tens to thousands of servers. An immutable infrastructure is one in which servers are never modified after they’re deployed. If something needs to be updated or changed, new servers are built afresh from a common template with the desired changes. This is the world of Terraform, where new servers replace the existing servers. This is also the philosophy of containers. With orchestration, immutability is easily applied to servers as they usually have built-in support for managing the lifecycle of a resource from creation to tearing down.

Terraform or configuration management?

My observation is that as cloud environments continue to grow in complexity, the need for orchestration increases. The growing requirement is for coordination of components and the management of the dependencies between the config of one service and another. Immutability avoids certain issues like configuration drift and problematic snowflake servers. Think “cattle” and not “pets.” However, to reap the benefits requires deployment automation, rapid server provisioning, and the handling of stateful data and ephemeral logs.

For me, this means one tool focused on infrastructure orchestration and another on applications. This brings together the benefits of a focused orchestration tool such as Terraform along with a wide choice of configuration management tools. This is one of the beauties of Terraform—it can easily work with your config management tool of choice to provide customized application delivery while maintaining the benefits of immutability.

Getting started with Terraform

With this introduction, I’ve introduced Terraform as IBM Cloud‘s choice for infrastructure orchestration along with an open choice of configuration management tools for application deployment.

To get started, have a look at Using Ansible to automate app deployment on Terraform-provided infrastructure and try out the tutorial Using Terraform and Ansible to deploy WordPress on IBM Cloud infrastructure.

For more of a background on Terraform, see the video "Terraform Explained":


Be the first to hear about news, product updates, and innovation from IBM Cloud