Terraform by HashiCorp is the current industry standard tool regarding automated infrastructure provisioning. With Terraform provisioning of resources via machine-readable files is made possible in a cloud-agnostic fashion as well as on-premise. It does this using the so-called Terraform Providers, which are pieces of software, often implemented by the community, as illustrated in the figure below. Which cloud providers are specifically supported can be seen in the Terraform Registry.

Terraform to cloud provider connection (HashiCorp)

Language Support 💻

Terraform supports multiple languages for provisioning infrastructure. First and foremost is the HCL, the HashiCorp Configuration Language, which was specifically designed to be used for Terraform. Second, configuration via Json or CRDS (Custom Resource Definition used for Kubernetes) are possible too. Yet while those are all languages rather common in the operations sector (apart from Json), Terraform also supports Typescript, Python, Java, C# and Go via its CDK (Cloud Development Kit), which are more common in software engineering.

Support languages of Terraform (HashiCorp)

The greatest difference in using a GPL for Terraform files is that options like the HCL are declarative approaches, meaning the goal of the code is described within it, whereas languages such as Java or C# require an imperative defining of what should be done to achieve the desired state (Howard, 2022).

The choice of what language to use heavily depends on multiple factors, such as readability of the code as a declarative style generally is associated with being more human-readable, the performance and ease of deployment as code must go through additional steps before being executed, and the general experience and knowledge of the personnel in charge of the implementation.

The relevance of this section for our on going quest of understanding QA for IaC is the possible usage of GPLs when working with Terraform. This implies that there are plenty well-known and well-incorporated testing tools available. Yet the possible level of quality assurance not just depends on the language used.

The Terraform Workflow 🌊

“Terraform's purpose is to provide one workflow to provision any infrastructure” (HashiCorp) and it does this by executing a three step workflow:

1. Write – Author infrastructure code
2. Plan – Preview changes that will be done before applying
3. Apply – Provision reproducible infrastructure

Especially the plan phase is relevant from an QA point of view. With this, a feedback loop for the developer is created with which syntax errors can be found and fixed at the earliest point of development possible. Again, just like a Docker image, the plan created in this phase is only a template of changes applicable to the target system. This may also give a possible angle of attack to perform tests on the implemented changes.

Important to add here is that plan does not necessary correspond to the artifacts generated in apply by default. They are separated operations meaning that in apply changes may be made that were not shown in the result of plan as the generated plan is only speculative. However, according to the Terraform documentation:

“You can use the optional -out=FILE option to save the generated plan to a file on disk, which you can later execute by passing the file to terraform apply as an extra argument. This two-step workflow is primarily intended for when running Terraform in automation”
(HashiCorp)

This way additional steps such as testing and general quality assurance are done at the actually used artifact.

Next Steps 🪜

In the previous posws we already looked at how IaC came to be and why we need it in our modern world. Now, being familiar with the tool Terraform and its history, in the next post we will dive into testing Terraform!

Cover image by RDNE Stock project! 🥳