Why Terraform has to be your default choice for Infrastructure as Code
The concept of IaC has created a helping hand for everyday struggling DevOps engineers. Using machine-readable definition files for managing and provisioning entire IT infrastructures automates all aspects in an easy step-by-step manner so you can focus on more important tasks than trying to figure out which servers need snapshots or what hypervisor should be used at any given time.
We have so many IaC tools for configuration management. One of the tools is Terraform, which does both configuration management and orchestration.
(If you need some understanding of the IaC, workflow, place in DevOps, benefits, and challenges in IaC. Please read here.)
Let us see about the Terraform.
- What is Terraform?
- Terraform Workflow
- Terraform Fundamentals
- Why Terraform?
What is Terraform?
Terraform is an IaC tool created by HashiCorp. Terraform enables you to define your infrastructure as code to easily reproduce it and share it among team members or even with several teams.
Terraform not only creates, but it can also destroy entire infrastructures with the push of a button, without worrying about the individual components that make up that infrastructure. Terraform can be used for both public and private clouds and supports providers like Amazon Web Services, Google Cloud Platform, Azure, and more. In this blog, we'll introduce you to Terraform and show you how to get started using it.
Terraform core uses two input sources to do its job:
The first input source is a Terraform configuration that you, as a user, configure. Here, you define what needs to be created or provisioned.
And the second input source is a state where terraform keeps the up-to-date state of how the current setup of the infrastructure looks like.
So, what terraform core does is it takes the input, and it figures out the plan of what needs to be done. It compares the state, what is the current state, and what is the configuration that you desire in the result. It determines what needs to be done to get to that desired state in the configuration file. It figures out what needs to be created, what needs to be updated, and what needs to be deleted to create and provision the infrastructure.
The second component of the architecture is providers for specific technologies. This could be cloud providers like AWS, Azure, GCP, or other infrastructure as a service platforms. It is also a provider for more high-level components like Kubernetes or other platform-as-a-service tools, even some software as a self-service tool.
The terraform init command initializes a working directory containing Terraform configuration files. During init, the configuration is searched for module blocks, and the source code for referenced modules is retrieved from the locations given in their source arguments.
Terraform must initialize the provider before it can be used. Initialization downloads and installs the provider's plugin so that it can later be executed. It initializes the backend configuration and will not create any sample files like the example.tf.
The terraform plan command is used to create an execution plan. It will not modify things in infrastructure.
Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.
This command is a convenient way to check whether the execution plan for a set of changes matches your expectations without changing real resources or the state.
The terraform apply command is used to apply the changes required to reach the desired state of the configuration. Terraform apply will also write data to the terraform.tf state file.
Once the application is completed, resources are immediately available.
The terraform refresh command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure.
This does not modify infrastructure but does modify the state file.
The terraform destroy command is used to destroy the Terraform-managed infrastructure. The Terraform destroy command is not the only command through which infrastructure can be destroyed.
You can remove the resource block from the configuration and run terraform apply this way, you can destroy the infrastructure.
The terraform validate command validates the configuration files in a directory.
Validate runs checks that verify whether a configuration is syntactically valid and thus primarily useful for general verification of reusable modules, including the correctness of attribute names and value types.
It is safe to run this command automatically, for example, as a post-save check in a text editor or as a test step for a reusable module in a CI system. It can run before the terraform plan.
Validation requires an initialized working directory with any referenced plugins and modules installed.
- Variables: It is also used as input variables. It is a key-value pair used by Terraform modules to allow customization.
- Provider: It is a plugin to interact with APIs of service and access its related resources.
- Module: It is a folder with Terraform templates where all the configurations are defined
- State: It consists of cached information about the infrastructure managed by Terraform and the related configurations.
- Resources: It refers to a block of one or more infrastructure objects (compute instances, virtual networks, etc.), which are used in configuring and managing the infrastructure.
- Data Source: Providers implement it to return information on external objects to terraform.
- Output Values: These are return values of a terraform module that other configurations can use.
- Plan: It is one of the stages where it determines what needs to be created, updated, or destroyed to move from the real/current state of the infrastructure to the desired state.
- Apply: It is one of the stages where it applies the changes real/current state of the infrastructure in order to move to the desired state.
There are a few key reasons developers choose to use Terraform over other Infrastructure as Code tools:
- Open source: Terraform is backed by large communities of contributors who build plugins for the platform. Regardless of which cloud provider you use, it's easy to find plugins, extensions, and professional support. This also means Terraform evolves quickly, consistently adding new benefits and improvements.
- Platform agnostic: Meaning you can use it with any cloud services provider. Most other IaC tools are designed to work with a single cloud provider.
- Immutable infrastructure: Most Infrastructure as Code tools create mutable infrastructure, meaning the infrastructure can change to accommodate changes such as a middleware upgrade or a new storage server. The danger with mutable infrastructure is configuration drift — as the changes pile up, the actual provisioning of different servers or other infrastructure elements 'drifts' further from the original configuration, making bugs or performance issues difficult to diagnose and correct. Terraform provisions immutable infrastructure, which means that with each change to the environment, the current configuration is replaced with a new one that accounts for the change, and the infrastructure is reprovisioned. Even better, previous configurations can be retained as versions to enable rollbacks if necessary.
- Declarative: Chef and Ansible encourage a procedural style where you write code that specifies, step-by-step, how to achieve some desired end state. Terraform, CloudFormation, SaltStack, and Puppet all encourage a more declarative style where you write code that specifies your desired end state, and the IaC tool itself is responsible for figuring out how to achieve that state
We have seen all the benefits and limitations of the terraform above. Terraform is also simpler to understand when it comes to its setup. And great at validating, creating, and destroying cloud resources. Suppose you start thinking of making your infrastructure as code. Terraform would be one of the best ones to kick-start.