I had a dream last night that I invented a pill which would make me an 8 years old kid. I can enjoy my childhood again. Wooohooooo!! But that Pill would not stop me from growing old. However, the brighter side is, I can always look in the mirror and see if I have grown old. If I have, meaning my current state (being old) does not match with my desired state (be an 8 years old kid), I can eat that magic pill and then my body would get destroyed and a new 8 years old Avatar of me would get created. Isn’t it an interesting dream. LOL.
Terraform is exactly like that dream.
Let’s break my dream into pieces and see how is it comparable with Terraform.
Pill – That pill reflects my desire to be an 8 years old kid. When you write code in configuration files (desired state) – It is like that pill that I dreamt of. You write the code in the configuration files desiring how you want your infra to look like.
My Body – My body tells me my current state, if I have grown old or not. Like I may have grey hair or I may have become taller than 8 years old version of mine etc. Terraform state is like body. State tells you the current state of Infra.
When you run terraform plan or terraform apply command, it refreshes the state file i.e. it checks the current state of resources managed by terraform and updates the state file (.tfstate). Then it checks the code that is written in configuration files and if there is any mismatch, it destroys those resources and recreates them again. Just like after eating pill, my body (current state) got destroyed and a new avatar of me (desired state) got created.
I can say Terraform is a dream come true. Hahahaha…
So we understand the importance of Terraform State file (.tfstate). When we run terraform apply command for the first time, Terraform State file(.tfstate) gets created. This file is in json format.
Terraform State Locking
Terraform State file can be stored either Locally or Remotely. But state file may get corrupt if multiple users would try to update the file at the same time. That is when State Locking concept comes into the picture. If a user would be updating or using the file by running commands like terraform plan or terraform apply, Terraform State file(.tfstate) would be locked, so that no one else would be able to use Terraform State file(.tfstate) as it is already in use. As soon as the user is done working on the state file, the lock would be removed automatically.
If Terraform State file is stored locally on the computer from where Terraform is run from then by default Terraform State Locking is enabled. If the State file is in use then you would also see a new file being created temporarily with name .terraform.tfstate.lock.info. This file would hold information of user who is currently using the file, Lock ID and a lot of other details.
Below screenshot shows details present in the lock file
If a state file is already in use by User A (Example) and if User B tries to run terraform plan command, what happens – is shown in the below screenshot
Backends
It is always recommended to store the state file at a remote backend (storage) like AWS S3 Bucket or Azurerm or GCS etc, and it is recommended not to store it on local computer.
Advantages of Remote Backend
There are many advantages of storing the state file at remote backend like
- Encryption
- Shared Storage
- Versioning
- Sate Locking
- Security
- Remote operations
Implementing S3 Backend with state locking capabilities
What do we need?
- S3 Bucket – to use that as our backend to store .tfstate file
- Dynamodb table – for state locking capabilities
- Backend Block – Collate all the info of bucket details and dynamodb table in a Backend Block in configuration file
- Configuration File – Where desired state would be written. Then run terraform apply command to generate .tfstate file at remote backend (S3)
S3 Bucket
I have created S3 bucket as shown in below screenshot.
I created a test folder in S3 bucket
Dynamodb table
Created a Dynamodb Table with name tfstate_table.
Important: While creating a table, Partition Key value should be LockID
Backend Block
Now we will create a backend block and put all the details of S3 bucket and dynamodb table
Attributes: –
Bucket – would contain S3 bucket name
Key – Path where the file would be saved
Dynamodb_table – table name
Configuration File
This is where the main code would be written (Desired state)
To demonstrate, if all the dots connect together and work, I have created time_sleep resource that would wait for specific seconds before the resource is created. This would give us opportunity to check if the state locking capabilities work or not.
I will now run terraform init, terraform plan and terraform apply command. As soon as I run terraform apply command, we see below that it first tries to acquire state lock. Once done, no one else would be able to change the use the state file
While state file is still locked, lets go and check if we are able to get details of lock in dynamodb table
In the above screenshot, we see that we got all the details of user, LockID etc in dynamodb table.
As soon as the resource is created, state lock would be released, for others to use the state file.
Terraform State Commands
Terraform State Pull – It pulls down the contents of .tfstate file and displays it on screen. You can also output the results in a local file.
Terraform state list – This command shows the list of all the resources in state file
Terraform state show – This command shows the attributes of a specific resource
Terraform refresh – This command reads the settings of all the resources managed by Terraform and then updates the details in Terraform state, so that the state file represents the current state of resources in the infra.
Terraform taint – If we think a resource has become corrupt/damaged then we can run this command against that resource. This would force the resource to be destroyed and recreated when we run terraform apply next time.
Terraform Untaint – This command would untaint any resource that has been marked as ‘tainted’
Hope you enjoyed learning today.
