Cloud / DevOps Engineer

Overview

CloudInfra Deploy Engine v2 is a web-based Terraform automation platform. It lets you choose pre-built AWS templates or upload your own Terraform project as a ZIP file, then runs terraform init, plan, apply, and destroy from a secure dashboard. Each job has its own logs and outputs so you can see exactly what infrastructure was created.

Core Features

• 👤 Secure login & dashboard – session-based auth, each user sees only their own jobs.
• 📦 Template mode – one-click deploy for curated AWS templates: web server, VPC, S3 + CloudFront, two-tier app (EC2 + RDS), EKS, ALB + ASG, and a hardened secure web hosting stack.
• 🧩 Custom mode – upload any Terraform project as a .zip and run it from the browser.
• 📜 Live log streaming – terminal-style view in the browser, auto-refreshing while Terraform runs.
• 🧾 Outputs viewer – stores and shows Terraform outputs (IPs, DNS names, endpoints, IDs) in a clean JSON-style layout.
• 🗑️ Destroy from UI – confirm AWS credentials and trigger terraform destroy safely from the dashboard.

Architecture

The app is split into a Flask backend and an infra templates layer:

• Web frontend – Jinja2 templates (login, dashboard, template forms, custom upload, logs, outputs) styled with Tailwind + custom CSS.
• Flask backend – handles authentication, job model (SQLite), file uploads, parameter handling, and spawning Terraform runners.
• Terraform runner – per-job workspace that executes terraform init/apply/destroy, captures logs and outputs, and writes them back for the UI.
• AWS layer – EC2, VPC, ALB, ASG, RDS, EKS, S3, CloudFront, etc. are provisioned via modules in infra/templates/aws/.

Project Structure

• backend/ – app.py, models, utilities (e.g. terraform_runner.py), templates, and static CSS.
• infra/templates/aws/ – reusable Terraform modules like web_server, vpc_basic, s3_cloudfront, two_tier_app, eks_basic, alb_asg, and secure_web_hosting.
• requirements.txt – Python dependencies for the Flask app.
• .gitignore – ignores Terraform state, caches, venv, and secrets.

Security & Best Practices

• AWS credentials are provided per-run through forms and passed as environment variables to Terraform (not stored in Git).
• Designed for use with a dedicated, least-privilege IAM user and budget alerts.
• Terraform state and workspace directories are kept local to the runner machine, not exposed to the UI.

What I Learned

• How to orchestrate Terraform as a long-running subprocess from a web app while keeping the UX responsive.
• Designing a job model and dashboard that make infra operations traceable and auditable.
• Packaging multiple AWS reference architectures as reusable Terraform templates for students and beginners.

Close details

Overview

CloudInfra Deploy Engine is a DevOps-friendly automation console that lets users drive Terraform commands via a browser-based dashboard, provisioning and managing AWS infrastructure through a guided UI instead of direct CLI usage.

Architecture

Tech Stack & Components

• Flask backend (app.py) to orchestrate Terraform CLI commands
• Terraform configuration (terraform/ with main.tf, variables.tf, outputs.tf, provider.tf)
• UI templates (templates/index.html) with dashboard views
• Optional static assets in static/
• Route 53 hosted zones and EC2 instances for website deployment

CI/CD Snippet (from README)

name: Terraform CI

                            on: [push, pull_request]

                            jobs:
                              terraform:
                                runs-on: ubuntu-latest

                                steps:
                                  - uses: actions/checkout@v4

                                  - name: Setup Terraform
                                    uses: hashicorp/setup-terraform@v2

                                  - name: Terraform fmt
                                    run: terraform fmt -check -recursive
                                    working-directory: ./terraform

                                  - name: Terraform init
                                    run: terraform init -input=false
                                    working-directory: ./terraform

                                  - name: Terraform validate
                                    run: terraform validate
                                    working-directory: ./terraform

Security & Cost Controls

• No terraform.tfvars, state files, or AWS keys are committed to Git.
• .gitignore excludes Terraform state, virtualenvs, and secrets.
• Least-privilege IAM policies recommended for Terraform execution roles.

How I Built It

I combined a Flask application with Terraform CLI, designing a clean DevOps dashboard to trigger init, validate, plan, apply, and destroy while streaming output into the browser. I structured the Terraform configuration under a dedicated terraform/ directory and added optional CI checks using GitHub Actions.

Learnings / Challenges (inferred)

• Orchestrating long-running Terraform processes from a web server safely.
• Handling credentials securely without exposing them to the UI.
• Designing a UX that makes complex infrastructure operations understandable and traceable.

Close details

Overview

This project demonstrates the first step in deploying a portfolio website on AWS EC2, installing an Apache web server, and pulling website files directly from GitHub onto the instance.

Architecture

Tech Stack & Components

• Amazon EC2 (t2.micro, Free Tier)
• Amazon Linux 2
• Apache HTTP Server (httpd)
• Security Group allowing HTTP (80) and SSH (22)
• Git & GitHub for website code deployment

IaC & Automation

Instance provisioning and configuration are described step by step (via console and commands). Future iterations can be migrated to Terraform or EC2 Image Builder for full automation. (inferred)

CI/CD & Monitoring

• Manual Git-based deployment from GitHub to EC2.
• (inferred) Can be extended using GitHub Actions to build and sync website files to EC2.
• (inferred) CloudWatch metrics and basic status checks for instance health and CPU usage.

Security & Cost Optimization

• Minimal Security Group rules (HTTP + SSH) to reduce attack surface.
• Free-tier eligible t2.micro instance to keep costs low.
• (inferred) SSH key–based login with no password authentication.
• (inferred) Stop / terminate instance when not in active use.

How I Built It

Using the AWS Console, I launched an EC2 instance, configured the Security Group, connected via SSH, installed Apache, and cloned my portfolio website from GitHub into /var/www/html.

Learnings / Challenges (inferred)

• Understanding EC2 networking and Security Group rules.
• Mapping Linux file structure to Apache’s document root.
• Troubleshooting HTTP access and verifying that the site served correctly from the public IP.

Close details

Overview

This project upgrades the basic EC2 deployment into a production-ready environment using a static Elastic IP, a custom domain managed via GoDaddy and AWS Route 53, and HTTPS enforced with Let’s Encrypt.

Architecture

Tech Stack & Components

• Elastic IP associated with EC2 instance
• GoDaddy domain pointing NS records to Route 53
• Route 53 Hosted Zone and A Record for domain → Elastic IP
• Let’s Encrypt certificate via certbot for HTTPS

IaC & CI/CD

The deployment is primarily console and CLI-driven, with clear steps to evolve toward full Infrastructure as Code and automated pipelines using Terraform and CI/CD tools. (inferred)

Monitoring & Security

• HTTPS ensures encrypted communication between clients and the EC2-hosted website.
• (inferred) CloudWatch alarms can track instance availability and HTTP response codes.
• (inferred) Regular Let’s Encrypt renewals automated via cron jobs.

Outcomes / Metrics (inferred)

• Stable, bookmarkable domain instead of changing public IP.
• Improved user trust and SEO through HTTPS & SSL/TLS.
• Production-style setup ready for further scaling (ASG + ALB).

Learnings / Challenges (inferred)

• DNS propagation and troubleshooting NS / A records.
• Correctly configuring certbot with Apache on Amazon Linux.
• Aligning registrar DNS with AWS Route 53 hosted zones.

Close details

Overview

This project uses EC2 Image Builder to automate the creation of AMIs with a pre-installed web server, ensuring faster and more consistent deployments across environments.

Architecture

Tech Stack & Components

• Custom Image Builder Component for web server installation
• Image Recipe referencing base Amazon Linux AMI and components
• Infrastructure Configuration for build host and IAM role
• Image Pipeline to orchestrate periodic or manual AMI builds

IaC & Automation

The AMI creation process is fully automated using Image Builder pipelines, making it easy to roll out updated images for EC2-based environments. Terraform can orchestrate these pipelines as part of a broader IaC approach. (inferred)

Monitoring & Security

• (inferred) CloudWatch logs for Image Builder pipeline status and failures.
• IAM roles restrict pipeline permissions to the minimum needed.
• (inferred) Regular AMI refresh schedule to include latest patches.

Outcomes / Metrics (inferred)

• Reduced time-to-provision for new web server instances.
• Consistent configuration across all deployed EC2 instances.
• Improved reliability through standardized base images.

Close details

Overview

This project provisions an EC2 instance using Terraform, configures Security Groups for HTTP access, and uses user_data to automatically install and start Apache, hosting a simple HTML page.

Architecture

IaC Snippet (from README)

provider "aws" {
          region     = "${var.region}"
          access_key = "${var.access_key}"
          secret_key = "${var.secret_key}"
        }

        resource "aws_security_group" "web-server" {
          name        = "web-server"
          description = "Allow incoming HTTP Connections"

          ingress {
            from_port   = 80
            to_port     = 80
            protocol    = "tcp"
            cidr_blocks = ["0.0.0.0/0"]
          }

          egress {
            from_port   = 0
            to_port     = 0
            protocol    = "-1"
            cidr_blocks = ["0.0.0.0/0"]
          }
        }

        resource "aws_instance" "web-server" {
          ami             = "ami-0150ccaf51ab55a51"
          instance_type   = "t2.micro"
          key_name        = "portfolio"
          security_groups = ["${aws_security_group.web-server.name}"]

          user_data = <<-EOF
            #!/bin/bash
            sudo su
            yum update -y
            yum install httpd -y
            systemctl start httpd
            systemctl enable httpd
            echo "<html><h1> Welcome to Cetpa Infotech. Happy Learning... </h1></html>" >> /var/www/html/index.html
          EOF

          tags = {
            Name = "web_instance"
          }
        }

Sensitive values (like real access keys in terraform.tfvars) are never committed to Git.

CI/CD & Automation

• Terraform workflow: terraform init, plan, apply, destroy.
• (inferred) Terraform fmt/validate can be wired into GitHub Actions for basic CI checks.

Monitoring & Security (inferred)

• Use CloudWatch to monitor instance metrics and set alarms on CPU or status checks.
• Restrict SSH access by IP and keep Security Groups minimal.
• Destroy resources after testing to avoid additional AWS charges.

Close details

Overview

This project automates the creation and teardown of an AWS VPC using Terraform, showcasing a complete init → plan → apply → destroy workflow and introducing reusable modules for networking.

Tech Stack & Components

• Custom VPC with CIDR block
• Public subnets
• Internet Gateway and route tables
• Outputs for VPC ID and other identifiers

IaC Snippet (inferred)

# (inferred structure based on README)
        resource "aws_vpc" "main" {
          cidr_block = var.vpc_cidr
          tags = { Name = "demo-vpc" }
        }

        resource "aws_internet_gateway" "igw" {
          vpc_id = aws_vpc.main.id
        }

        resource "aws_subnet" "public" {
          vpc_id                  = aws_vpc.main.id
          cidr_block              = var.public_subnet_cidr
          map_public_ip_on_launch = true
        }

The exact Terraform code lives in the project repo; this snippet is based on the documented structure. (inferred)

Monitoring, Security & Cost (inferred)

• Use tagging to track cost per environment (dev/test).
• Leverage Flow Logs and CloudTrail for network and API visibility.
• Destroy infrastructure with terraform destroy when not needed to avoid charges.

Close details

Overview

This project automates an EC2 + S3 integration where HTML files are stored in S3 and fetched by an EC2 instance using an IAM role instead of static credentials, then served through Apache.

Architecture

Key Resources

• aws_s3_bucket and aws_s3_bucket_object
• aws_iam_role and aws_iam_instance_profile
• aws_security_group for HTTP access
• aws_instance with Apache installed via user_data

Monitoring & Security (inferred)

• IAM role avoids hardcoding AWS credentials.
• CloudTrail can track S3 access via the role.
• S3 bucket policies can further restrict access to only the EC2 role.

Close details

Overview

This project provisions two Apache web server EC2 instances behind an Application Load Balancer, using target groups and health checks to provide a scalable, fault-tolerant setup.

CI/CD & Observability (inferred)

• Terraform plan/apply manage ALB and EC2 lifecycle.
• CloudWatch monitors ALB request metrics and target health.
• Logs can be pushed to S3 for long-term analysis.

Close details

Overview

This project wires S3 bucket events to SNS, sending email notifications each time an object is uploaded, fully provisioned and configured via Terraform.

Monitoring & Security (inferred)

• S3 → SNS events provide near real-time visibility into uploads.
• Policy-secured SNS topic to allow only S3 to publish.
• Email subscription confirmation workflow ensures valid subscribers.

Close details

Overview

This project provisions a custom VPC with a public subnet, a private subnet, a NAT Gateway for secure outbound internet from private EC2 instances, and routing that models real production environments.

Architecture

Monitoring & Security (inferred)

• Private subnet instances have no public IP, reducing exposure.
• Security Groups separate public and private traffic.
• VPC Flow Logs help analyze allowed/denied traffic.

Close details