In this article we are going to tackle Terraform, which is an open-source infrastructure as a code software tool.
But first let’s see the general concept of IaC (Infrastructure As A Code):
What is IaC?
Infrastructure as Code (IaC) is a type of IT infrastructure that operations teams can automatically manage and provision via code, rather than using a manual or interactive process.
Infrastructure as Code is sometimes referred to as programmable infrastructure. IaC is therefore an approach to designing and managing infrastructure and the services it supports.
IaC involves infrastructure being written to files in the form of code and maintained with source control software (SCM) such as Git. Within this framework, this code could be the subject of any DevOps practice such as testing and integration before being released to production as part of the infrastructure in a larger DevOps chain.
In order to approach IaC in the right way, the choice of the tool to generate the infrastructure must be well oriented to the one that meets the challenges of a dynamic infrastructure.
In this article, we will define the concept of the Terraform tool.
What is Terraform?
In case you have never heard about it, terraform is a tool for provisioning infrastructures.
When we talk about provisioning, two different problems may pop up. So when we provision, there’s the day one challenge (when we haven’t started running anything yet) and the more difficult one, that is day two plus challenge (when we have an existing set of infrastructure but we’re trying to evolve it).
How does terreform actually solve these problems? We basically believe in an infrastructure-as-code approach, and what we mean by that is to allow you to define in a kind of terraform configuration file set what you want your infrastructure to look like, in something very simple and human readable. Describing your overall topology, refers to an infrastructure where you might have a virtual private cloud, security groups…, and in that environment you define your set of virtual machines that you want to provision.
Imagine how this graph expands over time, adding different elements, different amounts while growing your infrastructure day by day.
Terreform gives you a workflow for creating and managing this environment. You can describe the vpc resource and the fields that are required to create this element of your infrastructure and then as you define other things you can add references to the other components of your infrastructure, and this is sort of three different main commands that you run.
The first commande is “Terraform refresh“, that reads the current settings from all managed remote objects and updates the Terraform state to match.
Eventually, you should run “Terraform Plan” where terraform figures out what needs to be done, by creating an execution plan.
By default, creating a plan consists of:
- Reading the current state of any already-existing remote objects to make sure that the Terraform state is up-to-date.
- Comparing the current configuration to the prior state and noting any differences.
- Proposing a set of change actions that should, if applied, make the remote objects match the configuration.
and for the last part you have to run “Terraform Apply”, which executes the actions suggested in a Terraform plan.
By doing so, terraform will figure out what is the right order for these actions , so there’s a natural dependency here, the network must be defined first before you can define the SG around it. Once those are defined you can boot all of your VMs.
This gives you a way to do your day one infrastructure. So day one, you describe what you want (how your universe looks like), then you start developing your infrastructure, for example you want to add a DNS service or a content distribution network or maybe you want your VMs to be connected to a monitoring system.
So in this case you change your terraform configuration, you enhance it by adding the definition of this other element to your terraform config file and you rerun the exact framework.
One of the advantages of this workflow is the moment you decide you might need to decommission a service that you don’t need any more, you have the option to come in and destroy by using the command “Terraform Destroy” which is a convenient way to destroy all remote objects managed by a particular Terraform configuration.
Now we can efficiently, at the end of our life cycle go from nothing to something evolving a day over day.
PS: You shouldn’t need to use the refresh command, because Terraform automatically performs the same refreshing actions as a part of creating a plan in both the terraform plan and terraform apply commands. This command is here primarily for backward compatibility.
How does Terraform work?
So far everything we have talked about is really about the workflow, so how does terraform actually make any of this stuff work? this is where terraform architecture becomes important, so when we talk about the way terraform actually works, there’s sort of two major components:
one is the terraform core: it takes the terraform configuration which is being provided by the user and then takes the terraform state which is managed by terraform itself. As such, this gets fed into the core that is responsible for figuring out what is that graph of our different resources for exemple how these different pieces relate to each other or what needs to be created/updated/destroyed, it does all the essential lifecycle management.
On the backside, terraform supports many different providers , such as: cloud providers (AWS,GCP,AZURE) and they also could be on-premise infrastructure (VMware,OpenStack.) But this support is not restricted or limited only to Infrastructure As A Service , terraform can also manage higher level like Platform As A Service(Kubernetes,Lambdas..)or even Software As A Service (DataDog,GitHub..)
All of these are important pieces of the infrastructure, they are all part of the logical end-to-end delivery.
Terraform has over a hundred providers for different technologies, and each provider gives terraform users access to their resources. It also gives you the ability to create infrastructure at different levels.
Terraform Core Concepts:
Below are the core concepts/terminologies used in Terraform:
- Variables: 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 its 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: It is implemented by providers to return information on external objects to terraform.
- Output Values: These are return values of a terraform module that can be used by other configurations.
- 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 in the real/current state of the infrastructure in order to move to the desired state.
Conclusion:
Through this article, we have seen the concepts of Terraform, and how it applies in the infrastructure as a code approach, and the way it gets easily integrated with several providers.
We hope you have acquired the bigger picture of Terraform by now. If you are interested in learning more about this powerful provisioning tool then stick around, other informative articles will be released soon!
