A portfolio of cloud projects using Infrastructure as Code (IaC) Herein is a terse description of the activity undertaken in each project and the corresponding method of what was done on the CLI. Project titles here are virtually identical to their corresponding repository folders.
Architectural diagram were created using draw.io.
- Install terraform
- Verify the installation
- Enable tab autocompletion
- Provision and destroy an NGINX server
brew tap hashicorp/tap->brew tap hashicorp/tap->brew install hashicorp/tap/terraform->brew update->brew upgrade hashicorp/tap/terraform- terraform --help
terraform -install-autocomplete- Start docker ->
open -a Docker- create the
main.tfinside the relevant folder (earn-terraform-docker-container) - terraform init
- terraform apply
- check the container ->
docker ps terraform destroy
- create the
- Spin up a Debian EC2 instance
- Replace the Debian instance with an Ubuntu instance which is dynamically chosen to be the latest version
- Destroy the Ubuntu EC2 instance
terraform init->terraform fmt->terraform validate->terraform apply- Inspect the state of the EC2 instance ->
terraform show - List resources in the project's state ->
terraform state list
- Inspect the state of the EC2 instance ->
- Add a data block to filter for the latest Ubuntu AMI
terraform destroy
- Create variables.tf file to define EC2 instance name dynamically
- Change instance name whilst provisioning the EC2 instance
touch variables.tfterraform apply -var "instance_name=YetAnotherName"
To be able to use these outputs to connect this component of infrastructure with other components of infrastructure e.g. Amazon S3.
- Create outputs.tf file to define the output EC2 instance configuration
- Query the outputs
touch outputs.tfterraform output
To use HCP Terraform to keep the infrastructure state secure and encrypted in a place that collaborators can access and where Terraform can run remotely.
- Login to terraform
- Having logged in, initialise terraform
- Migrate the state file
- Having migrated the state file to HCP Terraform, delete the local state file
- Set workspace variables in HCP Terraform
terraform loginterraform initterraform initrm terraform.tfstate- Login to HCP Terraform to do this
Creating an EC2 instance for a (PHP) web app with an AWS security group that enables public accessiblity via the internet.
- Changed the EC2 instance to Amazon Linux 2023
- Created a new init_script_amazon_2023.sh script to work with the new AMI
- Created an Amazon Security Group that enables access to the EC2 webserver
- Added vpc_security_group_ids to the aws_instance resource
- Launched the instance
- Obtained from Amazon management console -> AMI catalog
- Modified the original init_script.sh script accordingly
- Added a new resource for security group providing info on ingress and egress including from_port, to_port, protocol and cidr_blocks which enable the public accessibility
- A list was added as such
vpc_security_group_ids = [aws_security_group.web-sg.id] terraform login->terraform fmt->terraform validate->terraform init->terraform apply
Deploying a web app using an EC2 and a load balancer to handle traffic. Both private and public subnets will be used to house the EC2 and load balancer respectively. And all components will be kept in a virtual private cloud for logistic isolation and enhanced security.
- Configured filtration for available AZs with a data block
- Configured a VPC module with 2 private subnets and 2 public subnets, and NAT gateway toggleable VPN gateway
- Configured app security groups
- Configured loading balancer security groups
- Configured a resource for loading balancer ID
- Configured a module for the Elastic Loading Balancer (ELB) with associated LB security group and housed in a public subnet, detailing the instances in the target group, the listener setup of the LB and the health check settings for the instances and tags for the LB.
- Configured a module for the EC2 instances detailing the type of instance and the number of them, housing in two private subnets, associated security groups and tags for the EC2s.
- Created a terraform variable file and added several variables including, aws_regions, vpc_cidr_block, instance_count, enable_vpn_gateway, public_subnet_count, private_subnet_count, public_subnet_cidr_blocks, private_subnet_cidr_blocks, resource_tags and ec2_instance_type.
- Added the variables
- Configured settings for Terraform Cloud
- Configured and output terraform file
- Created .auto.tfvars file to edit the resource tags and modify the number instances
- Added code to main.tf
- Added code to main.tf
- Added code to main.tf
- Added code to main.tf
- Added code to main.tf
- Added code to main.tf
- Added code to main.tf
touch variables.tf-> Added code for all variablestouch terraform.tf-> Added terraform block with details workspace, owner and API providertouch output.tf-> Added code to output public DNS nametouch terraform.auto.tfvars-> Added code
Deploying a web app using an EC2 and a load balancer to handle traffic. Both private and public subnets will be used to house the EC2 and load balancer respectively. And all components will be kept in a virtual private cloud for logistic isolation and enhanced security.
Building on the tasks completed in "learn-terraform-variables"
- Define a database resource in main.tf
- Declare variables for database username and password and mark them as sensitive
- Create a file to be parsed that stores the database username and password
- Add an output block for database details in the output.tf file, include the database address, database username and database password
- Build infrastructure
- Added code to main.tf
- Added code to variables.tf
touch secret.tfvars- Added code to output.tf
terraform init->terraform apply -var-file=secret.tfvars
- Updating the
output.tffile with database information is a way to gather the info required to gain access to the database to update, modify or query the database. - The security of this infrastructure could be improved with a number of changes including changing the ELB port to 443 and the protocol to HTTPS, doing this in turn requires a SSL/TLS certificate (which is called an AWS Certificate Manager [ACM] within AWS Cloud Infrastructure), and this in turn requires a domain which I don't have access to so I did not provision this superior security setting.
- The ingress traffic to the ELB could be limited via the ELB security group. It currently allows all traffic, but if it were an internally used app it could be limited to specific IPs that are trusted such as known internal IPs or a range VPN IPs.
- At a high layer above the ingress traffic, an AWS WAF could be used to block IPs based on reputation, region/country (e.g. Russia), rate (to prevent DDoS) and the pattern of request (to prevent SQL injections)


