AWS — Infrastructure as Code Tutorial — Step 1.2 — Terraform
Note: all steps are in the GitHub repository
“Terraform allows operators to use HCL to author files containing definitions of their desired resources on almost any provider (AWS, GCP, GitHub, Docker, etc) and automates the creation of those resources at the time of apply.”
In case you have not yet installed Terraform, please check installation section.
I am putting Terraform binary one level up from the project folder. My projects (folders) are in terraform-projects folder. My first project is going to be located in folder vpc. Terraform binary is in terraform-projects folder.
I created file vpc.tf in vpc folder
Here is structure
Some rules about Terrafom language (HCL) syntax and files. (See more, following this link)
- Terraform configuration file- which is called a module — needs to have .tf extension
- Terraform is using its own configuration language — HCL. While it is possible to use json format also — we will use Terraform’s own language.
- Text and image bellow are from the link above.
- Blocks are containers for other content and usually represent the configuration of some kind of object, like a resource. Blocks have a block type, can have zero or more labels, and have a body that contains any number of arguments and nested blocks. Most of Terraform’s features are controlled by top-level blocks in a configuration file.
- Arguments assign a value to a name. They appear within blocks.
- Expressions represent a value, either literally or by referencing and combining other values. They appear as values for arguments, or within other expressions.
Here is our first configuration — (with errors — again)
Let us understand what is here:
- Resources — remember, just like in CloudFormation template, it is the only required section.
- Just like in CloudFormation template resource AWS::EC2::VPC — the resource we want to create — “aws_vpc”
Let us compare CloudFormation Template and Terraform Configuration file
Section Resources in CloudFormation template -> resource in Terraform
Resource AWS::EC2::VPC -> aws_vpc
Terrarorm is a universal tool, so we need to let Terraform know, what and where we are going to deploy our resources.
How did Terraform detect we were deploying to AWS?
You know the answer , right? It is the “aws_vpc” in the block.
Strictly saying, we need to explicitly state provider, but we will talk about that later.
This is what happened:
- Terraform detected we were deploying to AWS.
- Terraform downloaded the provider binary (plugin).
- Terraform downloaded selections.json, which contains a hash value that is used to test the binary integrity.
Moving on …
Remember from CloudFormation chapter, that it is good idea to validate the template? Terraform has a validate command:
Hm, well, it is ok — we can add a region, but what about VPC CidrBlock — we know it is wrong, as it is must be between /16 and /28.
Well, actually, there is another command that does that:
Let us correct typo, and rerun ../terraform plan
The screenshot continues:
The command not only does the validation on incorrect values, but also asks you to input missing values.
Recommendation: Always use both commands for validation
In addition, terraform plan can generate plan file, which can be used in apply switch.
Note from HashiCorp:
Saved plan files (with the
-outflag) encode the configuration, state, diff, and variables. Variables are often used to store secrets. Therefore, the plan file can potentially store secrets.
Running “terraform apply”
Enter region name and answer “yes”:
Validating resource creation — “terraform show”
Deleting resource — terraform destroy
We have learnt:
- Several details about Terraform language: HCL syntax and structure. Read more about HCL
- How Terraform detects where we want to deploy resources and that it downloads the corresponding provider plugin. We checked afterwards which files were downloaded and what are they used for.
- How Terraform does validation of configuration file syntax.
- How Terraform deploys (applies), lists and destroys configuration.