Terraform Block

The Terraform configuration block is a special kind of block in Terraform used to configure some of the Terraform behaviors. This block is not about defining any resources or modules but more about setting specific options and parameters that will impact the behavior of how Terraform will operate.

terraform block syntax

The syntax for the terraform block is:

terraform {
    # arguments 
    # Nested blocks 
}

Let's break this syntax apart:

terraform is the reserved keyword used to define a terraform block in Terraform.

The block body (between {}) contain the settings, that is the Arguments and Nested blocks.

Inside the terraform block, you can declare a number of settings that control Terraform's behavior. Nevertheless, there are some rules you have to be aware of:

Only constant values are allowed: Inside the terraform block, you are only allowed to use constant values, such as strings, numbers, or booleans. You are not allowed to use expressions or dynamic values.

No references to named objects: References to Named objects cannot be made from within the terraform block.

No Terraform language built-in functions : You cannot use any built-in Terraform functions such as concat() or length() within the terraform block.

Available Settings of terraform block

There are three major settings that can be used for customizing the behavior of Terraform:

Specifying a Required Terraform Version

Specifying Provider Requirements

Configuring a Terraform Backend

1. Specifying a Required Terraform Version

The required_version setting lets you constrain the version of Terraform that can use your configuration. When a required_version is specified, Terraform will check if the running version of Terraform is within the constraints. If the versions don't match, then Terraform will Produce an error and Exit without taking any further actions. When using child modules, each module can use its own required_version setting. In this case, all demands at the modules in the module tree have to be satisfied.

If you have a configuration that relies on a certain feature that's introduced in Terraform 1.3.7, this required_version setting can be very useful to ensure that the configuration will not be executed with an earlier version of Terraform that does not have the mentioned feature.

terraform {
    required_version = ">= 1.3.7"
}

If you are running Terraform 1.3.7 or later, such as 1.3.8, 1.4.0, etc., then Terraform will proceed with the configuration. Running Terraform 1.3.6 or earlier, such as 1.3.5, 1.2.4, etc., will result in an error for Terraform to exit because the version is incompatible with the constraint.

By setting the minimum version, you ensure that your Terraform configuration is compatible with a specific set of features, bug fixes, or other changes introduced in version 1.3.7 and later.

2. Specifying Provider Requirements

In Terraform, providers are plugins that interact with external systems such as cloud providers like AWS, Azure, Google Cloud, databases, and other services. You may need to install a provider by specifying which provider and version and where it is located in your Terraform configuration. That's where the required_providers block comes in.

The required_providers block is a mechanism to specify what providers the current Terraform module requires. When you run terraform init or terraform apply, the specified providers in the required providers block will be installed from their source location and loaded into the ~/.terraform.d/plugins directory.

Available arguments of required_providers

The required_providers block has two available arguments:

version: This specifies version constraint for the provider. Its type is String.

source: This specifies the source location of the provider. Its type is String.

Example: Specifying Required Terraform Version and Providers

terraform {
    required_version = ">= 1.3.7"
    required_providers = {
        aws = {
            version = ">= 2.7.0"
            source = "hashicorp/aws"
        },
        google = {
            version = ">= 3.52"
            source = "hashicorp/google"
        }
    }
}

In this example, if you run either terraform init or terraform apply, then Terraform will check whether the required providers are installed in the ~/.terraform.d/plugins directory. If they are not installed, then Terraform will install the required version from the source location specified, in this case, registry.terraform.io and load the installed providers in the ~/.terraform.d/plugins directory.

3. Configuring a Terraform Backend

In Terraform, a backend is essentially the storage system in which Terraform should store its statefile. The statefile keeps track of resources you have created or updated in your infrastructure so that Terraform can manage them effectively. You would need to configure Terraform regarding what kind of backend should be used in order to store the state file through a backend block in the Terraform configuration file.

The backend block is a nested block within your Terraform configuration file. It defines the settings of the state backend that Terraform should use. Here's how you could configure a backend to store your state file in an S3 bucket:

terraform {
    required_version = ">= 1.3.7"
    required_providers = {
        aws = {
            version = ">= 2.7.0"
            source = "hashicorp/aws"
        },
        google = {
            version = ">= 3.52"
            source = "hashicorp/google"
        }
    }
    backend "s3" {
        bucket = "my-state-bucket"
        region = "us-west-2"
    }
}

Here, we tell Terraform to store the state remotely in an S3 bucket "my-state-bucket" in region "us-west-2".

By configuring a backend, you're telling Terraform where to store its state file exactly. It allows Terraform not just to manage your infrastructure effectively but also determines where it will download the state file from. This way, Terraform will track changes in your resources and eventually update your infrastructure.

Resources

Modules

Simple Data types - String, Number, Boolean

Expression

Build-in Functions

Backend and Statefile

Feedback

Was this page helpful?

About

Contact

DevOpsResourceHub is designed to enhance your learning experience in DevOps technologies. While we strive to make our examples clear and easy to understand, and we regularly update our content to ensure accuracy, we acknowledge that occasional mistakes may occur. We encourage continuous learning and welcome feedback to help us improve.