Book Image

Terraform Cookbook

By : Mikael Krief
Book Image

Terraform Cookbook

By: Mikael Krief

Overview of this book

HashiCorp Configuration Language (HCL) has changed how we define and provision a data center infrastructure with the launch of Terraform—one of the most popular and powerful products for building Infrastructure as Code. This practical guide will show you how to leverage HashiCorp's Terraform tool to manage a complex infrastructure with ease. Starting with recipes for setting up the environment, this book will gradually guide you in configuring, provisioning, collaborating, and building a multi-environment architecture. Unlike other books, you’ll also be able to explore recipes with real-world examples to provision your Azure infrastructure with Terraform. Once you’ve covered topics such as Azure Template, Azure CLI, Terraform configuration, and Terragrunt, you’ll delve into manual and automated testing with Terraform configurations. The next set of chapters will show you how to manage a balanced and efficient infrastructure and create reusable infrastructure with Terraform modules. Finally, you’ll explore the latest DevOps trends such as continuous integration and continuous delivery (CI/CD) and zero-downtime deployments. By the end of this book, you’ll have developed the skills you need to get the most value out of Terraform and manage your infrastructure effectively.
Table of Contents (10 chapters)

Using external resources from other state files

In the previous recipe, we saw that it's possible to retrieve information about resources already present in the infrastructure using data blocks.

In this recipe, we will learn that it is also possible to retrieve external information that is present in other Terraform state files.

Getting ready

For this recipe, we will, similar to the previous recipe, use a Terraform configuration that provisions an Azure App Service that must be part of an already provisioned Service Plan.

Unlike the previous recipe, we will not use individual data sources; instead, we will read outputs from an existing Terraform state file that was used to provision the Service Plan.

As a prerequisite, in the Terraform configuration that was used to provision the Service Plan, we must have an output value (see the Using outputs to expose Terraform provisioned data recipe in this chapter) that returns the identifier of the Service Plan, as shown in the following code:

resource "azurerm_app_service_plan" "plan-app" {
name = "MyServicePlan"
location = "westeurope"
resource_group_name = "myrg"
sku {
tier = "Standard"
size = "S1"

output "service_plan_id" {
description = "output Id of the service plan"
value =

In addition, we used a remote backend version of Azure Storage (see the Protecting state files in an Azure remote backend recipe in Chapter 6, Provisioning Azure Infrastructure with Terraform, for more information) to store the Terraform state file of the Service Plan.

How to do it…

Perform the following steps:

  1. In the Terraform configuration that provides the Azure App Service, add and configure the terraform_remote_state block, as follows:
data "terraform_remote_state" "service_plan_tfstate" {
backend = "azurerm"
config = {
resource_group_name = "rg_tfstate"
storage_account_name = "storstate"
container_name = "tfbackends"
key = "serviceplan.tfstate"
  1. Then, in the Terraform configuration of the Azure App Service, use the created output of the Service Plan, as follows:
resource "azurerm_app_service" "app" {
name = "${var.app_name}-${var.environement}"
location = azurerm_resource_group.rg-app.location
resource_group_name =
app_service_plan_id = data.terraform_remote_state.service_plan_tfstate.service_plan_id

How it works…

In step 1, we added the terraform_remote_state block, which allows us to retrieve outputs present in another Terraform state file. In its block, we specified the remote backend information, which is where the given Terraform state is stored (in this recipe, we used Azure Storage).

In step 2, we used the ID returned by the output present in the Terraform state file.

The result of executing this code is exactly the same as what we saw in the Using external resources with data blocks recipe.

There's more…

This technique is very practical when separating the Terraform configuration that deploys a complex infrastructure.

Separating the Terraform configuration is a good practice because it allows better control and maintainability of the Terraform configuration. It also allows us to provision each part separately, without it impacting the rest of the infrastructure.

To know when to use a data block or a terraform_remote_state block, the following recommendations must be kept in mind:

  • The data block is used in the following cases:
    • When external resources have not been provisioned with Terraform configuration (it has been built manually or with a script)
    • When the user providing the resources of our Terraform configuration does not have access to another remote backend
  • The terraform_remote_state block is used in the following cases:
    • External resources have not been provisioned with Terraform configuration
    • When the user providing the resources of our Terraform configuration has read access to the other remote backend
    • When the external Terraform state file contains the output of the property we need in our Terraform configuration

See also

The documentation for the terraform_remote_state block is available at