Terraform vs. Ansible : Key Differences and Comparison of Tools

What is the difference between Terraform and Ansible? Terraform is an open-source platform designed to provision cloud infrastructure, while Ansible is an open-source configuration management tool focused on the configuration of that infrastructure.

Terraform vs Ansible: which tool should you use? Here’s the answer from experts who have working experience on both tools.

This post highlights the differences between Terraform and Ansible, explores the similarities and concludes with the best way to manage infrastructure.

Terraform enables you to provision, manage, and deploy your infrastructure as code (IaC) using a declarative configuration language called HashiCorp Configuration Language (HCL). One of the most popular IaC tools available, it was initially developed by Hashicorp under an open-source license, but it recently switched to a Business Source License (BUSL).

Key features of Terraform:

• State management: Terraform tracks resources and their configuration in a state file.
• Declarative code: Users describe the desired state of their infrastructure, and Terraform manages it.
• Widely adopted: Terraform supports over 3k providers.
• Declarative language: You can divide your infrastructure into multiple reusable modules.

Ansible is a software tool designed for cross-platform automation and orchestration at scale. Written in Python and backed by RedHat and a loyal open-source community, it is a command-line IT automation application widely used for configuration management, infrastructure provisioning, and application deployment use cases.

Key features of Ansible:

• YAML: A popular, simple data format that is easy for humans to understand.
• Modules: Reusable standalone scripts that perform a specific task
• Playbooks: A playbook is a YAML file that expresses configurations, deployments, and Orchestration in Ansible. They contain one or multiple plays.
• Plays: Subset within a playbook. Defines a set of tasks to run on a specific host or group of hosts.
• Inventories: All the machines you use with Ansible are listed in a single simple file, together with their IP addresses, databases, servers, and other details.
• Roles: Redistributable units of organization that make it easier for users to share automation code.

At a very high level, given the capabilities of both the products, Terraform and Ansible come across as similar tools. Both of them are capable of provisioning the new cloud infrastructure and configuring the same with required application components.

Both Terraform and Ansible are capable of executing remote commands on the virtual machine that is newly created. This means, both the tools are agentless. There is no need to deploy agents on the machines for operational purposes.

Terraform uses cloud provider APIs to create infrastructure and basic configuration tasks are achieved using SSH. The same goes with Ansible – it uses SSH to perform all the required configuration tasks. The “state” information for both does not require a separate set of infrastructure to manage, thus both the tools are masterless.

The previous section gives an overview of the two tools in their broadest similarities. At a high level, it sounds like both Terraform and Ansible are capable of provisioning and configuration management. However, a deeper dive into them makes us realize the benefits of one over the other in certain areas.

In general, both the tools are great in their own ways. They have an overlap of functions when it comes to infrastructure management. Infrastructure management broadly encompasses 2 aspects – orchestration and configuration management. 

Terraform and Ansible have their own ways of managing both – with strong and weak points when it comes to overlaps. Thus, it is important to delve into some details of both the tools to make a “perfect” choice or a combination with boundaries.

1. Orchestration vs. Configuration Management

Orchestration/provisioning is a process where we create the infrastructure – virtual machines, network components, databases, etc. Whereas, on the other hand, configuration management is a process of automating versioned software component installation, OS configuration tasks, network and firewall configuration, etc.

Both Terraform and Ansible are capable of performing both tasks. However, Terraform offers a comprehensive solution to manage infrastructure. Terraform uses cloud provider APIs to provision and de-provision the infrastructure based on declared resources. 

Ansible, on the other hand, is also capable of provisioning the cloud infrastructure but it is not comprehensive enough. It is mainly geared towards configuration management. Configuration management is a process of keeping the applications and dependencies up to date. This is where Ansible really shines as compared to Terraform.

Both the tools can perform both kinds of activities. However, there are limitations when implementing configuration management using Terraform, and infrastructure automation using Ansible. They are not flexible enough when it comes to complex infrastructure management.

Logically, we can identify orchestration as Day 0 activity and configuration management as Day 1 activity. Terraform works best for Day 0 activities and Ansible for Day 1 and onwards activities.

2. Declarative vs. Procedural Language

Terraform is used to write Infrastructure as Code (IaC). It uses HCL (Hashicorp Configuration Language) which is declarative in nature. It doesn’t matter in which sequence the code is written. The code could also be dispersed in multiple files.

No matter how you write the code, Terraform identifies the dependencies, and provisions infrastructure. Writing or translating existing infrastructure to code is easy in Terraform. Check this Terraform import tutorial if you would like to know more about importing infrastructure under Terraform management.

Ansible uses YAML syntax to define the procedure to perform on the target infrastructure. Ansible YAML scripts are procedural in nature – meaning when you write the script, it will be executed from top to bottom.

Ansible scripts are called “ansible playbooks“. When you have to perform a certain series of tasks, you define the same in the playbook. The tasks will be performed in the sequence they are written. For example, to install an Apache server on the given virtual machine as a root user, you would have to write the user creation step before defining the task for installation.

3. Mutable vs. Immutable Infrastructure

Application deployment workflow involves provisioning of the infrastructure and installing the right version of source code and dependencies on the provisioned infrastructure. 

Mutability is an attribute associated with the underlying infrastructure that defines the way newer versions of applications and services are deployed. Deployment either takes place on existing infrastructure, or we can provision a completely new set of infrastructure for the same.

The deployment practices typically determine whether the infrastructure is mutable or immutable. When newer versions of applications are released on the same infrastructure, it is called mutable. However, if the deployment happens on completely new infrastructure during releases, it is said to be immutable.

Mutability seems convenient, but the risk of failure associated with it is higher. When application configurations are re-applied on the same infrastructure, there are additional steps of uninstalling the previous version and then installing the desired version. More steps also introduce more chances of failure. Doing this for a fleet of servers can result in uneven configurations and unpredictable behavior.

Instead, if we focus on reducing these number of steps by ignoring the uninstallation procedure and performing the installation on new infrastructure resources – we get a chance to test and revert the new deployment in case of failure. Treating infrastructure as immutable in this way provides greater control over introducing changes.

However, there is no golden rule defined that advocates one approach over the other. 

Since Terraform’s strength lies in handling the infrastructure lifecycle, it supports infrastructure immutability better. It is easier to provision a completely new set of infrastructure and deprovision the older set using Terraform. However, handling configuration changes are not something that can be done in the most efficient manner.

As far as the configuration changes are concerned, Ansible wins the race since it is primarily a configuration management tool. Ansible supports infrastructure immutability by offering VM image creation. However, maintaining these additional images requires additional efforts.

It is recommended to follow the immutable infrastructure approach, where Terraform takes care of the infrastructure management, and Ansible helps apply the changed configuration. This is also known as the Blue/Green deployment strategy, where the risk of configuration failure is reduced.

4. State Management

Terraform manages the entire lifecycle of the resources under its management. It maintains the mapping of infrastructure resources with the current configuration in state files. State management plays a very important role in Terraform.

States are used to track changes to the configuration and provision the same. It is also possible to import existing resources under Terraform management by importing the real-world infrastructure in state files. 

At any given time, it is possible to query the Terraform state files to understand the infrastructure component and their attributes currently available.

As opposed to this, Ansible does not support any lifecycle management. Since Ansible mainly deals with configuration management and considering it defaults to immutable infrastructure, any changes introduced in the configuration are executed automatically on the target resource.

5. Configuration Drift

Configuration drift refers to the difference between the desired and actual state of your configuration. One of the most common reasons for this is that engineers/machines make changes outside the configuration. If you are using Terraform to manage your infrastructure and you make a change outside it, you’ve introduced drift. Drift happens, and solutions like Spacelift’s drift detection not only detect the drift but can optionally remediate it, too.

While both Ansible and Terraform aim to mitigate drift, their methodologies differ. Ansible relies on idempotent tasks and continuous execution without maintaining a persistent state of the infrastructure. In contrast, Terraform relies on a stored state to detect and manage drift, emphasizing a declarative approach to infrastructure as code.

Spacelift’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating both Ansible and Terraform. By introducing Spacelift on top of these tools, you can then easily create custom workflows based on pull requests and apply any necessary compliance checks for your organization.

Another great advantage of using Spacelift is that you can manage different infrastructure tools like Ansible, Terraform, Pulumi, AWS CloudFormation, and even Kubernetes from the same place and combine their Stacks with building workflows across tools.  For example, you can set up Terraform Stacks to provision required infrastructure (like a set of AWS EC2 instances with all their dependencies) and then connect that to an Ansible Stack, which then transactionally configures these EC2 instances using stack dependencies.

If you want to learn more about Spacelift working with Ansible or Terraform, check our documentation or book a demo with one of our engineers.

Which is better: Terraform or Ansible? Terraform works best for infrastructure orchestration, and Ansible is great at configuration management. They have the capabilities to perform each other’s tasks, although in a limited manner. Terraform is better for Day 0 activities, while Ansible is more suitable for Day 1 activities.

It’s recommended to leverage both tools for infrastructure management, based on their respective strengths.