DEV Community

Martez Reed for puppet

Posted on • Originally published at Medium on

Terraform is not Ansible or Puppet

Terraform is not Ansible or Puppet

There’s a common misconception that Terraform does the exact same thing as Ansible, Puppet or other tools that fall into the configuration management category. The focus of this post is on detailing why this is a misconception even though some believe it to be fact.

Before we get started HashiCorp pretty much settles the debate for us. The following is pulled directly from the HashiCorp Terraform documentation.

Terraform is not a configuration management tool, and it allows existing tooling to focus on their strengths: bootstrapping and initializing resources. — https://www.terraform.io/intro/vs/chef-puppet.html

This statement explains some of the ethos that has been followed by the Terraform team. Even with that, the delineation between the two is not readily apparent as there are things Terraform can do that Ansible or Puppet does and vice versa.

So what is Terraform good at?

Terraform is great with APIs

Terraform is built to interface with REST APIs. Terraform creates resources by calling a REST API endpoint to perform CRUD (create, read, update, delete) operations.

Cloud Infrastructure

Terraform is an excellent tool for codifying cloud infrastructure such as AWS S3 buckets or Azure AKS clusters. Terraform also has providers for VMware vSphere and OpenStack to codify private cloud infrastructure. All of these provide a REST API for creating, reading, updating and deleting resources so Terraform is great at this.

But can’t Ansible and Puppet create cloud resources?

Yes, Ansible and Puppet can also be used to create cloud resources. Which tool you use to provision cloud resources comes down to preference. Typically you would evaluate which tool supports all the resources you anticipate creating as well as how you like creating the resources with that tool.

Application Configuration

This is where things can get really confusing. Most modern applications expose a REST API for configuring the application. Since we know that Terraform interacts with REST APIs then it can be used to configure applications.

But can’t Ansible and Puppet also configure applications?

Yes, Ansible and Puppet are also capable of configuring applications. Where things diverge is that Ansible and Puppet are ideally suited for installing the applications on the operating system unlike Terraform. This is also why it would make sense to use Ansible or Puppet to install and configure the application otherwise there could be a ping ponging between the tools in a provisioning pipeline ( Terraform [Infrastructure] -> Puppet [Application Install] -> Terraform [Application Configuration]). Technically Terraform can be used to install software or configure system settings but based upon the HashiCorp statement above, that’s not the focus for Terraform.

Terraform is not great at installing software or configuring operating system level settings.

But that’s not true, public cloud readily supports configuration at boot time by passing a script

It is true that Terraform can pass scripts or commands that are executed on a virtual machine or cloud instance at boot time. This model works well for smaller scripts but can become unwieldy once the script grows to some substantial size. Additionally, with some cloud init or userdata integrations there is no direct feedback regarding the status of the script. This means that you need those execution logs to be shipped to a centralized logger or connect directly to the machine to review them.

But terraform has remote exec resources so I can just use one of those instead?

Using a remote exec does provide that realtime execution feedback however, HashiCorp recommends against using remote exec resources when possible.

Provisioners should only be used as a last resort. For most common situations there are better alternatives. — https://www.terraform.io/docs/provisioners/remote-exec.html

This isn’t to say that they aren’t used quite frequently with great success but that it’s not an ideal solution.

This isn’t to say that Terraform can’t be used to install applications or configure operating system level settings but that that’s not what it is great at. Configuration management tools are great at doing those things and I’ll walk through some of the benefits.

Benefits of configuration management

Configuration management tools have a number of benefits in comparison to bash or powershell scripts but we’ll cover three that should be familiar to those that use Terraform.

Configuration As Code

Terraform utilizes HCL (HashiCorp Configuration Language) to define resources. Defining configuration as code is a paradigm that many have adopted and love, which is why they use Terraform. Remote execs and userdata integrations break from this model and relies on inline commands or scripts. Configuration management tools like Ansible and Puppet enable this “as code” paradigm to be used for system configuration as well.

State management (Idempotency)

Terraform utilizes the construct of state to provide idempotency. This means that when you run a terraform plan and the Terraform code matches the current state of the resource you anticipate that Terraform won’t change anything.

Idempotency is the ability for automation to be run multiple times and only change what needs to be changed. This is how Terraform works, it verifies the current state of the resource and makes changes only when when the state doesn’t match the configuration. Terraform remote execs and userdata integration address idempotency by running the automation only during provisioning. This is a core aspect of configuration management tools and allows the automation to be run multiple times.

State Correction (Desired State)

One of the reasons people love declarative tools is the ability to change a configuration by simply changing the value of a parameter. When you change a setting in Terraform and run terraform plan you anticipate Terraform to show that there’s a change to be made. Once you run a terraform apply you expect the setting to be changed to align with the newly declared setting. The advantage of this is that you don’t have to concern yourself with all of the details of how to actually update a resource.

Configuration management tools can update resources in a similar manner along with being used to correct configuration drift. Configuration drift is typically caused by manual changes or another tool making changes. This is capability helps ensure that systems stay in alignment with the declared configuration and is especially useful for security and regulatory compliance.

Conclusion

Ultimately, Terraform “can” do a lot of things Ansible or Puppet does but many of the reasons for using Terraform are the same reasons to use a configuration management tool in conjunction with Terraform.

Top comments (4)

Collapse
 
melezhik profile image
Alexey Melezhik

As Code (Declarative)

Terraform utilizes HCL (HashiCorp Configuration Language) to define resources. > Defining configuration as code is a paradigm that many have adopted and love

I think you're mixing two concepts here:

  1. configuration as a code

  2. declarative style of configuration management, where a disired state is the only thing which is defined and means to achieve this state are not VS an imperative style configuration management where one defines the process of achieving a desired state. Both styles have pros and cons.

Collapse
 
martezr profile image
Martez Reed

Thanks for mentioning, they are definitely two separate concepts that are often conflated. I'll get the article updated as that was one item that I considered more than once before publishing.

Collapse
 
melezhik profile image
Alexey Melezhik

Yeah, welcome!

Collapse
 
ragnarkon profile image
Bryan Woolsey • Edited

Poor Chef... got left out.

Great article. There is a common misconception that if you move to public cloud you can rid yourself of the more traditional configuration management tools. Usually not the case unless you are very coordinated or are running serverless apps. And if it was true, there would be no need for Amazon to build services like AWS Systems Manager.