Compute Infrastructure

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

Share this post:

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, Chef, Ansible, Puppet, SaltStackTerraform, 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 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.

Chef Puppet Ansible SaltStack Terraform
Cloud All All All All
Type Config Mgmt Config Mgmt Config Mgmt Config Mgmt Orchestration
Infrastructure Mutable Mutable Mutable Mutable Immutable
Language Procedural Declarative Procedural Declarative Declarative
Architecture Client/Server Client/Server Client only Client only Client only
Orchestration
Lifecycle (state) management No No No No Yes
VM provisioning Partial Partial Partial Partial Yes
Networking Partial Partial Partial Partial Yes
Storage Management Partial Partial Partial Partial Yes
Configuration
Packaging Yes Yes Yes Yes Partial 1
Templating Yes Yes Yes Yes Partial 1
Service provisioning Yes Yes Yes Yes Yes
1 Using CloudInit

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.

Adoption Leader - Watson Cloud Platform

More Compute Infrastructure stories
December 5, 2018

Techwave Helps Businesses Migrate Securely and Non-Disruptively to the Cloud

Cloud computing offers an agile, flexible, and scalable alternative to traditional on-premises infrastructure, but choosing to migrate to a public cloud service can be risky. At Techwave, we help clients migrate to IBM Cloud bare metal servers so they can capitalize on the benefits of cloud computing while retaining complete control of their IT infrastructure.

Continue reading

November 30, 2018

Fulcrum Empowers Law Firms to Seize Competitive Advantage

Fulcrum Global Technologies is harnessing the power of SAP software, hosted in the IBM Cloud, to free lawyers to focus on delivering superb legal services. With IBM Cloud bare metal servers, Fulcrum GT has a dedicated, single-tenant architecture that enables exceptional control of data. The solution unites technical excellence—scalability, reliability, and availability—with comprehensive, responsive services from IBM experts.

Continue reading

November 21, 2018

End-to-End Application Provisioning with Ansible and Terraform

In this blog post, I look at using Ansible and Terraform to perform end-to-end environment and app provisioning on IBM Cloud. It shows how with the adoption of IaC, the building of environments can be reduced from hours (if not days) down to minutes.

Continue reading