Forem: Daniel Huerta

Terraform Associate Certification: Conditional Expression & Local values

Daniel Huerta — Tue, 24 Aug 2021 16:02:09 +0000

Conditional Expression

If you have programmed in other languages such as C or Javascript you may know the ternary operator. Well, in Terraform you can use it as well and it is nothing but a conditional expression that uses the value of a bool expression to select one of two values.

The syntax of it is as follows:

condition ? True_value : False_value

If condition is true, then the returned value will be True_value, otherwise will be False_value.

Let's see an example of this:

In this case, the amount of aws_instances will be created according to the value of the bool variable named istest. As you can see in the image, this value is set to false so only one aws_instance.prod will be created 😉.

Local Values

A local value assigns a name to an expression, allowing it to be used multiple times within a module without repeating it.
Let's see an example to understand this better, in the next image you will see that I created a set of tags within a locals block.

I'm using these tags inside two different resource blocks but I'm not typing every tag on it, that's the advantage of the local values.

Local values support for expression

Local values can be used for multiple different use-cases like having a conditional expression.

Use local values only in moderation, in situations where a single value or result is used in many places and that value is likely to be changed in future.

Terraform Associate Certification: Count & Count index

Daniel Huerta — Mon, 23 Aug 2021 20:30:28 +0000

Let's assume, you need to create two EC2 instances in AWS. One of the common approaches is to define two separate resource blocks for aws_instance such as follows:

Two EC2 instances is not a real problem, but what if we need to create more than that, maybe 10 instances?! 😖 It doesn't seem to be really cool right?

Well, in Terraform there is something named Count Parameter and it can simplify configurations and let you scale resources by simply incrementing a number.

Count parameter

With it, we can simply specify the count value and the resource can be scaled accordingly, for example, let's create 3 EC2 instances with this parameter:

The instances will be ordered as a list, we will be able to access to them using the position of it, for example instance-1[0].

Count index

In resource blocks where count is set, an additional count object is available in expressions, so you can modify the configuration of each instance.

This object has one attribute:

Count index: the distinct index number (starting with 0) corresponding to this instance.

For example:
With the below code, terraform will create 5 IAM users. But the problem is that all will have the same name:

Count.index allows to fetch the index of each iteration in the loop:

Closure

Now that you know how to scale resources using this parameter, you can combine it with other TF things such as variables.

We can take advantage of the count.index to use it in a different way:

In this example we are setting the name of each IAM user according to the position of the variable named elb_names.

Any comments are welcome, remember we are here to help each other 😃💙.

Terraform Associate Certification: Variables

Daniel Huerta — Mon, 23 Aug 2021 17:51:35 +0000

When using Infrastructure as Code there can be situations in which we need to use the same value multiple times and in different locations, but what if our configuration has changed and we need to modify that value. It can be a little tedious to do, depending upon the number of times that value appears.

Well, in that situations we can use variables to have a central source from which we can import the values from 😎.

How to use them

To use variables we have to create a file in which we will place them. As standard, the file must be named variables.tf.
In that file we need to specify the name of the variable, type (optional) and the default value (in case another value is not specified, TF will take the default one).

The syntax is as follows:

Once we have declared and defined our variable, we can use it with the next syntax:

We just need to type var. followed by the name of the variable, in this case instance_type.

Multiple approaches to Variable assignment

Variables in Terraform can be assigned values in multiple ways, some of these include:

1. Default Variables

If we have a file named variables.tf with the variables defined and a default value within it, Terraform will take it in the execution as we did it in the previous example.

If there is not a default value set to that file, when we run Terraform plan it will prompt to us to set a value to the variable.

2. From a file

As best practices, it is recommended to have two files to use variables:

Variables.tf: in which we need to declare the variables, type and the default value
Terraform.tfvars: in which we just need to set the value to the variable

So for instance, we can have something like this:

It is important to mention that the terraform.tfvars file must not be included in a repository, so it has to be added in a .gitignore file.

Also, this file must be named as this, otherwise we need to specify the name of the file in the CLI:

terraform plan -var-file="custom.tfvars

3. Command line flags

If not explicit value is specified in the terraform.tfvars file, it will take the default one.
We can specify an specific value to variable using something like this in the CLI:

terraform plan -var="var_name=new_value"

4. Environment variables

In case you don't have a terraform.tfvars defined but you have a variables.tf, we can set the value of the variable using environment variables, we just need to export them with the next structure:

export TF_VAR_name-of-the-variable=value-of-the-variable

And when we execute a terraform plan for example, TF will take the value of the exported variable.

Variables data types

The type argument in a variable block allows us to restrict the type of value that will be accepted as the value for a variable.

If no type constraint is set then a value of any type is accepted.

Data types:

String: sequence of unicode characters representing some text
Number
Collection types: allows group multiple values of the same type into a single value. The element type is specified as argument:
- list(...): sequential list of values identified by their position starting with 0, for example ["hello", "world"] in the case of a list(string).
- map(...): a group of values identified by named labels like {name = "Dan", lastname = "Hdz"} in the case of map(string).
Structural types: allows group multiple values of distinct type into a single value:
- Object(...): a group of values identified by a key name, it is necessary to specify a schema as argument to indicate the type of values that it is going to store like: object({name=string, age=number}) and it will match a value with the same structure such as {name = "Karla", age = 24}
- Tuple(...): A sequence of values. The schema for this must be like tuple ([string, number, bool]) and a value will match if follows that structure such as ["Mike", 23, true]

Data from maps and list variables

There can be situations in which we have variables defined as map or list and we just need one of those values inside of them.
For example, suppose the next scenario:

In this case, the instance type is going to take the corresponding value for the "us-west-2" key (t2.nano).
If we will use a variable type as List, we have to select the position of the element we want like: instance_type = var.list[0]

Closure

Now you are able to use variables in your Terraform configuration files, remember that are different ways to use them, you'll choose which to use depending of the situation 😉.

Terraform Associate Certification: Terraform Import

Daniel Huerta — Mon, 19 Jul 2021 18:25:08 +0000

Even when we are using an Infrastructure as Code tool such as Terraform can be a member of a team (including us 😅) that will ignore all this workflow and will create manually some resources directly in the cloud provider. It is unnecessary to say that it can be a really headache for the team, mainly because all the required changes for that resource need to be manually as well and ... that's why Terraform exists!! 🤯.

So, in this scenario there's a solution in TF and it is the import command 😎.

Terraform Import

This is a simple command that will help us in this tricky situations, it is going to (as its name says) import existing infrastructure to be managed by Terraform from now on.

But be careful, there is an important thing to mention here, Terraform will not create the configuration file of the resource that was created manually.

Because of this, it is necessary to first write manually a resource configuration block for the resource (with the same properties as the one that is already created), to which the imported object will be linked.

So let's do an example with an AWS EC2 instance:

Create a file with the provider configuration (in this case AWS).
Create a file in which we need to configure the resource that is already created in the Cloud with the same properties.
Run terraform import

EC2 instance manually

Let's start creating the EC2 instance manually with some basic configuration.

Here it is important to review all the important properties that this resource has because they need to be the same as the ones that we are goin to set in Terraform to be able to match both resources.

Creating configuration file

See that just some attributes are required to mapped both resources:

Once we have created the configuration file for the resources let's run:

terraform import aws_instance.myec2 i-0c598199bf2771676

Change the name of the resources and the id according to yours.

Now the resource that was created manually has been mapped to the local one that we set with Terraform, it means that if we change something in the file, the change will be reflected in AWS.

Let's change the Name tag from manual to manual2:

Even when we run the plan command we can see that any resource will be created but just modified (it means that there's already an existing created resource with that configuration).

terraform plan

terraform apply -auto-approve

Then, we can see that the changes were reflected in AWS:

Now we can manage that resource using Terraform 😉.

Closure

The import command is very useful, these situations where a resource is created manually occurs very frequently 😅 fortunately exists this solution so don't hesitate to use it when it happens to you.

Oh! And just one last thing, Terraform will include the feature of creating the configuration file when we run the import command in future releases, so this tricky part will be just for a few moment 😉💙.

Terraform Associate Certification: Remote Backend

Daniel Huerta — Fri, 16 Jul 2021 21:22:15 +0000

In the previous post we talked about how does Terraform manages the resources in the cloud using the local state file, however in the real world we will have to collaborate with other members of the team, it is to say that not only one person is going to modify the Terraform files.

In this scenario, does the entire team have to modify the local state file manually in their machine to be all synchronized? 🤔.

Well, it does not sound so practical. When we work in a collaborative workflow it is necessary to use a remote backend which is the same as a remote state file.

Remote Backend

The Remote Backend is the resource in Terraform that will allows us to store the state file in a remote location, not locally as it occurs in TF by default.

Doing this, all the team members that are working with the Terraform files will be able to do it in a synchronized way, there will be a unique shared state file for the project placed in a remote location which can be an AWS S3 Bucket, Consul, AzureRM, etc. In this post we are going to use an AWS S3 Bucket as our remote backend.

S3 Backend

If any backend is specified in the code, the state will be stored locally. Keeping that in mind, let's define our first remote backend 👨🏽‍💻.

To keep our code in a good structure, we need to create a file named backend.tf (you can name it as whatever you want, it is just to follow the standard). Inside of it we are going to use the next code and then configure it with the command terraform init in the terminal:

Note that the AWS S3 Bucket needs to be created in the cloud before running "terraform init", otherwise it will show an error because there will not be a bucket to store the remote state file.

Once the code has been applied, you will see that inside of the .terraform folder there is a terraform.tfstate file. However, the information about the created resources are not stored there, it only specifies that the backend is an S3 Bucket.

State Locking

Now we are able to work in the same Terraform infrastructure file in a collaborative way, however, what if while I'm modifying a specific resource in the code, another member of the team modify the same part as well? What changes are the ones that will remain? 😣.

This is a common problem when a team works in the same code, the solution of it is the state locking. As its name says, it is going to block the state during the applying operations such as terraform plan or terraform apply.

Once we have added the state locking (which is also included by default when we use the local state but not in a remote backend) if a user is running a terraform apply command for example, and another one tries to do it as well at the same time, TF will show him an error specifying that the state is currently locked by the changes of a different user, avoiding inconveniences in the code.

To create the state locking with the S3 Bucket, it is necessary to create a DynamoDB and add LockID as primary key:

Now, let's specify to the backend that we are going to use a DynamoDB for our State Locking. It is very simple, we just need to add the dynamodb_table tag:

To apply this configuration let's run the command terraform init.

Now we can work with the TF files within the team with the best practices 😉.

Closure

This topic can be a little tricky to understand, mainly because there are many resources that can be used as Remote Backends, however, you don't have to be an expert implementing all of them. In my case, AWS is the CP that I mostly use, that's why I'm using its resources with Terraform.

If you have any doubt or comments about it let's discuss it, remember we are here to help each other 😉💙.

Terraform Associate Certification: State file

Daniel Huerta — Mon, 12 Jul 2021 19:41:25 +0000

If you have started using Terraform as your Infrastructure as Code tool you might wonder how does TF know which resources need to be created, deleted, or modified when you run your code. Well, let me tell you that it is not a magic stuff, the agent behind this is the state file 😉.

Terraform apply

Every time we deploy our Infrastructure with terraform apply, a file named terraform.tfstate is created, it includes all the information about the resources that are currently deployed in the cloud.

You can navigate on it and you will see a key with the name of resources, it is an array which lists all the elements that were created with the configuration file (after doing terraform apply).

If you create an EC2 instance in AWS, your tfstate file will look like this:

To understand better how this works, it is important to talk about the Current and Desired State

Current State

The terraform.tfstate file is the responsible to store the current state of the infrastructure, it is to say all the information about the resources that are currently deployed in your Cloud Provider (after the terraform apply command has been run).

Desired State

All the code that is set in the main.tf file corresponds to the desired state, on it you specify what resources you expect to be created in the Cloud, and here is where the magic occurs 😉.

Terraform is going to compare both states (current and desired one), if there is an existing difference between both, it will make the changes that are necessary so that the current state is equal to the desired state.
TF shows the result of the comparison when we execute the terraform plan command in the terminal.

Refreshing the state

But, what if we modify a resource directly in the Cloud Provider interface not using Terraform apply (AWS Console for instance), let's say that we changed the EC2 instance type from t2.micro to t2.large, how is our local terraform.tfstate be modified to match with those remote changes? 🤔.

Well, Terraform has the solution for that. We just need to run the command terraform refresh and all the configuration that is currently running in the cloud provider will be updated in the local terraform.tfstate file.

Closure

Now that you understand the state concepts in Terraform, we can start talking about how to manage it in a collaborative workflow, let's talk about the remote state in a different post.

Thanks for reading, any comments or suggestions are welcome. We are here to help each other 😉💙.