Terraform Part - 3

Hey learners, in the last two articles, we’ve learnt What Terraform is, IaC, and other terminologies of the terraform, implemented few of them as well. In this, third article we are going to learn few other concepts of the Terraform. They are:

• Declarative and Imperative Scripts

• Infrastructure Lifecycle

• Local Exec

• Remote Exec

• Variables

Declarative vs Imperative Scripts:

• There is a small difference between these two but it effect a lot. I’ll explain you in simple way. Just like in the last article, we have implemented the script in which we have created VPC , EC2 Instance using Terraform.

• If you remember, after creating the VPC, We have created an EC2 Instance . While running the script again after that, we get our instance ready.

• But have you thought that “is that VPC got created for the second time?”

• Because you are running it again, it may create the resources again which we’ve created.

• Not exactly, right! We got to see the resources as result on console as we’ve defined the count.

• We defined a single VPC, a single EC2 Instance, right? We get end up no matter how many times we run the configuration again. It comes under Declarative.

• But, when it comes to imperative it gonna repeat the count of the resource as many times we run the configuration file.

• Just like, If you’ve got two VPCs and one EC2 Instance when running the file for the second time to create an EC2 Instance. It is Imperative.

• In Declarative, we write the scripts in explicitly, means we get what we define. We can expect zero chance of misconfiguration. It is similar to JSON, YAML, XML and HCL

• In Imperative, we just define what we want, everything rest is filled in, we could end up in misconfiguration, and does more than the declarative and uses programming languages like AWS CDK , Pulumi

• Even though Terraform is an declarative, it’s features are similar to the functionalities of imperative.

• In Declarative, we have limited sources to define our infrastructure but when it comes to imperative, we have multiple features which could lead to misconfiguration.

HCL Language is in between Declarative and imperative, that’s why most of the people call it as Declarative +

Infrastructure Lifecycle:

As a DevOps Engineer, we clearly define and distinct work phases which are used to Plan, Design, Build, Test, Deliver, Maintain and Retire cloud infrastructure.

• As we work in an organization, we should maintain the infrastructure reliably.

• It is Idempotent, which means no matter how many times we run the script, we end up with the same state.

• Using Terraform we can maintain the Consistency, Repeatable and predictable.

• With this we can manage the code with mutation with minimal changes. And also sensibility, we take care of our reputation by considering dependencies on infrastructure.

• These are commands which we've used to create our infrastructure and also to destroy it. If you haven't done yet, I recommend you to read the last tutorial

Infrastructure Drift:

Stating the differences between the desired state of our infrastructure which defined vs actually it is now currently. This often occurs in dynamic and complex IT environment when changes are made to infrastructure such as updates, patches, configuration adjustments or manual adjustments, this could lead to Breach.

In cloud we can detect the Infrastructure Drift using services like...

We can prevent this drift by,

• using Immutable infrastructure

• making servers not modified after the deployment or

• using GitOps to version control our IaC and peer review every changes, every single pull request that could change to Infrastructure

Local Exec

• Provisioners allows you to run virtually any any command that you might run in your terminal or command prompt that yo execute your commands.

• This could include simple command like copying files, creating directories or more scripts that perform a series of action.

• Mostly these commands allow us to execute arbitrary commands on your local machine during the provision or destruction resources.

• As we’ve seen in the previous article, provisioners run on the machine where terraform is executed not on the target infrastructure.

Remote Exec

• When it comes to Remote Exec, we write few commands which should be executed on the machine after creating it.

• For example, as we’ve created the EC2 Instance, suppose we have to update it or install any software in it, we are going to write the module as

File Provisioners:

To copy files or directories from our local machine to the newly created resource.

So that we can easily copy the files into the EC2 Instance.

• To perform this, we require a Connection block for authentication, which set up the connection and we use SSH for this.

Variables

Do you know any programming language? If you’re answer is yes, then you are going to relate to this in no time. Variables are just like the containers in which you store the data you want to store some data, so that you can use that variable’s name instead of using the variable’s value.

• Variables are defined via variable blocks. We use a separate file as well named as .tfvars

• By default, terraform.tfvars will be autoloaded when included in the root of our project directory.

• We can also specify the variables in CI CD build servers as environment variables.

• Not just a single, we can create multiple variable files, but to load those files into the main.tf file, we have to use the extension as my_tfvars.auto.vars by which it can be automatically autoloaded into the main.tf file.

Environment Variables

• Instead of using the direct value of it, we can specify just like mentioned in this code.

The precedence of these variables are as follows:

1. Environment Variables

2. terraform.tfvars

3. terraform.tfvars.json

4. *.auto.tfvars or .json

5. -var & -var-file

Output Values

These are the values which we get after running the terraform configuration file which we've written during the lifecycle of it. These outputs can be about getting an IP Address an an EC2 Instance, SSH Key value, etc.

We can also get these outputs as a file, which we can use it futher to verifiy with the state file via terraform_remote_state, Basically it gonna print everything in the state file.

Commands can be used for getting output as

1. terraform output

2. terraform output -json

3. curl $(terraform output -raw lb-url

Local Values

Basically, it works as methods in programming language. We define few values in the file, and we call them whenever we require it. We can use it multiple times, by defining it for once. Let me explain you clearly with this example...

locals {
    service_name = " "
    owner = " Operations_Team"
    }
# We  can use them anywhere as
locals {
    common_tags = {
        service = local.service_name
        owner = local.owner
        }
    }

• Once it is declared, we can reference it using local.common_tags

Don't worry, we will perform this example in tomorrow's article, where we focus on implementation of these concepts in our Configuration file.

We are done with this article, in the upcoming article we are going to implement what we've learnt in this one. Please comment if you have any quiries on this, and please follow to not to miss the upcoming article.