Building A 2 Tier Architecture With Terraform

Welcome back! Today’s tutorial we are continuing our journey with Terraform. We will be going step by step to add a 2-tier architecture. In a previous project we created a 3-tier architecture, using AWS, which handled the web tier, architecture tier, and the database tier. In this tutorial we will be working with creating our web tier and database tier. The great thing about Terraform is, instead of creating each component individually, we will running our codes in our files to complete this.

Objective:

1. Create a highly available two-tier AWS architecture containing the following:
2. Custom VPC with:
3. 2 Public Subnets for the Web Server Tier
4. 2 Private Subnets for the RDS Tier
5. Appropriate route tables
6. Launch an EC2 Instance with your choice of webserver in each public web tier subnet (Apache).
7. One RDS MySQL Instance (micro) in the private RDS subnets
8. Security Groups properly configured for needed resources ( web servers, RDS)
9. Deploy this using Terraform Cloud as a CI/CD tool to check your build.

Prerequisite:

Terraform Knowledge

IDE of your choosing ( Cloud9)

Github Account — attached repo

Terraform Cloud Account — free

Step 1 : Creating Environment / Creating Files

In order to get started, we are going to navigate to our AWS Cloud9 to create the environment that we will be working in. Once created, we are going to want to clone the repository we created in Github. This will allow us to push the configuration files we create into the repo. Create the files that we will be working with( main.tf, provider.tf, variable.tf, apache.sh, terraform.tf).

Step 2: Building Our Main.Tf file

Creating Our Vpc:

In our first section we are going to identify the Availability Zones being worked in and the defined region. Now we are going to define the VPC. The resource block is providing us the managed resource (VPC) and recognizng the cidr block that will be attached, this will be identified in our Variable.tf file. Enable DNS support determines supports DNS resolution through the Amazon provided server, the default for this attribute is true. Dns hostname determines whether the VPC supports assigning public DNS hostnames to instances with public IP addresses. This is true unless the Vpc is default. Tagging is optional but keeps things organized.

Create 2 Public Subnets for the Web Tier

We will name the first Public subnet in the resource block. The next line we are going to the specify the Vpc the subnets belong to. Followed by identifying the Cidr block for the subnet. Our next lines are going to get a list of all the Availabilty zones in the current region we are working in. The Tolist function is used to convert that list into a regular list. The [each.value] index is then used to select a specific availability zone from the list, based on the current value of the loop variable. We will add Map_Public_Ip_on_Launch, where will specifies that instances launched in these subnets will be assigned a public IP address by default. This is required for instances in public subnets to communicate with the internet. Repeat this instruction for our second Public subnet and use a different Cidr block.

Create 2 Private Subnets for the Database Tier

We are going use a similar format from our Public Subnets. We will exclude the Map_Public_Ip_on_Launch since the instances in these subnets are not going to be internet facing.

Create Route Tables and More

In our first block we are going to create a route table that points to the Public subnets. We will specify the Vpc the route table belongs to and route it to the internet gateway we will create in another step and attach the Cidr_block. Tagging optional for organization. Repeat the same instruction for the Private subnet, besides we will not be using the Internet gateway , we will be using the NAT gateway. This used to associate a fixed Public IP address. The Nat gateway acts as a “middleman” by forwarding traffic from the private subnet to the internet via the EIP. Now we will create our route table associations for the subnets we created, where we are going to specify the subnet and the corresponding route table.

Here we will create our Internet gateway and attach the Vpc it belongs to and of course name it. Now to create the EIP for the NAT gateway. Using the EIP for the NAT gateway, you can ensure the public IP address used by the NAT gateway does not change, which will maintain the security and stability of the network. Creating the NAT gateway, we want to associate the Elastic IP we just created and associate one of the Public subnets. At this point I ran and applied my plan so far to ensure everything works.

Create Our Security Groups:

Like other projects, we are going to create a Security that allows traffic to SSH(80) HTTPD(443) and HTTP (20) , this will allow us to connect to the internet and to our instance we are about to create.

Create Web Tier Instance :

Like in the AWS console, we want to attach our AMI, instance type, the key name and the subnet we created, security group created and attach the Apache install file we created in Apache.sh. The AMI and Keyname are named in our Variable.tf file. Repeat these configurations for our second instance, besides changing the name. Here I ran the configurations again to ensure it works.

Create a Security Groups for the RDS instance :

Here we are going to create our security group that allows to the RDS instance we are going to create, by allowing traffic to Port 3306.

Create the Rds Database Instance :

We created our Ec2 instance and now we are going to want to create our Database instance . The Engine is specifying the database engine for the instance type. The version will be “Db.2t.micro” which determines the memory capacity of the instance. Allocated storage is identifying the amount of storage in the Database in gigabytes. Our next couple lines for username and password, we are keeping default. Now to associate our Security groups. Next we will specify the name of the DB subnet group to be used for the instance. Pubicly accessibles = true, indicates the instance is publicly accessible. Now create the Subnet group resource and attach the Private subnets we created. Now i held off running this part for our next step.

Step 3 : Deploy this using Terraform Cloud as a CI/CD tool to check your build.

We are going to move over to the Terraform Cloud to create a workspace where we’ll be able to run this. We will start creating a new account(Link) and be brought to Create a New Workspace, you want to choose “CLI driven-workflow”.

Now that you have created your Workspace , back in your Cloud9 environment you want to run the command “ terraform login” .

Now that you are logged we want to test out running our infrastucture through Terraform cloud. You will select Start New Run in the Action tab. This is going to show you everything in the Cloud, similar to Terraform Plan

Now to apply the changes !

This project was a little delayed so the time frame is different

Step 4 : Check the Work Created

Navigating to the EC2 console we are going to see the instances we created.

Using the Public Ip address we are able to check our Apache installation.

You will see that our Database instance isn't in the EC2 console, so hop over to the RDS console and you will see the instance created. We’re completed!

Now we have checked our work to ensure we are not charged for the changes we made, you want to run the Terraform Destroy command.

This project like all the ones that came before it has taught me an incredible amount. Getting comfortable with Terraform has been so rewarding at each step. The resources Terraform offers are so helpful .I hope you found this tutorial helpful and as always feedback is appreciated.