Using checks for infrastructure validation

In the previous recipe, Adding custom pre and postconditions, we learned that it is possible to add pre- or postcondition validation inside the resource configuration.

In Terraform version 1.5 and newer, it’s possible to add infrastructure validation directly in the Terraform configuration, which allows us to check that the provisioned infrastructure is working as intended.

Let’s get started!

Getting ready

In this recipe, we will provision a new Azure App Service instance using a Terraform configuration and inside this same Terraform configuration, we will check that the provisioned App Service instance is running and returns an HTTP Status code equal to 200.

Note that in this recipe we will not go into detail about the Terraform configuration for the Azure App Service. We will only look directly at the availability check of the App Service.

So for this recipe, we will start with the Terraform configuration available at https://github.com/PacktPublishing/Terraform-Cookbook-Second-Edition/tree/main/CHAP02/sample-app, which we will copy into another folder called check.

In the recipe we will learn how to check the App Service instance’s availability. The source code of this recipe is available here: https://github.com/PacktPublishing/Terraform-Cookbook-Second-Edition/tree/main/CHAP02/check.

How to do it…

To check the provisioned infrastructure, perform the following steps:

1. In the main.tf file that is copied into the check folder, add the following Terraform configuration:

   check "response" {
     data "http" "webapp" {
       url      = "https://${azurerm_linux_web_app.app.default_hostname}"
   insecure=True
     }
     assert {
       condition     = data.http.webapp.status_code == 200
       error_message = "Web app response is ${data.http.webapp.status_code}"
     }
   }
   

2. In this folder, execute the basic Terraform workflow by running the terraform init, plan, and apply commands.

How it works…

In Step 1, we added the check block, which contains:

• A data HTTP source that performs an HTTP GET on the given URL. Here, we use the default hostname of the web app in the URL property. For more details about the data HTTP source block, refer to the documentation here: https://registry.terraform.io/providers/hashicorp/http/latest/docs/data-sources/http.
• An assert block that evaluates the response of the data source by checking that the HTTP code is equal to 200 (status code ok). If this evaluation returns false, then the assert block displays the configured error_message.

In Step 2, we run the Terraform workflow to create the Azure web app and check its availability. The following image shows the output of the terraform apply command:

Figure 2.20: Check infrastructure validation is successful

There’s more…

• Unlike the pre and postconditions, checking with the check block does not block resource provisioning if the assertion returns false. Instead, just a warning message in the output is displayed as shown in the following screenshot:

Figure 2.21: Check infrastructure validation on error with warning message

• Additionally, in this recipe, we demonstrated a check sample using a data source. However, this data source isn’t mandatory and its use will depend on the specific requirements of your infrastructure checks. For more details about the check block, read the tutorial at https://developer.hashicorp.com/terraform/tutorials/configuration-language/checks.

See also

• The check block documentation is available at https://developer.hashicorp.com/terraform/language/checks.

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/cloudanddevops