I was tasked with creating AWS resources with Terraform and it was my first time with both. I was also still new to Continuous Integration and Continuous Deployment (CI/CD) at the enterprise level.
These are some bits of knowledge I reflected on after a successful deployment of an RDS that I will carry on to the next Terraform task.
Going in order from what would have saved me the most time had I known:
Know what pipeline you're on and know it well. You'll likely have multiple Terraform pipelines, one for each version. Be aware of how access is managed for the version of Terraform you are going with and make sure you and the rest of your development team has proper access to run its jobs.
As general best practice, you want to keep up with the latest version of Terraform. Here are Terraform's official upgrade guides.
Knowing the jobs attached to your pipeline will help you narrow down the source of an error. If you know your pipeline is good, you can start debugging your code.
But the pipeline can tell you much more than the source of bugs. Once you push your terraform configuration, take a look at what's going on at each job. You'll likely see all the terraform commands being used at different stages. For example, you might see a terraform init followed by terraform validate followed by terraform plan, with the big terraform apply as a manual job at the end. This can teach you a lot about how your team is using Terraform and its features.
This can also help you narrow down errors and know what Terraform docs to reference.
Terraform is written in Hashicorp Configuration Language (HCL) Terraform abstracts the machine out of cloud service providers and maintains those rather than maintaining the software on the machines themselves. That's what allows Terraform to be cloud neutral. HCL is meant to be an easy read for both humans and machines.
The syntax between versions of Terraform can be drastically different. If you're writing for v0.12 in v0.11 you may get errors and warnings at main commands such as terraform init and terraform plan over how you're calling a variable, for example.
Terraform state is stored locally in a file called terraform.tfstate by default but can be stored remotely. If you're working on a team, it is likely you will have a pipeline that stores your state files in the cloud. Therefore, it is best not to commit your local state to your version control system.
You might see potential issues with having a shared state which multiple developers can write to. Terraform uses state locking on any operation that could potentially write to state to prevent others from writing to it simultaneously. Terraform queues up the most recent updated state and runs that first. In other words, if two Terraform jobs are run at the same time, it will take the most recent updated state and run your job against that.
This was somewhat of a shallow deep dive, if that makes sense, but these were some of the bits about Terraform that allowed me to code more comfortably. If you are also of the type who can't sleep soundly without knowing the whys maybe this helped you too.
Top comments (0)