TerraWeek Day 2

Task 🎈: Familiarize yourself with the HCL syntax used in Terraform

Learn about HCL blocks, parameters, and arguments

HCL (HashiCorp Configuration Language) is a domain-specific language (DSL) primarily used for configuring infrastructure as code (IaC). It frequently pairs with HashiCorp's Terraform, Consul, and Vault products, among others. In HCL, you use blocks, parameters, and arguments to define and configure resources or components for your infrastructure.

Blocks:-

The basic units of the HCL code are called blocks. They specify various setups or resource kinds. Blocks are defined using curly braces {} and frequently have the following structure:

block_type "block_label" {
  # Block content
}

block_type: the type of resource or configuration you are defining. For example, in Terraform, this could be "resource," "provider," "variable," etc.
"block_label": an optional label that distinguishes the block from others. It's frequently used to refer to the block in your setup.
{}: Encloses the content or configuration settings specific to the block.

The parameters and arguments that follow a block are given a scope and context by the block.

Parameters:-

Blocks have settings or attributes called parameters. They control a resource's or configuration's behavior. Block-defined parameters are key-value pairs. For example:

resource "aws_instance" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

In this example, the parameters "ami" and "instance_type" of the "aws_instance" block have the associated values given.

Arguments:-

Arguments are the values that are assigned to parameters inside of a block. They offer detailed configuration information for a resource or component. "ami-0c55b159cbfafe1f0" and "t2.micro" are the arguments supplied to the "ami" and "instance_type" parameters, respectively, in the sample above.

To make your setups dynamic, you can utilize expressions and variables in the arguments. Variables can be used, for example, to increase the flexibility and reuse of infrastructure code.

Here's a simple example combining blocks, parameters, and arguments in Terraform:

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

In this code:

provider is a block defining an AWS provider with the "region" parameter set to "us-east-1."
resource is a block defining an AWS EC2 instance with "ami" and "instance_type" parameters set to specific values.
Explore the different types of resources and data sources available in Terraform

Terraform is a well-known infrastructure as code (IaC) platform that enables declarative definition, provisioning, and management of infrastructure resources. The two major sorts of objects you work with in Terraform are resources and data sources. These items stand for different parts of the infrastructure and information sources. Let's investigate each type:

Resources:

Resources in Terraform stand for infrastructure parts you want to add, remove, or change. The resource block is used to specify resources, which correspond to specific types of resources made available by different providers (such as AWS, Azure, Google Cloud, etc.). An overview for defining a resource is provided below:

resource "provider_type" "resource_name" {
  # Configuration parameters for the resource
}

provider_type: Specifies the type of resource, such as "aws_instance" for an AWS EC2 instance.
resource_name: An optional name for the resource, which allows you to reference it elsewhere in your configuration.

Below are some common types of resources in Terraform:

Compute Resources:
- aws_instance: Represents an EC2 instance in AWS.
- google_compute_instance: Represents a Google Cloud Compute Engine instance.
- azurerm_virtual_machine: Represents an Azure Virtual Machine.
Networking Resources:
- aws_vpc: Defines a Virtual Private Cloud (VPC) in AWS.
- google_compute_network: Defines a network in Google Cloud.
- azurerm_virtual_network: Defines a virtual network in Azure.
Database Resources:
- aws_db_instance: Represents a database instance in AWS RDS.
- google_sql_database_instance: Represents a Google Cloud SQL database instance.
- azurerm_sql_server: Represents an Azure SQL Database server.
Storage Resources:
- aws_s3_bucket: Defines an S3 bucket in AWS.
- google_storage_bucket: Defines a Google Cloud Storage bucket.
- azurerm_storage_container: Defines a storage container in Azure.
Load Balancer Resources:
- aws_lb: Represents a load balancer in AWS.
- google_compute_http_health_check: Defines an HTTP health check in Google Cloud.
- azurerm_lb: Represents a load balancer in Azure.
Security Resources:
- aws_security_group: Defines a security group in AWS.
- google_compute_firewall: Defines a firewall rule in Google Cloud.
- azurerm_network_security_group: Defines a network security group in Azure.
Infrastructure Resources:
- terraform_remote_state: Allows you to reference outputs from other Terraform states.
- random_password: Generates a random password.
Data Sources:

Data sources in Terraform give details on resources or configurations that are already in use or that are not part of the current Terraform setup. They are normally read-only and are defined using the data block. Following is the format for defining a data source:

data "provider_type" "data_source_name" {
  # Configuration parameters for the data source
}

provider_type: Specifies the type of data source, such as "aws_subnet" to retrieve information about an AWS subnet.
data_source_name: An optional name for the data source, which allows you to reference it elsewhere in your configuration.

Data sources are frequently used to obtain properties or metadata from already-existing infrastructure components, which can subsequently be utilized in other sections of your Terraform setup. Examples of data sources are:

aws_subnet: Retrieves information about an AWS subnet.
google_compute_network: Retrieves details about a Google Cloud network.
azurerm_virtual_machine: Retrieves information about an Azure Virtual Machine.

Task 🎈🎈: Understand variables, data types, and expressions in HCL

Create a variable.tf file and define a variable
To create a variable.tf file in Terraform and define a variable, follow these steps:

Create a new file in your Terraform project directory and name it variables.tf.
Open the variables.tf file in a text editor of your choice.
Define a variable using the variable block. You can give your variable a name and specify its type and an optional default value. Here's an example of defining a variable named "instance_type" with a default value:

variable "instance_type" {
  type    = string
  default = "t2.micro"
}

In this example:

Variable: Indicates that you are defining a variable.
"instance_type": The name of the variable. You can choose any name you like.
type: Specifies the data type of the variable. In this case, it's set to string, indicating that the variable will hold a string value.
default: Provides an optional default value for the variable. If you don't specify a value when using the variable in your configuration, it will default to "t2.micro."

Save the variables. tf file.

Now you've defined a variable named "instance_type" that can be used in your Terraform configuration files (e.g., main.tf) to make your configuration more flexible and customizable. You can use this variable to control the instance type for resources like AWS EC2 instances or Google Cloud Compute Engine instances, allowing you to easily change the instance type as needed without modifying your main configuration.

Use the variable in a main.tf file to create a "local_file" resource

To use the variable defined in the variables.tf file in your main.tf file to create a "local_file" resource, you can follow these steps:

you have already defined the "instance_type" variable in your variables.tf file as described earlier, here's how you can use it:

Create or open your main.tf file in the same Terraform project directory.
Define the "local_file" resource in your main.tf file, and use the "instance_type" variable as part of the resource's configuration. In this example, we'll create a local text file with the instance type as part of the file content:

resource "local_file" "instance_type_file" {
  filename = "instance_type.txt"
  content  = var.instance_type
}

In this code:

resource "local_file" "instance_type_file": Defines a "local_file" resource with the name "instance_type_file."
filename = "instance_type.txt": Specifies the name of the file that will be created. Change this to the desired filename.
content = var.instance_type: Uses the "instance_type" variable as the content of the local file. The value of the variable will be written to the file.

Save your main.tf file.

Now, when you apply your Terraform configuration using terraform apply, it will create a local text file named "instance_type.txt" in the same directory with the content set to the value of the "instance_type" variable, which you can use to customize the file content by changing the value of the variable in your variables.tf file.

Task 🎈🎈🎈: Practice writing Terraform configurations using HCL syntax

Add required_providers to your configuration, such as Docker or AWS

In Terraform 0.13 and later versions, you can specify required providers in your configuration using the required_providers block. This block allows you to declare the providers you depend on and specify their versions. Here's how you can add a required provider, such as AWS:

Open or create your main.tf file in your Terraform project directory.
Add a required_providers block at the top of your main.tf file. Inside this block, specify the provider name and the version you want to use. For AWS, it would look like this:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = ">= 3.0.0"
    }
  }
}

In this example:

aws: The name of the provider you are specifying.
source: The source of the provider, which is in the format hashicorp/provider-name. For AWS, it's "hashicorp/aws."
version: The version constraint for the provider. In this case, we specify ">= 3.0.0," which means any version equal to or greater than 3.0.0 is acceptable.

Now, you can use AWS resources in your Terraform configuration, and Terraform will automatically download the specified provider version when you initialize your project using terraform init.

For example, you can define an AWS EC2 instance like this:

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  # Additional configuration for your EC2 instance
}

Save your main.tf file.
After adding the required provider configuration to your main.tf file, run the following command in your project directory to initialize your project:

terraform init

This command will download the specified version of the AWS provider and any other necessary dependencies.

Now, you can continue defining and managing AWS resources in your Terraform configuration with the assurance that the required provider is properly configured and available for use.

Test your configuration using the Terraform CLI and make any necessary adjustments

To test your Terraform configuration using the Terraform CLI and make any necessary adjustments, follow these steps:

Open a terminal or command prompt.
Navigate to the directory where your Terraform configuration files (main.tf and variables.tf) are located.
Run the following command to initialize your Terraform project:
```
 terraform init
```
This command will download the required provider (AWS, in this case) and initialize your project with the necessary dependencies.
After successful initialization, you can use the terraform plan command to perform a dry run of your configuration to see what changes Terraform will make without actually applying them:
```
 terraform plan
```
Review the output to ensure that your configuration is correct and that Terraform intends to create, update, or delete the resources as expected.
If everything looks good in the plan, you can apply the configuration changes to your infrastructure by running:
```
 terraform apply
```
Terraform will show a summary of the changes it will make and prompt you to confirm by typing "yes" or "no." Type "yes" to apply the changes.
Terraform will then create or modify the resources as specified in your configuration. It will provide a summary of the changes made once it's finished.
If you see any issues during the terraform plan or terraform apply steps, Terraform will provide error messages and suggestions for resolving them. Common issues may include incorrect configuration settings, missing dependencies, or network-related problems.
After applying your configuration, you can use the terraform destroy command to tear down the resources created by Terraform when you no longer need them:
```
 terraform destroy
```
Terraform will show a summary of the changes it will make to destroy the resources and prompt you to confirm the destruction by typing "yes" or "no." Type "yes" to proceed with the destruction.
To make sure you are utilizing the most recent and ideal configurations, consult the Terraform guide for AWS (or your particular provider).

You may successfully test and deploy your infrastructure as code while verifying that your configurations are accurate and satisfy your needs by following these instructions and modifying your Terraform setup as necessary.

Happy Learning

Thanks For Reading! :)

-Sriparthu💝

TerraWeek Day 2

Table of contents

Task 🎈: Familiarize yourself with the HCL syntax used in Terraform

Learn about HCL blocks, parameters, and arguments

Explore the different types of resources and data sources available in Terraform

Task 🎈🎈: Understand variables, data types, and expressions in HCL

Create a variable.tf file and define a variable

Use the variable in a main.tf file to create a "local_file" resource

Task 🎈🎈🎈: Practice writing Terraform configurations using HCL syntax

Add required_providers to your configuration, such as Docker or AWS

Test your configuration using the Terraform CLI and make any necessary adjustments