Terraform Part - 5

In the previous article, we’ve implemented remote exec, local exec, variables usage etc. In this, we are going to learn about few other concepts of the terraform by which you can change the way you write the Infrastructure as Code.

Data Sources

Suppose, you’ve defined few resources in a file, and you want to use them in a new file, instead of defining it again here you want to refer this file to that particluar definition. Here comes the data source.

• Just like a method in a programming language, but this is across the files.

• We define the data sources with keyword data

References to Named Values

In IaC we define a lot of values in order to build our infrastructure. Instead of defining them multiple times the same value, we can refer them by defining them once in a file.

They can be multiple ways,

In order to refer the files or workspaces of Terraform, we use

Resource Meta Arguments

Terraform language defines the several meta arguments which can be used with any resource type to change the behavior off resources.

Those arguments are…

depends_on:

• When we define the resources we require as code, few of them may or may not depend on each other.

• If they depend, terraform explicitly predict the dependency of the resources and work accordingly.

• But, there might be few chances where terraform may not predict the dependency of the resources on each other. That’s why we we this block to avoid confusion and get our desired output without infrastructure drift.

count:

In our practical, we just define single or two instances or resources we need multiple. We just write the same code for the second or third time to create a new resource. We may face problems like

• Increased Number of lines of code

• not developer friendly to read it, etc.

To make it simple, we use the keyword called count

• This instead of defining the same block of resource multiple times, we just use the keyword count and define how many we need.

• By that, we can make our code look precise, good to read and easy to implement and understand the code.

for_each:

It’s use case is similar to count for managing multiple related objects. But we can iterate over a map for more dynamic values.

Resource Behavior:

When we execute an execution order via terraform apply , it will perform one of the following.

1. Create: It helps in creation of resources which will actually get reflected on the infrastructure of Cloud provider instead of defining it simply on code.

2. Destroy: To destroy the resources which are actually running currently on infrastructure of cloud provider.

3. Update: We not just always define the resource, plan it, apply it we also update them accordingly. These arguments updates are like changing the Instance Type , count , etc.

4. Destroy and Create: When we update our Infrastructure as Code file (configuration file), it destroys the previously defined configuration of that particular resource and dependencies. And recreate them with the updated resource values.

Alias

Suppose, let’s imagine you’ve deployed your application on a region us-central-1 and after that you want to change the region of it, but not to change what you’ve defined the region on variable.

There, alias will comes into the picture. Alias helps us to reference it under attribute provider for a reference.

provider "google"{
        region = "us-central-`"
}
provider "google"{
        alias = "India"
        region = "ap-south-1"
}
resource "google_ci" "example"{
        provider = "google.alias" # ---> Resource using Alias
}

Lifecycle

By now, if you’re following us from the beginning you might got familiar with the lifecycle of the Terraform. Now, in this we can use resource meta arguments as

• create_before_destroy:

  • This is used when you’ve committed the changes in your code and you want to create the changed configuration file before you destroy the existing.

• This helps you to minimize the downtime

• However, this cannot be used for all resources it may lead to errors.

• prevent_destroy:

  • By setting this true , everytime you run command terraform destroy , it halts form destroying it.

  • This is valuable for protecting critical resources with sensitive data, like databases or storage accounts.

• ignore_changes:

  • This attribute instructs Terraform to ignore changes made to specific attributes of a resource outside of Terraform's management.

  • Use cases involve external processes managing certain aspects, like automatic tagging by Azure policies.

  • By specifying the attributes to ignore, Terraform avoids unnecessary attempts to "fix" them and respects the external management.

  • For more complete exclusion, the keyword all can be used to ignore all attributes, allowing only creation and destruction but no updates.

  • Be cautious when using ignore_changes, as unintended consequences can arise if crucial updates are inadvertently ignored.

This is up for today’s article. In tomorrow’s article we are going to implement this and on Saturday we are going to do a project using Terraform in which, we create a Single Tier Architecture on AWS and Azure aswell.

If you’ve any queries on these topics, you are free to use the comment section to raise them.