Towards high-quality infrastructure-as-code part 3
Note: this is a fairly advanced topic. It assumes you have some experience with Go and understand the Terraform state and resource life-cycle.
One of Terraform’s most significant drawbacks is that there is no clean way of injecting custom functionalities.
The canonical solution for injecting custom functionality is to use a `local_exec` provisioner combined with a shell script. In my opinion, this functionality is not enough for the following reasons:
In part 1 of this blog series, I make a case for testing your Terraform code with Go and Terratest.
In part 2 of this blog series, I’ll be making a case for static analysis tools. Static analysis tools for Terraform are a powerful mechanism to help your team follow industry best-practices. Conversely, your organization’s infrastructure team can leverage static analysis tools and custom checks to document and enforce company-wide policies.
These tools operate on the Terraform code or in the Terraform plan. Hence they are faster to run than an end-to-end test in Terratest. …
As a cloud engineer, I love Terraform. With Terraform, I don’t have to worry about keeping track of infrastructure changes or compute dependencies between each component. Terraform is also cloud-agnostic, so all the Terraform knowledge I’ve accrued over the years can quickly transfer between cloud providers and even into Kubernetes clusters.
While Terraform protects the user against many common mistakes, errors still creep up. An error I’ve encountered many times was a network security group misconfiguration that prevented VMs from communicating inside a Vnet. The Terraform code was syntactically correct but did not work as intended.
Given a spec, it’s…