22
Terraform Associate Certification: Remote Backend
In the previous post we talked about how does Terraform manages the resources in the cloud using the local state file, however in the real world we will have to collaborate with other members of the team, it is to say that not only one person is going to modify the Terraform files.
In this scenario, does the entire team have to modify the local state file manually in their machine to be all synchronized? 🤔.
Well, it does not sound so practical. When we work in a collaborative workflow it is necessary to use a remote backend which is the same as a remote state file.
The Remote Backend is the resource in Terraform that will allows us to store the state file in a remote location, not locally as it occurs in TF by default.
Doing this, all the team members that are working with the Terraform files will be able to do it in a synchronized way, there will be a unique shared state file for the project placed in a remote location which can be an AWS S3 Bucket, Consul, AzureRM, etc. In this post we are going to use an AWS S3 Bucket as our remote backend.
If any backend is specified in the code, the state will be stored locally. Keeping that in mind, let's define our first remote backend 👨🏽💻.
To keep our code in a good structure, we need to create a file named backend.tf (you can name it as whatever you want, it is just to follow the standard). Inside of it we are going to use the next code and then configure it with the command terraform init in the terminal:
Note that the AWS S3 Bucket needs to be created in the cloud before running "terraform init", otherwise it will show an error because there will not be a bucket to store the remote state file.
Once the code has been applied, you will see that inside of the .terraform folder there is a terraform.tfstate file. However, the information about the created resources are not stored there, it only specifies that the backend is an S3 Bucket.
Now we are able to work in the same Terraform infrastructure file in a collaborative way, however, what if while I'm modifying a specific resource in the code, another member of the team modify the same part as well? What changes are the ones that will remain? 😣.
This is a common problem when a team works in the same code, the solution of it is the state locking. As its name says, it is going to block the state during the applying operations such as terraform plan or terraform apply.
Once we have added the state locking (which is also included by default when we use the local state but not in a remote backend) if a user is running a terraform apply command for example, and another one tries to do it as well at the same time, TF will show him an error specifying that the state is currently locked by the changes of a different user, avoiding inconveniences in the code.
To create the state locking with the S3 Bucket, it is necessary to create a DynamoDB and add LockID as primary key:
Now, let's specify to the backend that we are going to use a DynamoDB for our State Locking. It is very simple, we just need to add the dynamodb_table tag:
To apply this configuration let's run the command terraform init.
Now we can work with the TF files within the team with the best practices 😉.
This topic can be a little tricky to understand, mainly because there are many resources that can be used as Remote Backends, however, you don't have to be an expert implementing all of them. In my case, AWS is the CP that I mostly use, that's why I'm using its resources with Terraform.
If you have any doubt or comments about it let's discuss it, remember we are here to help each other 😉💙.
22