Terraform for AWS Configuration Syntax

Terraform for AWS Configuration Syntax

Hi, this is Paul, and welcome to the #4 part of my Terraform guide. Today we will discuss Terraform Configuration Syntax.

Let’s explore the workings of the Terraform working directory. Understanding the configuration syntax and the essential components within it is crucial. Terraform’s configuration syntax encompasses several fundamental elements, such as blocks, arguments, and identifiers, all built on the HashiCorp Configuration Language (HCL).

Within Terraform, mastering certain aspects is necessary, including blocks, arguments, identifiers, and comments. A high-level understanding of these components will enable us to effectively implement solutions in most Terraform scenarios.

Template

This is the basic configuration syntax for a Terraform setup. It includes various components such as the Terraform block type, block labels, and block body. This structure is straightforward and serves as a simple template for configuration.

<block type> "<block label>" "<block label>" {
  # Block body
  <identifier> = <expression> # Argument
}

Example

If we use this as a starting point and transform it into an example, you’ll notice that the block type is categorized as a resource. In Terraform, this is just one type among several other block types. Examples include provider blocks, Terraform settings blocks, input variables blocks, output values blocks, local blocks, and data sources blocks. However, only a few are mentioned here. In our upcoming lecture, we will explore these Terraform top-level blocks in greater detail. Among these, the resource block is particularly crucial. It is fundamental because it is through the resource block that the underlying infrastructure is provisioned, whether on a cloud provider or on-premise infrastructure.

resource "aws_instance" "ec2_demo" {
  ami           = "ami-38f73g8f099fd7652"
  instance_type = "t2.micro"
}

Block

resource

In the context of Terraform, resources are categorized into different types of blocks. Firstly, there are top-level blocks, which have been previously discussed. In the upcoming lecture, we will delve deeper into these, covering aspects like resources and variables, all of which pertain to Terraform-related blocks.

Additionally, there are blocks nested within other blocks, known as “block inside blocks.” An example of this is provisioners, a specific type of block in Terraform that can be defined within resources. These nested blocks, such as provisioners, exemplify the concept of a block within a block.

Furthermore, regarding specific resources like an AWS instance, there is another type of nested block called the tags block. Here, you can define multiple tags for your AWS instance, further illustrating the concept of block inside blocks. These structures are fundamental to organizing and managing configurations in Terraform.

Block Labels

“aws_instance” “ec2_demo”

The concept of block labels is essential in understanding the configuration syntax, especially when dealing with different types of blocks such as resources or variables. In the example of an AWS resource, where the block type is an AWS instance, there are typically two block labels. However, for a block type categorized as a variable, only one label is usually required. This differentiation in label count is crucial for organizing and managing the configuration effectively.

Furthermore, the syntax and structure for each block type are predefined, which necessitates familiarity with the configuration rules for each type. To grasp the full extent of how many labels are needed for each top-level block, one would benefit from writing out multiple examples for each block type. This repetitive practice helps clarify the configuration requirements and ensures a deeper understanding of the necessary labels per block type.

Arguments & Identifiers

...
  ami           = "ami-38f73g8f099fd7652"
  instance_type = "t2.micro"
...

Each resource comes equipped with arguments, which consist of resource-specific information. For example, details such as AMI (Amazon Machine Image), instance_type, and other similar attributes. The left side of each argument is known as the argument name or the identifier for the specific resource. On the right side, you have the argument value, also referred to as the expression.

Comments

# One line comment 1
// One line comment 2
/*
line 1
line 2
line 3
*/

In the section discussing comments within Terraform configuration files, it’s important to note that comments can be implemented in three distinct types. First, single-line comments can be denoted by either a hash # or double slashes //.

Additionally, Terraform supports multi-line comments that start with a slash and an asterisk /* … */. This format allows for spanning comments across multiple lines, such as line 1, line 2, and line 3, to provide more extensive explanations within the code.

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn

Paul Ravvich