The Ops Community ⚙️: Moses Itoya

Terraform Modules - A High Level Overview

Moses Itoya — Sun, 10 Jul 2022 09:10:06 +0000

Topic Introduction

IaC helps with better complexity management and a much better visibility into infrastructure configuration. Whichever IaC tool you are using, it's important to have a code that is easier to read and more understandable, especially if you are in a team environment. This would ensure your code base is properly maintained and very well-organized. All these centers around refactoring, which reduces complexity and makes future releases more efficient. For Terraform, Modules helps a lot with Refactoring of your code.

Modules are containers for multiple resources that are used together. A module consists of a collection of .tf and/or .tf.json files kept together in a directory. To package and reuse resource configuration in Terraform, you'd need to understand modules and how they work, as this is the major way. The Agenda of this article is to:

Know what modules are
Know how modules interact
Know modules best practices

NOTE: Knowledge of Terraform is needed to fully understand the contents of this article, It is assumed that you already have this Knowledge going forward.

While some who are new to terraform sometimes say Modules is a complex topic and try to avoid it, having a good understanding of it is crucial to writing codes that can be shared, easily read and reusable. Who wouldn't want that? Well, I'd say someone who don't understand how it works for sure. Let's take a brief look at what Modules really are, this insight would help going further down the somewhat intricate path of Terraform Modules.

What Are Modules

Even as a beginner to Terraform, you’ve already interacted with modules. That’s the Root module, which contains all resource configuration files ending with the .tf terraform extension in the main working directory. Modules is just simply a better way of organizing and maintaining your resources configuration for easy modifications and efficient management of your infrastructure.

For Example...

Imagine your Infrastructure code base needs several Instance resource with it's own VPC and Subnet, you can create a module with the required resource, and call it whenever you need to create such an Instance on your infrastructure. Say you need multiple of such instance, all you have to do is pass in the count, or for each meta-arguments when calling the module. Talking about Modules, there’s the Root module which we define. There’s also the child module, this is a module that is been called by the root module.

The Instance Module in the example above is an example of a child module as we would call it from the root module. Child modules can be called multiple times within the same configuration, and multiple configurations can use the same child module, either within the same configuration or in separate configurations, allowing resource configurations to be packaged and re-used. Later on in the article, we’d see how to create a module, that would also show how we call a module to include their resources into the configuration.

There's some more..

Other than the Root module and child module, there is also the Published module. Like we had the concept of backend in terraform where we can store our state locally or remotely, this is somewhat similar. Terraform has a registry where you can publish modules for others to use, and to use modules that have been published by others. This registry can either be public or private. There are lots of modules available for use today on the registry. Terraform Cloud and Terraform Enterprise both include a private module registry for sharing modules internally within your organization. Depends on what you plan to use, there’s a way to include it or reference it in your configuration, we’d take a look at this in a later part of this article.

Interacting with Modules

Now that we have a pretty detailed understanding of what modules are, let's take a look at how we can interact with it in our infrastructure configuration, i.e. calling the child module. The child module can either be sourced from

local path, i.e. for closely related modules used primarily for the purpose of refactoring out repeated code elements
Native Terraform module registry, i.e for modules intended to be shared by multiple calling configurations
Github, Bitbucket, see more modules sources here

The same source address can be specified in multiple module blocks to create multiple copies of the resources defined within, possibly with different variable values. After adding, removing, or modifying module blocks, you must re-run terraform init to allow Terraform adjust the installed modules

Our example child module block would be using a local path. To call a module means to include the contents of that module into the configuration with specific values for it's input variables. This input variables allow you tailor certain parts of Terraform modules without altering the module's own source code, therefore making your module composable and easily reusable. Take a look at this module block below:

module "Security" {
  source = "./modules/Security"
  vpc_id = module.VPC.vpc_id
}

The label immediately after the module keyword is a local name , used to refer to the instance of the module by the calling module. To be able to interact with modules you have to know the arguments for the modules. A mandatory module argument is the source which tells terraform the location of the module, be it a local path or private registry or any of the source types. There is also the version argument which is recommended for modules from a registry so terraform can know which version of the module to use. As discussed already, the input variable defined by the module is also an important argument. Meta arguments are some special constructs in Terraform which are available for Resources and Modules, along with source and version. They include:

depends on
count
for_each
provider

In the example module block above, the security module source is a local path and it uses the relative filesystem path, not an absolute path. Terraform does not consider an absolute filesystem path(the same location in a file system relative to the root directory) to be a local path as it treats it as a remote module. It's best to use a relative filesystem path(points to a specific location in a file system relative to the current working directory you are working on). The input variable there which id the vpc_id passes in a vpc_id variable from another module called VPC in the same configuration.

You can use modules in various ways but it's best to keep everything easily understandable. I'd talk more about this in the next article which would be a continuation of this article and would center around "Terraform module best practices", this is in a bid to reduce the lengthiness of this article.

Terraform Cloud As A Remote Backend

Moses Itoya — Tue, 05 Jul 2022 14:43:50 +0000

On my previous article, I gave a step by step process on using AWS S3 for terraform backend, I also talked about terraform state file and terraform lock file quite extensively.

In summary, the state file contains information about configuration and managed infrastructure. This state is used by terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructure. This state is stored by default in a local file named terraform.tfstate, but it can be stored remotely, which works better in a team environment. Read more about terraform state here

Backends are where Terraform's state snapshots are stored. There are different types of backends on Terraform, they include;

Local(which is the default)
remote(which we would look into in this article)
S3(which we've previously talked about)
Kubernetes(stores the state in a Kubernetes secret)
etcd(does not support state locking) and others.

Securing of your terraform state file is your responsibility.

We would be migrating a state of a project which has been local, remotely to terraform cloud. This is for better security, better team activity and a great UI.

Steps to migrate our state

Set Up a Terraform cloud Account - Sign up for a new account if you don't already have one - Log in and create an Organization. Give it any name you like - Create a cloud code block on main.tf. When we refactor the code, a backend.tf file would be create where the cloud code block would be moved to.
```
terraform {
cloud {
organization = "static-website"

workspaces {
  name = "static-web-dry-run"
        }
    }
}
```
NOTE: The organization must already exist on terraform cloud, the workspaces however doesn't have to as it would be created if it doesn't already
Authenticate with Terraform Cloud - Having defined your Terraform Cloud configuration, authentication with Terraform Cloud is necessary for initialization. Run terraform login - Follow the prompt and set up the API keys which would be used for authentication - You should get a successful output like this
Migrate the state file - Run terraform init so our new cloud code block configuration can be recognized
Configure the Terraform Cloud Workspace - Log into the your Terraform cloud Account

Confirm the workspace defined can be seen in the organization
Run an apply and confirm the state is there on the terraform cloud workspace

Using AWS S3 for Terraform Backend

Moses Itoya — Tue, 28 Jun 2022 20:44:29 +0000

This 3rd part of the series would be centered around migrating your terraform state file which has been stored locally so far in the project, to an AWS S3 bucket so it can be accessed remotely. This is important if you intend to work in a team environment, or even for more secured storage of your state file.

It is a very important file which terraform uses to manage, configure and store information about your infrastructure. Without the state, Terraform cannot function. Server-side encryption would be used to ensure that your state files are encrypted since the state files stores sensitive information like passwords. Tampering with this state file which terraform stores as 'terraform.tfstate' could be a nightmare, except you know exactly what you are doing.

Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state. In order words, the state lock file locks the state during a deployment such that no two terraform processes try to update the same state at the same time. So in the case where you work in a dev environment and everyone have access to the code base, no two engineers can run terraform command at the same time or while a command is already running. We'd implement this using AWS DynamoDB. State locking happens automatically on all operations that could write state. You won't see any message that it is happening. If state locking fails, Terraform will not continue.

Here is our plan to Re-initialize Terraform to use S3 backend:

Add S3 and DynamoDB resource blocks before deleting the local state file
Update terraform block to introduce backend and locking
Re-initialize terraform
Delete the local tfstate file and check the one in S3 bucket
Add outputs
terraform apply

Create backend.tf and add the following

resource "aws_s3_bucket" "terraform_state" {
bucket = "moses-dev-terraform-bucket"
# Enable versioning so we can see the full revision history of our state files
versioning {
enabled = true
      }
# Enable server-side encryption by default
server_side_encryption_configuration {
rule {
  apply_server_side_encryption_by_default {
    sse_algorithm = "AES256"
          }
      }
   }
}

Note: The bucket name may not work for you since buckets are unique globally in AWS, so you must give it a unique name. Read more about AWS S3 Bucket Naming Policies Here

Create DynamoDB table to handle locking. With a cloud storage database like DynamoDB, anyone running Terraform against the same infrastructure can use a central location to control a situation where Terraform is running at the same time from multiple different people.
```
resource "aws_dynamodb_table" "terraform_locks" {
name         = "terraform-locks"
billing_mode = "PAY_PER_REQUEST"
hash_key     = "LockID"
attribute {
name = "LockID"
type = "S"s
      }
}
```
Terraform expects that both S3 bucket and DynamoDB resources are already created before we configure the backend. So, let us run terraform apply to provision resources.

Configure S3 backend

terraform {
backend "s3" {
bucket         = "moses-dev-terraform-bucket"
key            = "global/s3/terraform.tfstate"
region         = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt        = true
      }
}

Now, Run terraform init and confirm you are OK to change the backend by typing 'yes'

Verify the changes - Checking AWS, the following will be noted: tfstatefile is now inside the S3 bucket

DynamoDB table which we create has an entry which includes state file status

Add Terraform Output
Add the following to output.tf

output "s3_bucket_arn" {
value       = aws_s3_bucket.terraform_state.arn
description = "The ARN of the S3 bucket"
    }
output "dynamodb_table_name" {
value       = aws_dynamodb_table.terraform_locks.name
description = "The name of the DynamoDB table"
}

Run terraform apply

Terraform will automatically read the latest state from the S3 bucket to determine the current state of the infrastructure. Even if another engineer has applied changes, the state file will always be up to date. Check the tfstate file in S3 and click the version tab to see the different versions of the tfstate file.

In the next part of the series, Modules would be discussed, and more some more refactoring as well.

Code from Darey.io

CREATING A COMPANY INFRASTRUCTURE IN AWS USING TERRAFORM - Part 2

Moses Itoya — Tue, 28 Jun 2022 16:29:44 +0000

This article is part 2 of a series of articles focused on building a company's infrastructure on AWS using Terraform. You can read up Part 1 where we introduced the topic, basic setup, wrote terraform code which creates our VPC and public subnets. By the end of this article, we would understand and write codes that would create the following resources:

Private Subnets
Tags
Internet Gateway and NAT Gateway
EIP and Routes Tables
Security groups
Certificate from amazon certificate manager
Autoscaling groups
Storage and database

Code from Darey.io

Networking

Private subnets & best practices

Create 4 private subnets, keep in mind following principles:

Make sure you use variables or length() function to determine the number of AZs
Use variables and cidrsubnet() function to allocate vpc_cidr for subnets
Keep variables and resources in separate files for better code structure and readability

main.tf private subnets code block:

# Create private subnets
resource "aws_subnet" "private" {
  count = var.preferred_number_of_public_subnets == null ? length(data.aws_availability_zones.available.names) : var.preferred_number_of_public_subnets 
  vpc_id                     = aws_vpc.main.id
  <!-- cidr_block                 = cidrsubnet(var.vpc_cidr, 4 , count.index) -->
  cidr_block                 = var.public_subnets[count.index]
  map_public_ip_on_launch    = true
  availability_zone          = data.aws_availability_zones.available.names[count.index]
}

variables.tf private subnets variable:

variable "preferred_number_of_private_subnets" {
  default = null
}

terraform.tfvars private subnets variable:

preferred_number_of_private_subnets = 4

Tag all the resources you have created so far. Explore how to use format() and count functions to automatically tag subnets with its respective number.

TAGS

In terraform.tfvars file, add the following:

tags = {
  Enviroment = "production"
  Owner-Email = "owner@mail.com"
  Managed-By = "Terraform"
}

In variables.tf file, add the following:

variable "tags" {
  description = "A mapping of tags to assign to all resources."
  type        = map(string)
  default     = {}
}

Now we can tag our resources with the tags we have defined in the variables.tf file like this:

tags = merge(
    var.tags,
    {
      Name = "Name of the resource"
    },
  )

Benefits of tagging with this approach: we only need to change the tags in one place (terraform.tfvars) and we can easily see what resources are tagged with what tags.

Internet Gateways & format() function

Create an Internet Gateway in a separate Terraform file internet_gateway.tf

resource "aws_internet_gateway" "ig" {
  vpc_id = aws_vpc.main.id

  tags = merge(
    var.tags,
    {
      Name = format("%s-%s!", aws_vpc.main.id,"IG")
    } 
  )
}

We used format to dynamically generate the name of the resource by using format() function.

The first part of the %s takes the interpolated value of aws_vpc.main.id while the second %sappends a literal string IG and finally an exclamation mark is added in the end.

NAT Gateways

Create 1 NAT Gateways and 1 Elastic IP (EIP) addresses

create a new file called natgateway.tf.

Note: We need to create an Elastic IP for the NAT Gateway, and you can see the use of depends_on to indicate that the Internet Gateway resource must be available before this should be created. Although Terraform does a good job to manage dependencies, but in some cases, it is good to be explicit

resource "aws_eip" "nat_eip" {
  vpc        = true
  depends_on = [aws_internet_gateway.ig]

  tags = merge(
    var.tags,
    {
      Name = format("%s-EIP", var.name)
    },
  )
}

resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat_eip.id
  subnet_id     = element(aws_subnet.public.*.id, 0)
  depends_on    = [aws_internet_gateway.ig]

  tags = merge(
    var.tags,
    {
      Name = format("%s-Nat", var.name)
    },
  )
}

We used the element() function to select the first element of the array of subnets.

element(list, index)

element(aws_subnet.public.*.id, 0)

Fetches the first element of the array of subnets.

AWS ROUTES

Create a file called route_tables.tf and use it to create routes for both public and private subnets.

Now we Create a route table for the public subnets and a route table for the private subnets.

aws_route_table
aws_route
aws_route_table_association

# create private route table
resource "aws_route_table" "private-rtb" {
  vpc_id = aws_vpc.main.id

  tags = merge(
    var.tags,
    {
      Name = format("%s-Private-Route-Table", var.name)
    },
  )
}

# associate all private subnets to the private route table
resource "aws_route_table_association" "private-subnets-assoc" {
  count          = length(aws_subnet.private[*].id)
  subnet_id      = element(aws_subnet.private[*].id, count.index)
  route_table_id = aws_route_table.private-rtb.id
}

# create route table for the public subnets
resource "aws_route_table" "public-rtb" {
  vpc_id = aws_vpc.main.id

  tags = merge(
    var.tags,
    {
      Name = format("%s-Public-Route-Table", var.name)
    },
  )
}

# create route for the public route table and attach the internet gateway
resource "aws_route" "public-rtb-route" {
  route_table_id         = aws_route_table.public-rtb.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.ig.id
}

# associate all public subnets to the public route table
resource "aws_route_table_association" "public-subnets-assoc" {
  count          = length(aws_subnet.public[*].id)
  subnet_id      = element(aws_subnet.public[*].id, count.index)
  route_table_id = aws_route_table.public-rtb.id
}

AWS Identity and Access Management

IAM and Roles

We want to pass an IAM role our EC2 instances to give them access to some specific resources, so we need to do the following:

Create AssumeRole

Assume Role uses Security Token Service (STS) API that returns a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to. These temporary credentials consist of an access key ID, a secret access key, and a security token. Typically, you use AssumeRole within your account or for cross-account access.

Add the following code to a new file named roles.tf

resource "aws_iam_role" "ec2_instance_role" {
name = "ec2_instance_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })

  tags = merge(
    var.tags,
    {
      Name = "aws assume role"
    },
  )
}

we are creating AssumeRole with AssumeRole policy. It grants to an entity, in our case it is an EC2, permissions to assume the role.

Create IAM policy for this role

resource "aws_iam_policy" "policy" {
  name        = "ec2_instance_policy"
  description = "A test policy"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "ec2:Describe*",
        ]
        Effect   = "Allow"
        Resource = "*"
      },
    ]

  })

  tags = merge(
    var.tags,
    {
      Name =  "aws assume policy"
    },
  )

}

Attach the Policy to the IAM Role

we will be attaching the policy which we created above, to the role we created in the first step.

resource "aws_iam_role_policy_attachment" "test-attach" {
    role       = aws_iam_role.ec2_instance_role.name
    policy_arn = aws_iam_policy.policy.arn
}

Create an Instance Profile and interpolate the IAM Role

resource "aws_iam_instance_profile" "ip" {
    name = "aws_instance_profile_test"
    role =  aws_iam_role.ec2_instance_role.name
}

CREATE SECURITY GROUPS

We are going to create all the security groups in a single file, then we are going to reference this security group within each resources that needs it.

I've taken a codesnap of the block of code for this resource as it's quite lengthy, this would be done for any lenghty code for the remainder of this series. I would leave a link to my repo at the end of this article should you need to look through.

Create a file called security.tf
Add the following code to the file.

NOTE: We used the aws_security_group_rule to reference another security group in a security group.

CREATE CERTIFICATE FROM AMAZON CERIFICATE MANAGER

Create cert.tf file

Create an external (Internet facing) Application Load Balancer (ALB)

Create a file called alb.tf

First of all we will create the ALB, then we create the target group and lastly we will create the listener rule.

Create an Internal (Internal) Application Load Balancer (ALB)

This follows the same set up as external ALB

Add the following Code to alb.tf

CREATING AUSTOALING GROUPS

We need to configure our ASG to be able to scale the EC2s out and in depending on the application traffic.

we need to create the launch template and the the AMI before creating the ASG. For now we will use a random AMI from AWS.

Based on our Architetecture we need for Auto Scaling Groups for bastion, nginx, wordpress and tooling, so we will create two files; asg-bastion-nginx.tf will contain Launch Template and Autoscaling group for Bastion and Nginx, then asg-wordpress-tooling.tf will contain Launch Template and Autoscaling group for wordpress and tooling

Create asg-bastion-nginx.tf and add the following

Create asg-wordpress-tooling.tf and paste the following code

STORAGE AND DATABASE

We will be creating RDS, EFS and KMS for the resources. Here

Create Elastic File System (EFS).

Create a efs.tf file: In order to create an EFS you need to create a KMS key.
Add the following code to efs.tf

Create RDS instance

Create a rds.tf file and add the following code to it.

Update variable.tf to include the variables we've used so far. The file should look like this:

Update terraform.tfvars to include the variables we've used so far. The file should look like this:

region = "us-east-1"

vpc_cidr = "172.16.0.0/16"

enable_dns_support = "true"

enable_dns_hostnames = "true"

enable_classiclink = "false"

enable_classiclink_dns_support = "false"

preferred_number_of_public_subnets = 2

preferred_number_of_private_subnets = 4

environment = "production"

ami = "ami-0b0af3577fe5e3532"

keypair = "terraform"

# Ensure to change this to your acccount number
account_no = "012345678901 "
tags = {
  Enviroment      = "production"
  Owner-Email     = "name@mail.com"
  Managed-By      = "Terraform"
  Billing-Account = "1234567890"
}

master-password = "admin12345"

master-username = "admin12345"

db_name = "Doeita-db"

Pheew! That was some long lines of codes and less story, I know I know! Well, our infrastructure is quite a complex one, so it should be expected. The code we've written so far is pretty much a large percentage of the entire code needed. Moving on, we would be introducing backend storage of our terraform state file on amazon s3 and introducing modules for refactoring and better structure of our codes.

Code From Darey.io

HERE IS A LINK TO MY GITHUB REPO FOR THIS PROJECT

Running Docker Without Sudo - EC2 server

Moses Itoya — Sun, 26 Jun 2022 09:33:09 +0000

I was quite comfortable running my docker using sudo, not that I preferred it but I really had no option until I had to run a CI/CD pipeline which throws error as a result of running the commands with sudo. By default, the docker command can only be run by the root user or by a user in the docker group, which is automatically created during Docker’s installation process. If you attempt to run the docker command without prefixing it with sudo or without being in the docker group, you’ll get an output like this:

Output
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
See 'docker run --help'.

This made me further troubleshoot to get a solution, this article is about my little experience resolving the issue, most especially if you experience this issue running docker on a server.

I ran my docker on an EC2 instance, even after following the commands necessary for me to run docker without using sudo. It turns out I had to reboot my server, and not just exit the terminal and ssh back in to the terminal as a lot of articles I came across advised. Well, that may have worked for others, but it did not for me. If it's on a local terminal, after following the process, you can close your terminal and come back in. The changes would be effected, but it's not so for servers, you have to reboot the server.

Also, I'd like to add that it is important you run docker without sudo especially in a Jenkins Job as it would throw errors as seen below.

If you want to avoid typing sudo whenever you run the docker command, add your username to the docker group. That being said, the following are steps to run Docker without sudo(I'd still like to emphasize, for EC2 servers or any other cloud provider servers,):

Add your username to the docker group:
```
sudo usermod -aG docker ${USER}
```
Apply the new group membership. In my own case, I had to reboot my ec2 server for it to take effect, my server user had no password. If your user has a password, then run su - ${USER}. You'd be prompted to enter your password, do that and the changes would take effect.
Confirm that your user is now added to the docker group by running the command groups. You should now see your user amongts the group.

That's all, you can now go ahead and run docker without sudo. This worked for me and my Jenkins job which failed worked right after the above steps

Kubernetes Cluster on aws EKS using Terraform

Moses Itoya — Sun, 26 Jun 2022 08:34:40 +0000

Quite recently, I was tasked with creating a production ready Kubernetes cluster from the ground up at Darey.io where I Learn DevOps via a Project Based Learning model. This task gave me a deep and practical insight into the technical structure and setup of Kubernetes. Though it took me a while, I was able to set it up as requested and as per documentation.

Moving forward with the knowledge gained, I decided to set up an AWS EKS Cluster which I would use for some application deployments. This next tasks would center around deployments and persisting data in k8s. However, this article is only a guide to provisioning your own AWS EKS Cluster using IaC(Terraform). It is advisable to do this first with the console if you don't already have knowledge as to how it all works.

Terraform is the IaC tool for this guide(knowledge of terraform is a prerequisite for this process), below are the steps to follow in setting up your EKS Cluster using terraform on your control machine;

Setup a controller client machine(can be an EC2 instance or your local machine)
Install Terraform, Kubectl, AWSCLI, aws-iam-authenticator
Create a folder where you'd clone the Terraform repo already provide by Hashicorp/AWS
Clone down the Github Repo into your controller client machine
cd into the folder, cd into examples dir, cd into eks-getting-started
ls to see the '.tf' files
Feel free editing to your preference, things such as Region, names, instance type for the worker nodes, version of Kubernetes among others.
Run terraform init to initialize the folder, terraform plan to see what resources would be created. 18 resources would be created in building this cluster. terraform apply to create the resources. It would take some 8-10 min for the cluster to be built and ready to go.
Now the cluster is built, you have to update the --kubeconfig with the awscli command
```
aws eks --region <region> update-kubeconfig --name <cluster-name>
```
Test that everything works by running a kubectl command(any kubectl command) to show the nodes in your cluster
```
kubectl get nodes -o wide
```

CREATING A COMPANY INFRASTRUCTURE IN AWS USING TERRAFORM - Part 1

Moses Itoya — Wed, 01 Jun 2022 14:07:54 +0000

This article is part of a series of articles focused on building a company's infrastructure on AWS using Terraform, all of which(and more) I learnt on the Darey.io platform. The Darey.io platform adopts a project based learning style which has proven very effective in development, growth and career success evident in a lot of DevOps Engineers who have passed through the DevOps program on the platform.

The said company we would create an infrastructure for on this series needs a WordPress solution for its developers and a tooling solution for it's DevOps engineers. This would all be in a private network. Part 1 centers on basic intro, VPC and subnets creation. I'd be taking you through the processes involved, should you want to create same or similar infrastructure, while also learning and improving on terraform. You would write the code with Terraform and build the infrastructure as seen below.

Image from Darey.io

Programmable infrastructures allow you to manage on-premises and cloud resources through code instead of with the management platforms and manual methods traditionally used by IT teams.
An infrastructure captured in code is simpler to manage, can be replicated or altered with greater accuracy, and benefits from all sorts of automation. It can also have changes to it implemented and tracked with the version control methods customarily used in software development.

STEP 1 - Setup

AWS strongly recommends following the security practice of granting least privilege, i.e. the minimum set of permissions necessary to perform a given task. So its best to look at the infrastructure and see what services would be created or accessed and the required permissions. However, you would create a user with programmatic access and AdministratorAccess permissions.
Configure programmatic access from your work station. I would recommend using the AWSCLI for this with the aws configure command.
Create a S3 bucket via the console to store Terraform state file. View the newly created S3 bucket via your terminal to confirm the access was configured properly. You are all set up when you can see it.

Best practices are to ensure every resource is tagged, using multiple key-value pairs. Secondly, write reusable code. We should avoid hard coding values wherever possible.

STEP 2 - VPC Creation

Create a Directory Structure which should have:

folder(name it whatever you like)
main.tf file which is our main configuration file where we are going to define our resource definition.
variables.tf file which would store your variable declarations. It's best to use variables as it keeps your code neat and tidy. Variables prevents hard coding values and makes code easily reusable.
terraform.tfvars file which would contain the values for your variables. This project would get complex really soon and I think it's best to understand variables and how manage them effectively. I came across this great article from Spacelift that did justice to that.

2.
Set up your Terraform CLI

3.
Add a provider block(AWS is the provider)

provider "aws" {
  region = var.region
}

4.
Add a resource that would create a VPC for the infra.

# Create VPC
resource "aws_vpc" "main" {
  cidr_block                     = var.vpc_cidr
  enable_dns_support             = var.enable_dns_support 
  enable_dns_hostnames           = var.enable_dns_support
  enable_classiclink             = var.enable_classiclink
  enable_classiclink_dns_support = var.enable_classiclink

5.
Run terraform init. Terraform relies on plugins called “providers” to interact with cloud providers, SaaS providers, and other APIs. Terraform configurations must declare which providers they require so that Terraform can install and use them. terraform init finds and downloads those providers from either the public Terraform Registry or a third-party provider registry. This is the part that generates the .terraform.lock.hcl you would notice when you run terraform init.

Notice that a new directory has been created: .terraform\.... This is where Terraform keeps plugins. Generally, it is safe to delete this folder. It just means that you must execute terraform init again, to download them.

6.
Run terraform plan to see what would be created when you decide to create your aws_vpc resource.

7.
Run terraform apply if only you accept the changes that would occur.

A new file is created terraform.tfstate This is how Terraform keeps itself up to date with the exact state of the infrastructure. It reads this file to know what already exists, what should be added, or destroyed based on the entire terraform code that is being developed.

Also created is the lock file .terraform.lock.hcl which contains information about the providers; in future command runs, Terraform will refer to that file in order to use the same provider versions as it did when the file was generated.

STEP 3 - Subnet Creation

According to the infrastructure design, you will require 6 subnets:

2 public
2 private for webservers
2 private for data layer

Create the first 2 public subnets.

Do not try to memorize the code for anything on terraform. Just understand the structure. You can easily get whatever resource block, from any provider you need on terraform registry All you have to do is to tweak it to your desired resource for your infra. Reason a good understanding of the structure of terraform is key. With time, writing the resource would be a breeze.

# Create public subnets
resource "aws_subnet" "public" {
  count  = var.preferred_number_of_public_subnets == null ? length(data.aws_availability_zones.available.names) : var.preferred_number_of_public_subnets   
  vpc_id = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 4 , count.index)
  map_public_ip_on_launch = true
  availability_zone       = data.aws_availability_zones.available.names[count.index]
}

The final main.tf file would look like this:

I'm sure you noticed the private subnets have not been created. On the next publication, you would move on with creating more resources while also refactoring your code. "Doing is the best way of learning", that is exactly what is going to happen in this project.

Darey.io