Introduction To Terraform
Let's consider a scenario, where our client is using Cloud, be it AWS/Azure/GCP for the Project.
There are lots of services provided by these Cloud Providers which a client can use to meet its requirements like storage options, virtual machines, monitoring solutions, etc.
But what if the client needs a technique and a way in which the infrastructure could be spin up with a bit of automation without eventually logging into the User Interface of the Cloud Provider. What if a person can codify the infrastructure to be built using the command line without any manual intervention.
Terraform is a really handy tech tool that lets you build, change, and version infrastructure safely and efficiently. With Terraform all you have to do is built the code once, and the code can be used a number of times with the requirements. Terraform is our tool of choice to manage the entire lifecycle of infrastructure using Infra As A Code. That means declaring infrastructure components in configuration files that are then used by Terraform to provision, adjust and tear down infrastructure in various cloud providers.
For example, say you are working in Azure and would like to spin up several virtual machines of specific types. You would define the type and number of instances in a configuration file, and Terraform would use that to communicate with the Azure API to create those instances. The same file could then be used to adjust the configuration, for example increasing or decreasing the number of instances.
What exactly to use Terraform?
- Terraform lets you define infrastructure in config/code and will enable you to rebuild/change and track changes to infrastructure with ease. which helps to provide a high-level description of infrastructure.
- Terraform enables you to implement all kinds of coding principles like having your code in source control, the ability to write automated tests, etc
- Terraform has a simple modular syntax and supports multi-cloud infrastructure configuration.
- It uses a high-level declarative style language called HashiCorp Configuration Language (HCL) for defining infrastructure in ‘simple for humans to read’ configuration files. Organizations can use public templates and can have a unique private registry.
- Terraform has a lively community and is open-source; there is a massive community developing around this tool. Many people are already using it, and it’s easier to find people who know how to use it, plugins, extensions, professional support, etc.
- Terraform allows you to see and validate what exactly you will be building with the script you code. This means it is easier to test, manage and deploy with Zero errors.
- Let's consider a scenario, Where a person accidentally deletes a running resource from the cloud. Here terraform helps us to manage the state of any resource we provisioned where we can deploy the same resource with the exact configurations using the State file generated by Terraform.
Life Cycle of Terraform Workflow
Stage 1 → Code :
As a developer, you start writing the code, coding the proper configrations required to build the resource. Using variables wherever required, Calling the provider to be used.
Code part mainly evolves around 4 files :
- main.tf→ The actual resource that is required to be deployed is written here. For Example: if we want to create a Resource Group in azure, we write the code that calls the resource group from the azure provider.
- variables.tf →We use variables when we do not want to hard code any particular resource value. For Example, Instead of giving the name of the resource group in the main file, we can use a variable and use it in a separate file.
- provider.tf → The provider we use and the secrets that would be used to connect with the API of the cloud are written here. Example: In the case of Azure, We use client_id, client_secret, subscription_id, and tenant_id.
- terraform.tfvars →Any variable we use in our code can be assigned a value in this file.
Stage 2 → Init
The ‘terraform init’ step analyses the code, figures out the provider, and downloads all the plugins (code) needed by the provider. Provider plugins are responsible for interacting over APIs provided by the cloud platforms using the corresponding CLI tools. They are responsible for the life cycle of the resource, i.e., create, read, update and delete.
Stage 3 →Validate
It validates and checks the syntax we have used in our code meets the requirements in Terraform.
Stage 4 →Plan
Generates and shows us the execution plan according to our code. It checks the previous state we used and then shows us the changed execution plan.
Stage 5 →Apply
The ‘terraform apply’ executes the exact same provisioning plan defined in the last step, after being reviewed. Terraform transforms configuration files (.tf) based on appropriate API calls to a cloud provider(s) automating resource creation (using the provider’s CLI) seamlessly.
Stage 6 →Destroy
After resources are created, there may be a need to terminate them. As Terraform tracks all the resources, terminating them is also simple. All that is needed is to run ‘terraform destroy. Again, Terraform will evaluate the changes and execute them after you give permission.
And so on…In order to build the same resource again, we can use the state file which will have the exact configuration of the resource we deleted.
That's where Terraform can be a Gem for A DevOps Guy !!….