The DevOps community relies heavily on automation tools, two of the most prominent ones being Ansible and Terraform. How are these tools different? How are they similar? How do we decide which one to use in a given scenario? This blog attempts to answer these questions.
Terraform is an open-source tool developed by HashiCorp for infrastructure automation. It helps create, update, and version infrastructure, which could include virtual machines, containers, networks, storage, databases, and more.
Central to Terraform’s philosophy is the notion of infrastructure-as-code (IaC). The thing about the code is that we can build it and then manage changes with version control. The IaC approach uses code to describe infrastructure requirements. The life cycle of the infrastructure is managed through the execution of code. Changes to this code are managed in a version control system.
To learn more about Terraform, check out the following course on Educative.
Infrastructure as code (IaC) is a standard practice of maintaining infrastructure configuration as code. Terraform is a cross-platform tool that introduces the HashiCorp Configuration Language (HCL) for the provisioning of infrastructures on different cloud platforms like Azure, AWS, and Google Cloud. First you’ll learn about the basics of IaC and the tools used for it. Next, you’ll learn about Terraform, how to deploy resources using it, and the Terraform state file. Then you’ll cover the basics of HCL, followed by how to work with outputs, expressions, and loops. You’ll also cover local and remote provisioners, and learn how to employ HCL to provision and manage resources using different concepts like modules, variables, provisioners, and the Terraform state file. Finally, you’ll learn how to use the Terraform Cloud. By the end of this course, you’ll be able to provision, delete, and update resources on a cloud platform using Terraform. Knowing how to use Terraform effectively will set you up for success.
IT people have previously done this to an extent using shell scripts that invoke certain infrastructure-specific tools to manage the infrastructure life cycle. However, we have to write the shell script differently for each vendor and each device. IaC tools like Terraform take that pain away as we see later in this blog.
To learn more about Terraform as used with the AWS cloud, check out the following course.
In this course, you will work from the ground up, starting with what Terraform is and the problems it solves. The course will then guide you through the features of Terraform. You will build on your knowledge with the end goal of you being comfortable building projects using Terraform.
Terraform employs a declarative approach to infrastructure. What that means is that we specify our desired infrastructure in a HashiCorp Configuration Language (HCL) file. Then, we can use command-line utilities to deploy or tear down the corresponding infrastructure. This infrastructure can be on-premises or on any of the popular public cloud service providers. The various infrastructure types are supported using plugins known as providers. There’s one for each of the popular public cloud service providers and for on-premises.
The following diagram captures Terraform’s infrastructure orchestration at a high level.
The diagram above shows that the Terraform CLI works with HCL configuration files and communicates with the Terraform Core. The Terraform Core components make API calls to the cloud provider for the infrastructure. The cloud provider then interacts with the managed infrastructure.
Let’s review some of the use cases for Terraform.
Terraform enables the provisioning, modification, and tear-down of infrastructure on-premises and in any popular public cloud service provider. Look at an example of this.
Suppose we want to create infrastructure to deploy an application to the AWS cloud. First, we export our AWS Access Key ID and Secret Access Key to the environment variables AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
, respectively. That enables the terraform provider for AWS to authenticate with AWS.
Next, we create a file named main.tf
at a suitable place in our file system. It is useful to put this in a Git repository for versioning. Here’s an example main.tf
file that creates an AWS EC2 instance:
terraform {required_providers {aws = {source = "hashicorp/aws"version = "~> 5.40"}}required_version = ">= 1.4.0"}provider "aws" {region = "us-east-1"}resource "ec2_instance" "web_server" {ami = "ami-0005e0cfe09cc9050"instance_type = "t2.micro"tags = {Name = "WebServerInstance"}}
We start with a terraform
section in lines 1–10, where we identify that we wish to use the hashicorp/aws
provider version at least 5.40
(line 5). We also declare that we require Terraform version 1.4.0 or later (line 9). In line 13, we use a provider
block to declare that we want our resources created in the US East 1 region. Finally, in lines 16–23, we declare the characteristics of the EC2 instance using a resource
block, including the AMI image (line 17), the instance type (line 18), and a tag (line 21).
Having created this file, we issue the command terraform plan
to create a deployment plan. We review the reported plan and proceed to the next step, which is to run the command terraform apply
. This actually creates the requested EC2 instance. Finally, if we want to terminate this EC2 instance, we can run the terraform destroy
command from the same directory.
After running terraform apply
, if we need to make changes to the deployed infrastructure, for example, install some tools or libraries on the running instances or deploy more instances, we can modify the main.tf
file, commit the changes to the Git repository, and run terraform apply
.
Sometimes, organizations need to use a multicloud strategy. For example, they might deploy product analytics in the Google Cloud and the application in AWS. Rather than using two different tools to manage the life cycle of the cloud resources, we can use Terraform to manage resources in both.
Terraform integrates with popular Continuous Integration/Continuous Delivery (CI/CD) tools as well. This means that a code change can trigger infrastructure changes as an atomic step. For example, Terraform commands can be integrated into a Jenkins pipeline, and these commands are executed in specific CI/CD pipeline stages to automate infrastructure changes.
A great use case for Terraform is creating mirrored versions of entire environments when creating the primary environment, which is useful for disaster recovery.
Ansible is an open-source IT automation tool used to automate many IT processes ranging from configuration management to infrastructure orchestration. It works on the basis of playbooks written as YAML files, and command-line tools. Ansible consists of an Ansible engine that processes the YAML playbooks and executes the tasks defined in them. It has an extensible architecture based on modules to perform different tasks.
Just as Terraform relies on providers to interact with different kinds of infrastructure, Ansible has a pluggable architecture consisting of an Ansible engine coupled with modules.
To learn more about automating infrastructure with Ansible, check out the following course.
In an era of IT environments, automation is no longer a luxury—it's a necessity. Ansible, an open-source IT automation tool, has become a go-to solution for streamlining IT tasks. This comprehensive course aims to equip you with both fundamental and advanced Ansible knowledge. You'll start by installing Ansible, understanding its architecture, and diving into inventory management and playbook creation. Next, you'll explore variables, conditional statements, loops, handlers, roles, and collections. After that, the course dives into Ansible for Linux-specific tasks and troubleshooting techniques to resolve common problems like connection failures, missing parameters, and syntax errors. After completing this course, you'll have gained a robust understanding of Ansible, with the ability to create efficient playbooks, manage inventory, troubleshoot common problems, and automate a wide range of IT tasks. These skills will provide a strong foundation for a thriving career in IT infrastructure management.
The following diagram indicates at a high level how Ansible does infrastructure orchestration.
When we invoke an Ansible command on the control node, it interacts with the inventory file to determine the managed nodes involved in the playbook execution. The control node identifies the modules needed in the playbook execution. The control node establishes a connection with the target node over protocols such as SSH and transfers the modules needed to manage the node. Ansible then executes the tasks that are mentioned in the playbook on the target node. The results and output from each task’s execution are returned to the control node.
Let’s look at some of the use cases for Ansible.
Organizations must maintain hardware and software in a specific desired state to keep their IT system running smoothly. By implementing configuration management across hardware and software systems, organizations ensure that changes to the infrastructure state are controlled and predictable. The process generally starts with collecting the current configuration of all devices and software in a central repository. That forms the single source of truth.
Ansible is a useful tool for application deployment. It can be used to set up the target environment for our application. This includes provisioning of servers, installation of dependencies, set up and configuration of networking, required services, and tasks like copying of application artifacts. We can also use Ansible to perform Blue-Green deployments, rolling updates, and rollbacks. Ansible works with most CI/CD tools. For example, the Ansible playbooks can be part of a Jenkins pipeline, such that the playbooks are executed within specific CI/CD pipeline stages. Another common use of Ansible in application deployment is for tasks like cache warming, database migration, and monitoring.
Ansible is a useful tool for infrastructure orchestration. This includes deploying servers or containers, installing dependencies, and setting up complete application environments. Thanks to the Ansible modules for popular public cloud service providers, this works for deployments on on-premises and the public cloud.
To learn more about Ansible, check out the following course.
Ansible is one of the leading tools for software provisioning, configuration management, and application deployment. In this course, you will learn the ins and outs of Ansible with the goal of managing and automating your infrastructure and code’s deployment. You will learn how to set up a docker environment, connect with cloud providers like AWS and Azure, manage infrastructure on AWS and Azure using Ansible, and lastly how to automate configuration and state management processes. Throughout each section, you will dive into the fundamentals of Ansible through practical and real-world scenarios. By the end, you will have a great new skill that will open a lot of doors for you like cloud computing and DevOps. This will definitely be a good tool to put on your resume and will help you further your career.
Here is an example Ansible playbook that sets up an EC2 instance:
- name: Provision EC2 Instancehosts: localhostgather_facts: novars:aws_region: "us-east-1"instance_type: "t2.micro"ami_id: "ami-0005e0cfe09cc9050"key_name: "key-pair-name"security_group: "security-group-name"subnet_id: "subnet-id"instance_tags:Name: "ExampleInstance"tasks:- name: Provision EC2 Instanceec2:region: "{{ aws_region }}"instance_type: "{{ instance_type }}"image: "{{ ami_id }}"key_name: "{{ key_name }}"group: "{{ security_group }}"subnet_id: "{{ subnet_id }}"state: presentwait: yestags: "{{ instance_tags }}"
In the playbook above, we name the task in line 1. In line 2, we declare that the above commands must be executed on the local machine. In line 3, we specify that facts don’t need to be collected from the remote machine. Here, facts include system information such as IP address, operating system, hardware configuration, etc. We declare several variables in lines 5–12. Then, we use these variables in the task specification in lines 14–24.
This includes multicloud scenarios. A common scenario is for an organization to use one cloud provider (AWS, for example) for their application and another (Azure, for example) for disaster recovery. Ansible can help easily set both environments up.
From the discussion above on Ansible and Terraform use cases, we can notice some overlap. Let’s discuss some similarities between the two tools.
Ansible and Terraform are IaC tools that work with all major public cloud providers. These tools allow the users to automate resource deployment on any public cloud through modules (in the case of Ansible) and providers (in the case of Terraform).
Both Ansible and Terraform are capable of the same high-level functionalities, such as infrastructure provisioning, updates, and configuration management for both on-premises and public cloud.
Both Ansible and Terraform allow the configuration of infrastructure—both software and hardware.
Now, let’s compare Ansible and Terraform in terms of their differences.
For starters, Ansible is primarily a configuration management tool, whereas configuration management can be done with Terraform, but that isn’t its primary purpose.
Terraform requires the installation of an agent on the target infrastructure, whereas Ansible has an agent-less architecture.
Ansible uses a procedural approach, executing a playbook step by step and stopping wherever an error is encountered. This makes troubleshooting somewhat convenient. In contrast, in Terraform, we only describe the desired infrastructure elements and their relationship to each other. Terraform analyzes this specification and develops a plan to create the needed infrastructure.
Terraform’s philosophy is that of immutable infrastructure. It does allow updating existing infrastructure, but that isn’t its core trait. Ansible, on the other hand, is based primarily on mutable infrastructure.
Terraform automatically manages resource dependencies, which must be manually managed with Ansible.
Infrastructure provisioning in Terraform is pull-based, whereas that in Ansible is push-based. In Ansible, the control node initiates connections to the target hosts over a protocol such as SSH and pushes configuration and commands to them to execute tasks sequentially, actively managing the execution flow. In Terraform, the control node pulls configuration files and compares the desired state with the state of the actual infrastructure. It then determines an execution plan to reach the desired state. Unlike Ansible, it does not directly interact with the target infrastructure elements.
Ansible playbooks are written in YAML format, which is commonly understood, whereas Terraform uses files written in the HCL format.
Both Terraform and Ansible have the concept of modules. But the term means different things. A Terraform module is at a higher level of abstraction. It is a representation of a collection of resources. It allows reusing the same collection of resources. A module in Ansible is a collection of tasks and actions on the managed infrastructure, also for reusability, but at a much lower level. In short, Terraform modules group infrastructure elements, whereas Ansible modules are collections of tasks to be performed on infrastructure.
Ansible is a configuration management tool, whereas Terraform is an infrastructure automation tool. Both can be used to accomplish similar tasks. However, Ansible is geared primarily toward configuration management and uses a mutable infrastructure philosophy, whereas Terraform is geared primarily toward infrastructure automation and uses an immutable infrastructure philosophy. The specific choice of tool is driven by the specific use case and organizational preferences.
Free Resources