What is Terraform? What is infrastructure provisioning? Defining Infrastructure as Code
Infrastructure as code (IaC) is the concept of managing and provisioning your IT infrastructure using configuration files. Terraform is an infrastructure-as-code software tool that enables you to safely and predictably build, change, and improve infrastructure.
Infrastructure provisioning is the process of setting up your IT infrastructure. It also refers to the steps required to manage access to data and resources, and make them available to users and systems.
Terraform is an open-source orchestration tool developed by HashiCorp, which was created using the Go programming language. The Go language is compiled into a binary file called “terraform”, which makes requests to the cloud provider’s application programming interface (API). Terraform makes these requests based on user-written infrastructure templates. These templates are text files and are written similarly to program code, describing the desired infrastructure that will be created.
What is Terraform used for? Terraform Basic Use Cases
As we mentioned, Terraform is an orchestration tool used for Infrastructure as Code (IaC). It makes configuration files resemble easy-to-read documentation, describing on-prem and cloud resources. Through the commands described below, terraform realizes these resources, creating the infrastructure we desire.
The image below previews how to configure Google Cloud Platform as a cloud provider and implement a private key. This requires parameters for the GCP project, the project region and zone, and a GCP authentication file.
Once we define the zone and the provider, we can move on to everything else our infrastructure needs: instances, load balancers, auto-scaling, security groups, etc. Here is a simple example of defining a Kubernetes Cluster on Google Kubernetes Engine (GKE) using Terraform.
Terraform Architecture & Basic Commands
Once the templates are prepared, they can be applied using the “terraform apply” command, which will create the desired infrastructure. When you enter this command, the terraform binary translates the Terraform code into a series of API requests to the provider that creates the infrastructure. Similarly, the “terraform destroy” command is used to demolish existing infrastructure. Another useful command is the “terraform plan”, which creates an implementation plan, defining what actions need to be taken to achieve the infrastructure described in the templates. This plan is based on the templates and infrastructure state files used by Terraform.
Because Terraform templates are written in the form of program code, this means that they can be stored in a version control system, which allows several developers to work on it. The problem occurs when saving and working with the state file. Because it is stored locally by default, this means that when using a version control system, the state file will also need to be stored on that system. This is problematic because it means that for proper operation, each participant in the project must ensure that each time it works with the latest version of the state file. Although inconvenient, this option would work. But if the state file is stored in shared storage, a new problem arises – the lack of so-called ‘locking’. The lock prohibits the simultaneous execution of Terraform operations working with the state file. This is useful because writing to a shared state file at the same time can lead to conflicts, data loss, file corruption, and inconsistencies between templates and infrastructure in the state file. Also, storing the status file in a version control system is undesirable, as all data in the file is kept in unencrypted text.
The good practice for storing the status file is to store it remotely via the so-called backend. This Terraform backend determines the loading and storage of data in Terraform. By default, a local backend is used to store data on the local disk. It is possible to use a remote backend, through which Terraform will store data on the state of the infrastructure in a remote location, which solves all the problems encountered when using a version control system.
There are also some good practices in writing the code for defining our infrastructure. The first example we gave is not actually the best practice of writing terraform files. We recommend using different terraform files to make the code more readable, less complex, and easy to change when needed. You may review an example of infrastructure files here:
As you can see there are files such as versions, outputs, and variables. In the variable files are stored all the variables needed for the infrastructure. That’s a really good practice for saving information, because once again – it’s easy to read and change after. So if we take the first example of defining Google provider and split it into two files, the variable will look like this:
It is exactly the same with versions and outputs. You can store versions and version requirements in the versions file and outputs in the outputs file. While you can store everything in the main file, that’s not a good practice.
For more in-depth tutorials and practices in Terraform, stay tuned.