IaC: Revolutionizing Infrastructure Management

In traditionalway, physical data centers managing multiple physical servers. Maintainence was done by system admins and tech support(manual human effort).

physical infra was quite simple to maintain.

but when the demand grew, management and maintainance became quite difficult. scaling up , scaling down servers based on demand meet of users. based on demand you may need more team members to meet the demand of maintainance that comes along.

next comes cloud way, where you can rent servers or database from cloud providers whenever in use. in this way, you dont have to deal with hassle of maintainance cost or anything. components are requested using ui or api of the cloud providers. scale up, scale down easy simply create or delete instances based on demand.

deployed on multiple regions. if any region goes down it may not affect anything since on other region its working fine. so at the end of the its up and running on other regions and users/ customers wont get affected with the down time in one region.

but manual effort increases in infrastructure components management using ui when you deploy it across multiple regions. every time you add components in one region you have to add it in all other regions too. Also, with increase in demand, infra components also increase and to be increased in all the regions and with this manual effort is also increasing.

infrastructure provisioning means creating infrastructure resources on single or multiple cloud providers.

Install terraform using cli or ui

Provider

terraform is cloud agnostic means you can define you infrastructure across multiple cloud providders

local provider

initialise terraform directory

creates two files after terraform inint:

terraform.lock.hcl : gives info about provider that we have installed. basically gives meta data about the provider to intialised from terraform registry.
(dot) .terraform directory: stores info in related to infrastructure. .terraform directory is an internal workspace that helps Terraform manage the resources and dependencies for your project.
You can safely commit terraform.lock.hcl to version control, but generally, you should ignore the .terraform directory in .gitignore.

Terraform resources:

when you define resources, its necessary to mention write certain properties. for ex. in local_file resource, filename is required.

you can also write filename = “${path.module}/first.txt” and path.module gives path of current file in which you are writing this resources code.

do terraform plan:

terraform references newly resources like:

do terraform apply:

When you run terraform apply, it:
1. Executes terraform plan: It first shows you a preview of the changes it will make to your infrastructure, based on the current configuration.
2. Asks for Confirmation: Terraform then prompts you to confirm by typing "yes" to apply the proposed changes.
3. Applies Changes: After confirmation, Terraform applies the changes to your infrastructure as per the plan.
4. But its a good practice to run terraform plan before terraform apply.

In Terraform, when you modify the content of a file resource, it will:

Delete the existing file: If the content of the file is changed in the configuration, Terraform will delete the current file on the system.
Recreate the file: Terraform will then create a new file with the updated content as specified in the configuration.

you can also create local sensitive file resource from local provider.

terraform destroy:

The terraform destroy command is used to destroy all the resources managed by your Terraform configuration.

Here's how it works:
1. Preview of Resources to be Destroyed: It first shows a list of all the resources that will be destroyed, based on the current state.
2. Confirmation: Terraform prompts you to confirm by typing yes to proceed with the destruction.
3. Resource Destruction: After confirmation, Terraform will delete all the resources it has created, effectively tearing down the infrastructure.

terraform destroy -target=type.reference_name_of_file_to_be_destroyed :: command used to destroy a file with a particular type or particular name.

The reference name has to be different for all all the resources, if the resource type is same. If resource type is different, you can have same name.

Sometimes its not a good practice to delete a particular resource. As one resource could be dependent on another.

terraform plan -out=path :: Write a plan file to the given path. This can be used as input to the "apply" command. creates a plan file.

then run :

and it will execute whatever was there in the plan file to be executed. and wont ask for confirmation. Using plan file it will able to show the structure to everyone before putting it into action (before applying).

Below are the commands that works well automatically without taking any secondary approval. These are called flag-approves.

But they say, approval is important , it cant straight away create or destroy multiple resources. Not a good practice. Best practice is to go with plan first then hit apply.

Terraform State

It keeps the record of everything we create / provision/ manage/ delete in our infrastructure.

Desired state: things we mention in our main.tf config file that we want to achieve.

Then we hit terraform apply, and terraform will compare desired and current state and bring the changes in current state accordingly. And whatever changes it makes in current states, it maintains it all in the terraform.tfstate file everytime you create or delete a resource.

So terraform apply does two things:

Creates resources. and writes it in state file.

Terraform state list :: gives list of all of the resources that have been created.

Terraform state show file_type.file_name :: info about that particular file.

Try out all the other commands from :: terraform state -h

State Drift (state management):

Happens when actual infra is not equal to terraform tf state. ( could be possible when you manually delete a particular resource)

How to handle state drift ?
1. Check through terraform plan as it compares desired state with the actual state. and prompts us to create a particular resource (which you know has been deleted or is not present.) and when you hit apply , it will create the resource again and maintain its entry in tf state file. (Assuming its all done by mistake )
2. Tf refresh :: (What if the deletion was intentional and not a mistake)
  
  It wont make any changes in the infrastrucutre , it will only update the state file. And it wont even look whats there in the config file.
  
  But it sort of creates confusion , something is not created in actual infrastructure and its not in the state file also but its present in the config file so is not a good practice.

Where to store state file?

State files are confidential as sensitive data (which gives content : sensitive value in terminal on hitting terraform plan or apply) is also visible in your state file (like passwords, api keys or any other secret credentials).

Backend is defined to store terraform state file. By default terraform supports local backend means to store terraform state file locally on your system. Path is given to terraform state file.