Let’s do a short exercise wherein we will define a VPC and spin up an EC2 instance in the AWS cloud. We can use the AWS free tier account to do it.
First, the following is the prep work that we need to do which would hardly take 10 minutes.
- Create AWS Free tier account. Visit this link
- Install AWS CLI. Refer this link
- Configure AWS CLI with access key using “aws configure” command. Refer the link
- Install Terraform if you don’t have it already. Click here
Now let’s do some terraform coding.
As we are going to do some provisioning in the AWS cloud we need to define some baseline configuration to tell Terraform about the target platform.
Create a file with the name “main.tf” and define the above-mentioned configuration in it. Please note that we’re using Terraform version 1.0.4. The configuration tells terraform the provider and its version to download from the Terraform registry.
In the provider section, we have defined the region we want to use to deploy our resources.
Let’s now define the VPC and EC2 instance in the form of HashiCorp configuration Language.
Defining VPC and its components:
In AWS, setting up your Virtual Private Cloud is one of the most essential things that you need to plan out before deploying any resources like VMs, Databases, Gateways, etc. Here our target is to deploy an EC2 instance in the cloud and for that, we would definitely require a VPC and a private or a public subnet.
Either we can use the default VPC and let AWS decide the IP addressing or we can take the matter into our own good hands and do it ourselves. The latter part always attracts me though.
Below snippets of code shows the resource block defined for VPC, Subnet, and association of the subnet with the route table.
Creation of subnet and the route table. Associate it with the relevant VPC by calling the VPC name.
Lastly, Create the association between the route table and the subnet.
Now we are set to deploy our EC2 instance in ‘Prod-VPC’.
Defining EC2:
EC2 instance in AWS refers to the VM you want to deploy in the cloud. Here we are going to deploy an Ubuntu VM into the AWS Cloud. So we’ve defined the AMI ID (ami-038e6b679579b4ec1) of the image we’re going to use to build our VM. You can refer to this link to get the AMI ID.
Other than that, the Instance type is t2.micro which is free tier eligible, and then we have associated the subnet in which our VM would be deployed.
We’re pretty much done with the code and now we need to initiate the Terraform Lifecycle stages i.e Init, Plan, and Apply.
As you see my code directory looks like this before the execution of Terraform Init.
After executing the “Terraform Init” command as shown below, it’ll download the AWS provider version in a new directory.
The new directory “.terraform” has the AWS provider version 3.54.0 downloaded from Terraform Registry and it also has created the “.terraform.lock.hcl “ file in my Staging directory.
This Lock file is used to store information about the versions of provider dependencies used. Here in our code, the dependency is on the AWS provider plugin to interact with the APIs of AWS to provision resources.
Now we’ll move towards the “plan” stage of Terraform lifecycle which will give us the changes Terraform is going to make in AWS infrastructure by executing the “Terraform Plan” command.
The above snippets show the changes that our terraform code will make. Also, do look at your directory and you’ll see the Terraform State file which would record the latest state of the AWS infrastructure.
PS: the “Plan” output is too long so I only mentioned some parts of it.
Terraform apply is our executioner and will command terraform to start interacting with the AWS APIs and execute the changes defined in the code.
As you can see in the above snippets that it has created those resources in the AWS cloud and relevant associations that we have defined.
Great work !! I hope this has been informative for you.
