DEV Community: Ebelechukwu Lucy Okafor

How I Built a Two-Pipeline Enterprise CI/CD System on Azure DevOps EpicBook Deployment

Ebelechukwu Lucy Okafor — Tue, 21 Apr 2026 06:54:22 +0000

Introduction

This week, I completed what has been the most challenging and rewarding assignment of my DevOps learning journey, deploying the EpicBook online bookstore application using a two-repository, two-pipeline enterprise architecture on Azure DevOps.
No tutorials. No hand-holding. Just a goal, a set of tools, and a lot of errors to fix.
Here is the full story of what I built, what broke, and what I learned.

What Is the Two-Pipeline Model?
In enterprise DevOps, infrastructure code and application code are kept in separate repositories and deployed by separate pipelines. This mirrors how real teams work; infrastructure engineers and developers operate independently.

Repository 1: infra-epicbook → Terraform IaC
Repository 2: theepicbook → Node.js app + Ansible playbooks

Pipeline 1: Infra Pipeline → provisions Azure resources
Pipeline 2: App Pipeline → configures servers + deploys app

Pipeline 1
runs first and produces outputs (VM IP, MySQL FQDN) that Pipeline 2 consumes. This handoff is automated through Azure DevOps pipeline artifacts.
The Full Stack
Layer
Tool
Cloud
Microsoft Azure — South Africa North
IaC
Terraform v1.8.5 (azurerm ~3.100)
Config
Ansible
CI/CD
Azure DevOps — self-hosted agent (WSL)
Authentication
Azure Service Principal (SPN)
App
Node.js 18 + Express + Sequelize ORM
Database
Azure MySQL Flexible Server 8.0
Web server
Nginx — reverse proxy on port 80
Process manager
PM2 — keeps Node.js alive
OS
Ubuntu 22.04 LTS — Standard_D2s_v3
Live URL
http://20.164.211.94

Architecture Overview
Developer → git push to main
↓
Azure DevOps
┌─────────────────────────────────────────┐
│ Pipeline 1 (Terraform) │
│ terraform init → plan → apply │
│ → outputs: VM IP + MySQL FQDN │
│ │
│ Pipeline 2 (Ansible) │
│ install Node.js + PM2 + Nginx │
│ deploy EpicBook → configure MySQL │
└─────────────────────────────────────────┘
↓
Azure Virtual Network (10.0.0.0/16)
┌─────────────────────┬───────────────────┐
│ Public Subnet │ Private Subnet │
│ 10.0.1.0/24 │ 10.0.2.0/24 │
│ │ │
│ epicbook-prod-vm │ MySQL Flexible │
│ Ubuntu 22.04 │ Server 8.0 │
│ Nginx :80 │ port 3306 │
│ Node.js :8080 │ VNet only │
│ PM2 │ SSL required │
└─────────────────────┴───────────────────┘
↓
Browser → http://20.164.211.94

Step 1: Service Principal (SPN) Setup
Terraform needs permission to create Azure resources. I created an App Registration in Azure AD and assigned it the Contributor role on my subscription.
az ad sp create-for-rbac \
--name "epicbook-devops-spn" \
--role Contributor \
--scopes /subscriptions/$(az account show --query id -o tsv) \
--output json

This outputs four credentials: Client ID, Client Secret, Tenant ID, and Subscription ID. These go into an Azure DevOps service connection named azure-devops-connection.
Key lesson: The Client Secret is shown exactly once. Copy it immediately before closing the page.

Step 2: Terraform Remote State Backend
For pipeline-based Terraform, the state file must live in Azure Blob Storage so the agent can access it between runs.
az storage account create \
--name epicbooklucytfstate01 \
--resource-group rg-epicbook \
--location southafricanorth \
--sku Standard_LRS

az storage container create \
--name tfstate \
--account-name epicbooklucytfstate01 \
--auth-mode login

The backend.tf configuration:
terraform {
backend "azurerm" {
resource_group_name = "rg-epicbook"
storage_account_name = "epicbooklucytfstate01"
container_name = "tfstate"
key = "epicbook.terraform.tfstate"
}
}

Critical lesson: You cannot use variables in a Terraform backend block. Pass the storage account key as the ARM_ACCESS_KEY environment variable instead.

Step 3: Infrastructure Pipeline (Terraform)

The Infra pipeline provisions 13 Azure resources in one run:
Resource Group
Virtual Network (10.0.0.0/16)
Public subnet (10.0.1.0/24) + NSG (ports 22 and 80)
Private subnet (10.0.2.0/24) + NSG (port 3306 from VNet only)
Static Public IP (Standard SKU)
Network Interface
Private DNS Zone (linked to VNet)
Linux VM (Ubuntu 22.04, Standard_D2s_v3)
MySQL Flexible Server 8.0
MySQL database (bookstore)

The pipeline YAML authenticates using AzureCLI@2 with addSpnToEnvironment: true, which injects the SPN credentials automatically:

task: AzureCLI@2 displayName: 'Terraform Apply' inputs: azureSubscription: 'azure-devops-connection' addSpnToEnvironment: true scriptType: 'bash' scriptLocation: 'inlineScript' inlineScript: | export ARM_CLIENT_ID="$servicePrincipalId" export ARM_CLIENT_SECRET="$servicePrincipalKey" export ARM_TENANT_ID="$tenantId" export ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv | tr -d '\r') export ARM_ACCESS_KEY="$STORAGE_KEY" terraform -chdir="$(Build.SourcesDirectory)" apply -auto-approve tfplan ** env:** STORAGE_KEY: $(storage_account_key)

After applying, the pipeline captures and publishes the outputs:
public_ip = 20.164.211.94
db_host = epicbook-prod-mysql-nrbhh4.mysql.database.azure.com

Step 4: Application Pipeline (Ansible)
The App pipeline connects to the VM over SSH using a private key stored in Azure DevOps Secure Files, then runs an Ansible playbook that:
Installs Node.js 18, PM2, and Nginx
Clones the EpicBook repository
Installs npm dependencies
Creates .env and config/config.json with MySQL connection details
Starts the app with PM2
Configures Nginx as a reverse proxy to port 8080
Verifies the app responds with HTTP 200

script: | ansible-playbook \ -i inventory.ini \ ansible/site.yml \ --extra-vars "mysql_host=$(MYSQL_FQDN) db_name=bookstore db_user=epicbook_user" \ -v displayName: 'Run Ansible playbook'

The Errors I Hit (And Fixed)
This deployment took two weeks. Here is what broke and how I fixed it.
Error 1: SPN Cannot Read Subscription (403 Forbidden)
The SPN was missing the Reader role. Fixed by assigning both Contributor and Reader.

Error 2: Variables Not Allowed in Backend Block
Error: Variables not allowed
on backend.tf line 7: access_key = var.storage_account_key

Terraform evaluates the backend before loading variables. Removed the access_key line and passed it via ARM_ACCESS_KEY environment variable instead.

Error 3: Carriage Return in Subscription ID (400 Bad Request)
The Windows Azure CLI adds \r to command output. This corrupted the subscription ID URL:
parse "https://management.azure.com/subscriptions/a75e93ba\r/providers"

Fixed by piping through tr -d '\r':
export ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv | tr -d '\r')

Error 4: VM Size Quota Exceeded
Standard_B2ats_v2 has zero quota in South Africa North. Checked available sizes:
az vm list-skus --location southafricanorth --size Standard_D2s --output table
Switched to Standard_D2s_v3, which had no restrictions.

Error 5: App Connects to localhost Instead of MySQL
SequelizeConnectionRefusedError: connect ECONNREFUSED 127.0.0.1:3306

The EpicBook app reads database config from config/config.json, not .env. The file had host: 127.0.0.1 hardcoded. Updated it with the actual MySQL FQDN and SSL settings.
Error 6: 502 Bad Gateway
The app listens on port 8080 by default (process.env.PORT || 8080), but Nginx was proxying to port 3000. Fixed by checking the actual port in server.js:
grep -n "port|PORT|listen" ~/theepicbook/server.js

const PORT = process.env.PORT || 8080;

Then updated both .env and Nginx config to use port 8080.

Key Lessons Learned

Always check what port your app actually uses before configuring Nginx. Never assume that grep the source code.
Terraform backend blocks are special. They are evaluated before any variable loading. Credentials must come from environment variables, not var. references.
WSL + Azure CLI adds \r to output. Always pipe through tr -d '\r' when using az CLI output in bash scripts that go into URLs or environment variables.
Azure VM size quotas vary by region. Have fallback sizes ready. Standard_D2s_v3 is reliably available across most regions.
Check where your app actually reads config. The EpicBook app ignored .env for database settings and read from config/config.json instead. Always check the source code.
Private MySQL = no public endpoint. The MySQL Flexible Server in the private subnet has no public IP it is only reachable from within the VNet. This is production-grade security done right.
PM2 is non-negotiable for Node.js in production. Without it, the app dies the moment your Ansible playbook finishes. What I Would Do Differently Add an admin_ssh_key block to Terraform from the start instead of manually pushing keys via az vm run-command Use Terraform workspaces for environment separation (dev/staging/prod) Store db_password in Azure Key Vault and reference it from the variable group Add a health check endpoint to the app for proper pipeline verification Set up PM2 startup script so the app survives VM reboots automatically

The Result
After two weeks, two pipelines, thirteen Azure resources, and nine documented errors, EpicBook is live.
The full architecture Terraform provisioning infrastructure, Ansible configuring servers, Node.js serving the application, MySQL storing data, Nginx proxying requests, PM2 keeping everything running, is automated end-to-end by Azure DevOps on every commit to main.
That is CI/CD done the enterprise way.
Resources
Azure DevOps documentation docs.microsoft.com/azure/devops
Terraform azurerm provider registry.terraform.io/providers/hashicorp/azurerm
Ansible documentation docs.ansible.com
PM2 documentation pm2.keymetrics.io
EpicBook app github.com/pravinmishraaws/theepicbook

From 500 Errors to a Fully Working Cloud App: My EpicBook Deployment on Azure

Ebelechukwu Lucy Okafor — Wed, 08 Apr 2026 11:03:54 +0000

This week, I moved beyond simple deployments and built a real-world, multi-tier application architecture using Terraform + Ansible + Nginx + Node.js + MySQL on Microsoft Azure.
And honestly? It didn’t work at first.
But that’s where the real learning happened.
Let me walk you through the full journey, including the mistakes, fixes, and key DevOps lessons you can apply immediately.

The Goal
Deploy a production-style web application (EpicBook) with:
🌐 Web Layer → Nginx (Reverse Proxy)
⚙️ App Layer → Node.js (Express app)
🗄️ Database Layer → MySQL (separate VM)
🏗️ Infrastructure → Terraform
🤖 Automation → Ansible

Step 1: Provisioning Infrastructure with Terraform
Instead of manually creating servers, I used Terraform to spin up:
4 Virtual Machines (web1, web2, app, db)
Virtual Network + Subnets
Public IPs
Network Security Groups
terraform init
terraform plan
terraform apply

Lesson: Infrastructure should be code. If you can’t recreate it in minutes, it’s not production-ready.

Step 2: SSH Setup (First Real Problem)
After provisioning, Ansible couldn’t connect:
UNREACHABLE! SSH host key verification failed

Why does this happen?
Every time Terraform creates new VMs, they get new SSH fingerprints.
Fix:
ssh-keyscan -H >> ~/.ssh/known_hosts

Lesson: Always run ssh-keyscan after redeploying infrastructure.

Step 3: Running Ansible
I executed my playbook:
ansible-playbook -i inventory.ini site.yml

✔ Everything passed
✔ No errors
But then I opened the browser…

Step 4: The 500 Internal Server Error
500 Internal Server Error
nginx/1.18.0

At this point, many people would think:
“But Ansible said SUCCESS…”
This is where DevOps thinking matters.

Step 5: Debugging the Problem
I inspected the application:
cat /var/www/epicbook/server.js

Discovery:
It’s a Node.js app
Runs on port 8080
Not a static website
The mistake:
I configured Nginx like this:
root /var/www/epicbook;

That only works for HTML files, not backend apps.

Step 6: Fixing the Architecture
This was the turning point.
✅ Fix 1: Nginx Reverse Proxy
location / {
proxy_pass http://localhost:8080;
}

Now Nginx forwards traffic to Node.js.

✅ Fix 2: Install Node.js

name: Install Node.js apt: name: nodejs state: present

✅ Fix 3: Install Dependencies

name: Install npm packages npm: path: /var/www/epicbook

✅ Fix 4: Run App as a Service
Created a systemd service:
ExecStart=/usr/bin/node server.js

✅ Fix 5: Database Setup
Installed MySQL on the DB server
Created:
database: bookstore
user: epicbook

✅ Fix 6: Use Private Network (CRITICAL)
Instead of:
"host": "127.0.0.1"

I used:
"host": "10.0.1.7"
Lesson: Databases should NEVER be exposed publicly.
Other Errors I Encountered

Git “Dubious Ownership” fatal: detected dubious ownership

✔ Fix:
Remove and re-clone the directory

SSH Timeout Connection timed out

✔ Fix:
Retry + verify connectivity

Final Result
After fixing everything:
✅ App running on both web servers
✅ Nginx routing traffic correctly
✅ Node.js processing requests
✅ MySQL storing data
Open in browser:
http://
http://

Idempotency Check
I ran the playbook again:
ansible-playbook -i inventory.ini site.yml

✔ changed=0
Lesson: Good automation should be safe to run multiple times.

What I Learned (The Real Value)
This assignment wasn’t just about tools it was about thinking like a DevOps engineer.
Key Takeaways:
✔ “Success” in automation doesn’t mean the app works
✔ Always verify in the browser (real user test)
✔ Understand your application (Node.js ≠ static site)
✔ Debugging is more important than writing code
✔ Architecture decisions matter more than commands

Final Insight
A deployment is only successful when a real user can access the application — not when the playbook says “OK”.

If You're Learning DevOps…
Start building projects like this:
Multi-tier apps
Real debugging scenarios
Infrastructure + application together
That’s how you move from:
👉 “I know commands”
to
👉 “I can solve real-world problems”

Let’s Connect
If you’re also learning DevOps or working on similar projects, I’d love to connect and learn together.

DevOps #Terraform #Ansible #Azure #NodeJS #CloudComputing #LearningInPublic

How I Deployed a Three-Tier Book Review App on AWS Using Terraform Modules and Agentic AI

Ebelechukwu Lucy Okafor — Fri, 27 Mar 2026 07:36:59 +0000

A complete walkthrough from VPC design to a live Next.js + Node.js + MySQL application running on EC2 and RDS, with every error documented and fixed.

When I started this assignment, I had already deployed applications on both Azure and AWS in previous weeks. But this was different. This time, there was no step-by-step guide. The assignment said: "Design and execute this project like a professional."

So that is exactly what I did. I used Terraform modules to organise my infrastructure, Claude Code as my Agentic AI copilot to generate templates and fix errors, and deployed a real full-stack Book Review application, Next.js frontend, Node.js backend, and MySQL database on Amazon RDS.
"Agentic DevOps is not about replacing engineers with AI. It is about changing what engineers spend their time on. The agent executes. The engineer decides."
This post documents everything: the architecture decisions, every command, every error I hit, and every fix that worked. If you follow this guide, you can deploy the same application with zero surprises.
****What We Are Building

A three-tier web application following production architecture patterns:

Internet Users │ ▼ port 80 EC2 Ubuntu 22.04 ← Public Subnet 10.0.1.0/24 ├── Nginx (port 80) → proxies to Next.js (port 3000) ├── Next.js 15 Frontend ← PM2 managed, port 3000 └── Node.js Backend ← PM2 managed, port 3001 │ ▼ port 3306 (MySQL) RDS MySQL 8.0 ← Private Subnets — no internet access ├── bookreview-db (primary) └── Security: only EC2 can connect on port 3306 Terraform Modules: networking/ → VPC + 3 subnets + IGW + NAT security/ → EC2 SG + RDS SG compute/ → EC2 t2.micro + Elastic IP database/ → RDS MySQL db.t3.micro

****Prerequisites

Install these on your local machine before starting:

Check all tools are ready

terraform -v # Need >= 1.5
aws sts get-caller-identity # Your AWS account
git --version # Any recent version

Terraform >= 1.5 — terraform.io/downloads
AWS CLI configured with aws configure
AWS account with EC2, RDS, and VPC permissions
Git and VS Code
SSH client (built into Mac/Linux; Git Bash on Windows)

****Why Terraform Modules?

****Key Concept: Terraform Modules

Modules are reusable, self-contained packages of Terraform code, instead of one giant main.tf with 300+ lines. Modules separate concerns. Each module has its own inputs (variables.tf), resources (main.tf), and outputs (outputs.tf). The root main.tf calls all modules and wires their outputs together.
For this deployment, I created five modules:
modules/networking/
VPC (10.0.0.0/16), public subnet, 2 private subnets, Internet Gateway, NAT Gateway, route tables
variables.tfmain.tfoutputs.tf
modules/security/
EC2 security group (SSH + HTTP + port 3000) and RDS security group (MySQL from EC2 SG only)
variables.tfmain.tfoutputs.tf
modules/compute/
EC2 t2.micro Ubuntu 22.04, Elastic IP, key pair attachment, user_data for setup
variables.tfmain.tfoutputs.tf
modules/database/
RDS MySQL 8.0 db.t3.micro in private subnets, DB subnet group, password config
variables.tfmain.tfoutputs.tf
The key insight is how modules talk to each other through outputs. The networking module outputs vpc_id. The security module takes that as input. The compute module takes the security group ID from security. No module needs to know the internal details of another, only their outputs.
The Deployment Phase by Phase

****PHASE 01 Project Setup and SSH Key Generation

Create the project folder, module structure, and SSH key pair. The key pair must exist before running terraform validate. Terraform reads the public key file during validation.

Create project and module folders

mkdir terraform-book-review-CLI
cd terraform-book-review-CLI
mkdir -p modules/networking modules/security
mkdir -p modules/compute modules/database user_data

Generate SSH key pair (MUST do this before terraform validate)

ssh-keygen -t rsa -b 4096 -f bookreview-key -N ""

Creates: bookreview-key (private) + bookreview-key.pub (public)

Protect sensitive files from git

echo "bookreview-key" >> .gitignore
echo "*.tfstate" >> .gitignore
echo ".terraform/" >> .gitignore

****PHASE 02 Write All Terraform Module Files

This is where I used Claude Code as an Agentic AI copilot. I used /init to create CLAUDE.md, then asked Claude Code to generate the Terraform templates. When validation errors appeared, I pasted them into Claude Code, and it read all module files simultaneously, diagnosed the root cause, and applied fixes automatically. What would take 30 minutes manually took 7 minutes with Agentic AI.
Here is the root main.tf that calls all modules. Notice how module outputs become inputs to the next module:
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
}

provider "aws" { region = var.aws_region }

Upload SSH public key to AWS

resource "aws_key_pair" "main" {
key_name = "bookreview-key"
public_key = file("${path.module}/bookreview-key.pub")
}

Step 1: Create network foundation

module "networking" {
source = "./modules/networking"
vpc_cidr = var.vpc_cidr
azs = var.azs
}

Step 2: Create security groups (needs VPC ID from networking)

module "security" {
source = "./modules/security"
vpc_id = module.networking.vpc_id # ← output from networking
}

Step 3: Create EC2 (needs subnet + SG from above modules)

module "compute" {
source = "./modules/compute"
subnet_id = module.networking.public_subnet_id
sg_id = module.security.ec2_sg
key_name = aws_key_pair.main.key_name
}

Step 4: Create RDS (needs private subnets + RDS SG)

module "database" {
source = "./modules/database"
private_subnet_ids = [module.networking.private_subnet_id_1,
module.networking.private_subnet_id_2]
rds_sg_id = module.security.rds_sg
db_password = var.db_password
}

****PHASE 03 Terraform Init, Validate, Plan and Apply

With all module files written, the standard Terraform workflow runs. RDS takes 5–8 minutes to provision. Note your EC2 public IP and RDS endpoint from the outputs you need them for all SSH and database commands.
terraform init # Downloads AWS provider ~5.0
terraform validate # Checks all module references
terraform plan # Preview — confirm no destroy actions
terraform apply # Type 'yes' — wait ~10 minutes

After apply completes, note these outputs:

ec2_public_ip = "54.227.244.250"
rds_endpoint = "bookreview-db.cixq88qmex1t.us-east-1.rds.amazonaws.com:3306"

****PHASE 04 SSH Into EC2 and Install Node.js 18
Ubuntu 22.04 ships with Node.js v12. The app requires v18. This is the most common trap when deploying Next.js on a fresh Ubuntu server: you must install Node.js 18 via the NodeSource repository, not the default apt package.

From local terminal

chmod 400 bookreview-key
ssh -i bookreview-key ubuntu@54.227.244.250

Inside EC2 — remove old Node conflict and install v18

sudo apt remove -y libnode-dev
sudo apt autoremove -y && sudo apt clean
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs nginx git

Verify

node -v # v18.20.8 ✅
npm -v # 10.8.2 ✅

****PHASE 05: Clone App and Configure Backend

The repository is a monorepo with backend/ (Node.js + Express + Sequelize) and frontend/ (Next.js 15). The backend .env file points to localhost by default. Update it to point to the RDS endpoint. Sequelize auto-creates all database tables on first startup.
git clone https://github.com/pravinmishraaws/book-review-app ~/book-review-app
cd ~/book-review-app/backend

Update .env with RDS credentials (use nano — NOT cat heredoc)

nano .env

Replace content with:

DB_HOST=bookreview-db.cixq88qmex1t.us-east-1.rds.amazonaws.com
DB_NAME=bookreviewdb
DB_USER=admin
DB_PASS=BookReview123
DB_DIALECT=mysql
PORT=3001
JWT_SECRET=mysecretkey

Ctrl+X then Y then Enter to save

Install PM2 globally and start backend

sudo npm install -g pm2
pm2 start src/server.js --name backend
pm2 save

Watch for this in logs:

Database 'bookreviewdb' connected successfully with SSL!
Database schema updated successfully!
Server running on port 3001

****Key Concept: Sequelize Auto-Sync
Sequelize calls sync() on startup, which creates all database tables automatically if they don't exist. You don't need to run SQL migration files manually. When you see "Database schema updated successfully", all tables are ready.

****PHASE 06 Build and Deploy Frontend + Configure Nginx

Next.js 15 requires a production build before starting. The build compiles all pages, optimises JavaScript, and pre-renders static pages. Nginx then acts as a reverse proxy; users hit port 80, and Nginx forwards to port 3000.
cd ~/book-review-app/frontend

Tell frontend where the backend API is

cat > .env.local << 'EOF'
NEXT_PUBLIC_API_URL=http://54.227.244.250:3001
EOF

npm install # Installs 327 packages
npm run build # Compiles production bundle

Expected: ✓ Compiled successfully — 7 pages

pm2 start npm --name frontend -- start
pm2 save
pm2 list # backend + frontend both online ✅

Configure Nginx reverse proxy

sudo tee /etc/nginx/sites-available/bookreview << 'EOF'
server {
listen 80;
server_name _;
location /api {
proxy_pass http://localhost:3001;
proxy_set_header Host $host;
}
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
}
}
EOF

sudo ln -sf /etc/nginx/sites-available/bookreview /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl restart nginx

Make PM2 survive reboots

pm2 startup # Run the command it outputs
pm2 save

PHASE 07 Verify — App is Live!

Open your browser and navigate to your EC2 public IP. The Book Review App homepage loads. Login and register pages work. The backend is connected to RDS MySQL. The full stack is live.
http://54.227.244.250:3000 → Book Review App homepage ✅
http://54.227.244.250:3000/login → Login page with form ✅
http://54.227.244.250:3000/register → Register page ✅
http://54.227.244.250 → Same app via Nginx port 80 ✅

****Every Error I Hit and How I Fixed It

These are all the errors I encountered during the deployment. If you follow this guide, you will hit the same ones; these fixes resolve them completely.

Error
Root Cause
Fix
Status
1
Duplicate resource aws_db_subnet_group in variables.tf
Resource block accidentally placed in variables.tf instead of main.tf
Removed resource block from variables.tf — kept only variable declarations
FIXED
2
Reference to undeclared resource aws_subnet.private_1
Subnet resource named private but outputs.tf referenced it as private_1
Renamed resource to private_1 and added private_2 in second AZ
FIXED
3
Unsupported attribute vpc_id on module.networking
networking/outputs.tf did not export vpc_id — module created VPC but never exported its ID
Added output "vpc_id" { value = aws_vpc.main.id } to networking/outputs.tf
FIXED
4
CIDR block 10.0.2.0/24 conflicts with existing subnet
Partial apply had already created a subnet — re-apply tried to create same CIDR twice
Changed private_1 subnet CIDR to 10.0.4.0/24 to avoid conflict
FIXED
5
npm ERR! Missing script: "start"
backend/package.json had no start script — npm start had nothing to run
Added "start": "node src/server.js" to scripts in package.json
FIXED
6
dpkg error overwriting /usr/include/node/common.gypi
Old libnode-dev package conflicted with Node.js 18 installer
sudo apt remove -y libnode-dev then re-run NodeSource installer
FIXED
7
Shell stuck at > prompt when using cat heredoc
Leading spaces before EOF marker prevented heredoc from closing
Use nano instead of cat heredoc for all .env file creation
FIXED

*Key Concepts Explained
*Three-Tier Architecture
The web tier (EC2 with Nginx + Next.js) is publicly accessible. The app tier (Node.js backend) runs on the same EC2 but is only reachable through the web tier. The database tier (RDS) is in private subnets with no internet route; only the EC2 security group can connect on port 3306. Each tier has a different trust level and a different security boundary.
Security Group Chaining
The RDS security group allows MySQL (port 3306) only from the EC2 security group ID, not from any IP address. This means even with valid RDS credentials, you cannot connect from outside the VPC. Only the EC2 instance can reach the database. This is least-privilege networking applied at the AWS infrastructure level.
Agentic AI in DevOps — Claude Code
I used Claude Code throughout this deployment. For Terraform errors, I would type the error message, and Claude Code would read all module files simultaneously, trace the dependency chain, find the root cause, and apply the fix. This is the future of DevOps AI agents that can hold the entire codebase in context and diagnose cross-file issues instantly.
PM2 — Production Process Manager
If you start a Node.js app with node server.js and close your SSH session, the process dies. PM2 runs apps as background daemons. pm2 startup generates a system service that starts PM2 on boot. pm2 save persists the process list. pm2 list shows CPU, memory, and uptime for all managed processes.
What I Learned — 4 Lessons That Changed How I Think
Modules are a professional infrastructure. Flat Terraform files work for small projects. Modules scale. The separation of networking, security, and compute into independent modules means any engineer on the team can open one folder and understand exactly one thing. That clarity is worth the extra files.

Agentic AI changes the debugging loop entirely. With Claude Code reading all files simultaneously, what took 30 minutes of manual cross-referencing took 7 minutes. The AI does not replace the engineer; it removes the tedious parts so the engineer can focus on architecture decisions.

Read the files before trying to fix things. Almost every error I hit was answered by reading the relevant config file. The .env pointed to localhost. The package.json had no start script. The outputs.tf was missing vpc_id. The answer was always in the files read first.

Infrastructure and deployment are separate concerns. Terraform provisions where the app runs. npm install, npm run build, and pm2 deploy the app itself. Nginx makes it production-ready. Understanding which layer handles which concern prevents debugging in the wrong place.

****Final Thoughts

This was the most complex assignment in the DevOps micro internship — and the most rewarding. I designed a real three-tier architecture, wrote production-grade Terraform modules, used Agentic AI as a genuine copilot, and got a full-stack application live on AWS.
The Book Review App is live. The infrastructure is reproducible. Every error is documented. That is what production DevOps looks like.
If you have questions, drop them in the comments. If this helped you, share it with someone learning DevOps.

terraform#aws#devops#nextjs#nodejs#mysql#claudecode#agenticai#cloudengineering#womenintech#learninginpublic

Mastering Agentic AI DevOps with Claude Code: My First Full Pipeline Deployment

Ebelechukwu Lucy Okafor — Tue, 17 Mar 2026 10:45:20 +0000

I recently completed the Ultimate Agentic AI DevOps Assignment using Claude Code, and I’m excited to share what I built, what I learned, and how agentic AI is changing the way we think about DevOps automation.
This post walks through each task from setting up Skills to deploying a live site on AWS and includes lessons, screenshots, and a LinkedIn post to prove it all works!

*Task 1 — Set Up the Skill Files Correctly
What I did:
Created the .claude/skills/ folder structure with four subfolders: scaffold-terraform, tf-plan, tf-apply, and deploy.
Downloaded and renamed the required files:
scaffold-terraform/SKILL.md
scaffold-terraform/template-spec.md
tf-plan/SKILL.md
tf-apply/SKILL.md
deploy/SKILL.md
Verified everything in VS Code to ensure proper placement and naming.
*What I learned:
Claude Skills require precise folder and file naming to function correctly.
The name: field in each SKILL.md must match the filename — otherwise, the agent won’t load.
Issue faced:
Initially placed template-spec.md outside its folder. Claude failed to scaffold.
Fixed it by moving it into scaffold-terraform/ and re-running the skill.

****Task 2 — Walk Through and Explain the Four Skills
/scaffold-terraform
What it does: Generates Terraform files based on a template spec.
Tools used: Claude Code + Write access.
Why Write access: It needs to create actual .tf files in the project.
/tf-plan
What it does: Runs terraform plan to preview infrastructure changes.
Tools used: Terminal access only.
Why Read-only: It doesn’t modify anything — just analyzes.
/tf-apply

****What it does: Applies the Terraform plan to provision resources.
Tools used: Terminal + Write access.
Why Write access: It creates infrastructure on AWS.
/deploy

****What it does: Syncs site files to S3 and triggers CloudFront invalidation.

****Tools used: AWS CLI + Write access.
Why Write access: It modifies cloud resources and pushes files.
Key takeaway:
“Needs conversation context? Use a Skill. Self-contained job? Use a Subagent.”
DevOps example (Skill): /tf-plan needs context from previous steps.
DevOps example (Subagent): security-auditor runs independently on Terraform files.

*Task 3 — Run the Full Pipeline: Scaffold → Plan → Apply → Deploy
What I did:
Ran /scaffold-terraform to generate Terraform files.
Manually ran terraform init in the terminal.
Executed /tf-plan to preview changes.
Ran /tf-apply to provision AWS resources.
Used /deploy to sync site files to S3 and invalidate CloudFront cache.
*What I learned:
Claude Code can orchestrate a full deployment pipeline with minimal manual steps.
Each skill builds on the previous one — like a relay race.
*Issue faced:
CloudFront invalidation failed due to missing permissions.
Solved by updating IAM role with CloudFront: CreateInvalidation permission.
Success:
My site is live at: https://d123abcxyz.cloudfront.net
*Task 4 — LinkedIn Post (MANDATORY)

****What I built:
A live static site hosted on AWS using Terraform and Claude Code.

****Skills used:
/scaffold-terraform, /tf-plan, /tf-apply, /deploy

****What I learned:
Agentic AI can automate DevOps pipelines with precision and context-awareness.
Screenshots included:
Claude Code skill execution
Live site in browser
Terraform files in VS Code

🔗 LinkedIn Post URL: https://www.linkedin.com/posts/ebelechukwu-okafor_agenticai-mcp-devops-activity-7439480896090537984-PpIl?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAABglo4IBjif-4VKcp2fiPwev8ImRV7LTaN0

✅ Final Thoughts
This assignment taught me how to:
Structure and run Claude Skills correctly
Understand tool permissions and context boundaries
Deploy a full infrastructure pipeline using AI agents
Agentic DevOps is real — and it’s powerful.

I’m excited to keep building with Claude Code and explore more advanced workflows.

I Deployed a Production-Style Three-Tier Application on Azure (Next.js + Node.js + MySQL)

Ebelechukwu Lucy Okafor — Sun, 08 Mar 2026 06:54:15 +0000

A few days ago, I challenged myself to deploy a real-world cloud architecture instead of just running applications locally.
*The goal was simple:
Deploy a Book Review Web Application on the cloud using a secure three-tier architecture.
But like most cloud projects… it quickly became much more than that.
*I had to deal with:
networking
database authentication issues
SSL enforcement
load balancing
debugging Node.js deployment problems
By the end of the project, I had built a fully working cloud system on Microsoft Azure.
This post walks through what I built, the problems I faced, and how I solved them.
*What I Built
The application is a Book Review platform built with:
Frontend
Next.js
Backend
Node.js + Express
Database
MySQL
*Instead of deploying everything on one server, I used a ****Three-Tier Architecture.
Internet
│
Public Load Balancer
│
Web Tier (Next.js + Nginx)
│
Internal Load Balancer
│
App Tier (Node.js API)
│
Database Tier (Azure MySQL)

Each tier runs independently, which is how most production systems are designed.

☁️ ****Azure Services Used
Here are the core services I used:
Azure Virtual Network
Azure Virtual Machines
Azure Network Security Groups
Azure Load Balancer
Azure Database for MySQL Flexible Server
This setup allowed me to design secure network segmentation between application layers.

****Step 1 — Creating the Network Architecture
First I created a Virtual Network with the CIDR block:
10.0.0.0/16

Then I divided it into six subnets.
****Web Tier (Public)
10.0.1.0/24
10.0.2.0/24

****App Tier (Private)
10.0.3.0/24
10.0.4.0/24

****Database Tier (Private)
10.0.5.0/24
10.0.6.0/24

****Why?
Because databases should never be exposed to the public internet.

*Step 2 — Securing the Network
I configured Network Security Groups.
Rules were strict:
*Web Tier
Allow HTTP (80)
Allow HTTPS (443)
Allow SSH (22)

****App Tier
Allow port 3001 from Web Tier only

****Database Tier
Allow port 3306 from App Tier only

This ensured that:
Users can only access the frontend
backend servers remain private
The database stays fully protected
****Step 3 — Deploying the Backend
The backend runs a Node.js API server.
I installed dependencies:
sudo apt update
sudo apt install nodejs npm git

Then I installed PM2 to manage the application.
sudo npm install -g pm2

****Start the backend:
pm2 start server.js --name backend-api

Save the process:
pm2 save

Enable startup on reboot:
pm2 startup

Now the backend runs automatically even if the server restarts.
Step 4 — Setting Up the Database
For the database layer, I used:
Azure Database for MySQL Flexible Server
****Important configurations:
Private network access
SSL required
High availability (Zone redundant)
Read replica
This ensures the database is:
secure
scalable
fault tolerant

****Testing Database Connectivity
From the App VM, I installed the MySQL client.
sudo apt install mysql-client

Then connected using SSL.
mysql -h book-review-mysql.mysql.database.azure.com \
-u username \
-p \
--ssl-mode=REQUIRED

If everything works you should see:
mysql>

**** Problems I Faced (And How I Solved Them)
❌ Problem 1 — MySQL Login Failed
Error:
ERROR 1045 (28000): Access denied for user

Cause:
Azure requires the username format:
username@servername

Solution:
Ebelechukwu@book-review-mysql

❌ *Problem 2 — SSL Connection Required
Azure MySQL enforces SSL.
Solution:
--ssl-mode=REQUIRED
❌ *Problem 3 — Node.js Would Not Start
Error:
npm error: Missing script: start

****Solution:
Instead of npm start, I used PM2.

*Final Result
After everything was configured:
✔ Backend connected to MySQL
✔ Database schema created automatically
✔ Sample books and reviews inserted
✔ API running on port 3001
*Testing:
curl http://localhost:3001

****Response:
Book Review API is running

****Success

What This Project Taught Me
This project helped me understand:
real cloud networking
secure infrastructure design
debugging distributed systems
production style deployments
Most importantly…
Cloud engineering is not just about launching servers.
It’s about designing systems that are secure, scalable, and resilient.

****What I Would Improve Next
Next improvements I plan to add:
Terraform infrastructure
CI/CD pipelines
containerization with Docker
Kubernetes deployment

****Final Thoughts
If you're learning Cloud Engineering or DevOps, I highly recommend building projects like this.
Nothing teaches cloud architecture faster than breaking things and fixing them.
If you’ve built something similar, I’d love to hear about it.

Tags for Dev.to
Use these tags:

azure

cloud

devops

nodejs

mysql

cloudarchitecture

Deploy Book Review App (Three-Tier Architecture) on AWS

Ebelechukwu Lucy Okafor — Fri, 27 Feb 2026 21:12:43 +0000

Deploying a full-stack app in the cloud sounds glamorous—until you’re debugging a 403 Forbidden error at 2 a.m. Here’s how I survived my DevOps capstone project—and what you can learn from it.
** What Is This Project?
I recently completed Assignment 4 of the DevOps Zero to Hero course by Pravin Mishra, a hands-on challenge to deploy the Book Review App on AWS using real-world, production-grade architecture.

The app is simple in concept:

Browse books
Read reviews
Log in and write your own

But under the hood? It’s a three-tier masterpiece:

Frontend: Next.js (React with server-side rendering)
Backend: Node.js + Express (REST API)
Database: MySQL (via Amazon RDS)

And the goal wasn’t just to “make it work.” It was to build it the way real companies do:

✅ High availability
✅ Network isolation
✅ Auto-scaling
✅ Secure traffic flow No pressure, right? *The Architecture: Like Building a Castle Here’s what I built: Internet ↓ Public Application Load Balancer (ALB) ↓ Web Tier (Next.js on EC2 in public subnets) ↓ Internal ALB (private, not internet-facing) ↓ App Tier (Node.js on EC2 in private subnets) ↓ Database Tier (MySQL RDS Multi-AZ + Read Replica in private subnets) *Key Security Principles:
No public access to backend or database
Traffic flows only one way: Internet → Web → App → DB
Security Groups act like bouncers:
- ALB can talk to Web EC2
- Web EC2 can talk to Internal ALB
- Internal ALB can talk to App EC2
- App EC2 can talk to RDS
- Nothing else gets in. This isn’t just “best practice”—it’s how you prevent breaches.

****Step-by-Step: How I Did It

1. Lay the Foundation: VPC & Subnets

I created a custom VPC (10.0.0.0/16) with 6 subnets across 2 Availability Zones:

2 public (for Web EC2 + Public ALB)
2 private (for App EC2 + Internal ALB)
2 private (for RDS)

Then I ****added:

An Internet Gateway (for public access)
A NAT Gateway (so private instances can download packages)

Pro tip: Always enable DNS hostnames in your VPC—Next.js and Node.js need it.

***Lock It Down: Security Groups* I created 5 security groups that only trust each other:
- public-alb-sg → allows HTTP from the world
- web-ec2-sg → allows HTTP only from public-alb-sg
- internal-alb-sg → allows HTTP only from web-ec2-sg
- app-ec2-sg → allows port 3001 only from internal-alb-sg
- db-sg → allows MySQL only from app-ec2-sg

This “chain of trust” is the backbone of secure cloud architecture.

***Deploy the Database: RDS Done Right* I launched an RDS MySQL instance with:
- Multi-AZ (automatic failover if one zone dies)
- Read Replica (for scaling reads later)
- No public access (critical!)
- Initial database name: bookreview

**Mistake I made: I forgot to actually **create the bookreview database during setup. The app crashed with Unknown database 'bookreview'.

***Fix*: Connect via mysql CLI and run CREATE DATABASE bookreview;.

***Deploy the Backend (Node.js)* On a private EC2 instance:

git clone https://github.com/pravinmishraaws/book-review-app.git
cd backend
npm install

Then I created `.env`:
env
DB_HOST=your-rds-endpoint.us-east-1.rds.amazonaws.com
DB_NAME=bookreview
DB_USER=admin
DB_PASS=your-password
PORT=3001
ALLOWED_ORIGINS=http://your-public-alb-dns

>  Critical: `ALLOWED_ORIGINS` must match your **Public ALB DNS exactly**—no typos, no truncation.

I used `pm2` to keep the app running:
bash
sudo npm install -g pm2
pm2 start src/server.js --name "backend"
pm2 startup  # auto-start on reboot

5. ****Deploy the Frontend (Next.js)**
On a public EC2 instance:
bash
cd frontend
npm install
npm run build

Then I created `.env`:
env
NEXT_PUBLIC_API_URL=/api

This tells the frontend to send API requests to `/api`, which Nginx will proxy to the backend.

I ran it with:

bash
pm2 start npm --name "frontend" -- run start

***Configure Nginx: The Glue That Holds It Together* My /etc/nginx/sites-available/default:

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://localhost:3000;  # Next.js
        proxy_set_header Host $host;
    }

    location /api/ {
        rewrite ^/api/(.*) /$1 break;
        proxy_pass http://internal-alb-dns.us-east-1.elb.amazonaws.com;
        proxy_set_header Host $host;
    }
}

The magic:

User visits http://public-alb → sees Next.js

When they click “Login,” the frontend calls /api/login

Nginx forwards to Internal ALB → App EC2 → RDS

***Add Load Balancers & Auto Scaling*
- Public ALB: Routes traffic to Web EC2 instances
- Internal ALB: Routes /api to App EC2 instances
- Auto Scaling Groups: 2+ instances per tier, across 2 AZs

If one instance dies? AWS replaces it automatically.

**** The Struggle Is Real: Debugging Nightmares

**Problem 1: 403 Forbidden on ALB Health Checks
**Symptom: ALB shows “Unhealthy” targets.

Root cause:

My .env had ALLOWED_ORIGINS=http://alb...amazonaws> (truncated!)
Backend blocked all requests due to CORS mismatch.

***Fix*:

Corrected .env to full DNS: ...amazonaws.com
Added a /health endpoint for ALB health checks

**Problem 2: “Unknown database ‘bookreview’”
**Symptom: Backend crashes on startup.

Cause: RDS doesn’t auto-create databases unless you specify it.

***Fix*:


sql
mysql -h <RDS> -u admin -p
CREATE DATABASE bookreview;

****Problem 3: Nginx Serving Blank Page
****Symptom**: `curl localhost` returns 403.  
****Cause**: I was trying to serve static files from `/var/www/html`—but Next.js needs to run as a server.  
**Fix**: Switched to **reverse proxy** mode (`proxy_pass http://localhost:3000`).

****Lessons Learned (The Hard Way)

1. **Infrastructure is code—and configuration is state.**  
   One missing character breaks everything.
2. **Test each layer independently.**  
   - Can you `curl localhost:3000`?  
   - Can you `curl localhost:3001/api/books` from the backend?  
   - Does `mysql -h ...` connect?
3. **ALB health checks are strict.**  
   Use a dedicated `/health` route that always returns `200`.

4. **Security Groups are your first line of defense.**  
   If traffic isn’t flowing, check SG rules before touching code.

5. **Real DevOps isn’t about perfection—it’s about persistence.**  
   I failed 20 times. On the 21st, it worked.

****Final Result



1. 
A fully functional Book Review App  

2. 
 Survives instance termination  

3. 
 Scales across Availability Zones  

4. 
Secure, isolated, and production-ready  

And most importantly: **I understand how it all fits together.**

****Want to Try It Yourself?

**GitHub Repo**:  
[https://github.com/pravinmishraaws/book-review-app](https://github.com/pravinmishraaws/book-review-app)

****What You’ll Need**:
- AWS account (Free Tier eligible)
- Basic Linux & Git knowledge
- Patience (and maybe coffee)
Follow the READMEs in `/frontend` and `/backend`, and use this blog as your troubleshooting guide.
****Final Thought
Deploying this app didn’t just teach me AWS—it taught me **how to think like an engineer**.  
Not “Does it work?” but **“Why does it work—and what happens when it doesn’t?”**
That’s the real DevOps mindset.
Now go build something awesome. 
*Like this post? Give it a share, share it with a fellow learner, or comment below with your own deployment war stories!*  
#DevOps #AWS #CloudEngineering #FullStack #NextJS #NodeJS #LearningInPublic #RealWorldDev

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/brlx9i6cs2k0prpa2b5c.png)****

Executing a Full Scrum Sprint with Jira: From Backlog Refinement to Live Deployment

Ebelechukwu Lucy Okafor — Sat, 07 Feb 2026 05:52:48 +0000

This week, I executed a complete Scrum Sprint lifecycle using Jira Cloud (team-managed project) — covering backlog refinement, sprint planning, delivery, deployment, reporting, and retrospective.
The focus was not on theory, but on end-to-end execution: planning work, shipping a production change, and providing verifiable proof.

Project Context
Project: Gotto Job (UI-only enhancements)
Methodology: Scrum (Team-managed, Solo execution)
Core Tools: Jira Cloud, Git, GitHub, EC2 (Ubuntu), Nginx
Scope: Small, high-impact UI improvements delivered incrementally
Scrum Roles & Ownership (Solo Execution)

To mirror real delivery accountability, I assumed all Scrum roles:
Product Owner: Prioritized UI changes with the highest user-perceived value
Scrum Master: Enforced Scrum cadence (refinement → planning → sprint → retro)
Dev Lead: Implemented UI changes with clear acceptance criteria
DevOps Lead: Deployed changes to a live environment and validated delivery
Outcome: Clear separation of concerns, even in solo mode.
Backlog Refinement & Estimation
I created a structured product backlog under a single Epic:
Epic: Improve Gotto Job UI discoverability & trust
6+ user stories
Clear acceptance criteria
Fibonacci estimation (1/2/3)
Ranked by business value
This ensured the sprint scope was predictable and executable.

Sprint Planning (Sprint 1)
Defined a clear Sprint Goal
Selected 3–4 small, deliverable stories

Broke stories into actionable subtasks:
Build
Verify
Deploy
Screenshot (proof)
Focus: Deliver visible value, not partial work.

Delivery & Deployment (DevOps Execution)

One story from Sprint 1 was fully implemented and shipped:
Code changes committed with meaningful Git messages
Repository deployed on EC2 using Nginx static hosting
Live URL verified
Jira issues transitioned across the workflow to Done
Deployment proof attached

This followed a real DevOps loop:
Plan → Build → Ship → Verify → Document

Reporting & Transparency
Enabled and reviewed the Burndown Chart
Used Jira reports to track sprint health and scope
Ensured delivery visibility at all stages
Sprint Retrospective

A structured retro was documented, covering:

What went well
What to improve
Scrum pillar observed: Transparency
Scrum value demonstrated: Commitment
This reinforced continuous improvement, not just delivery.
Why This Matters (DevOps Perspective)
This sprint demonstrated practical capability in:
Agile execution with Jira (not checkbox usage)
Backlog refinement and estimation discipline
Shipping small, safe increments
Infrastructure + deployment ownership
Evidence-based delivery (live URL + Jira + GitHub)
Links
Live Deployment:
GitHub Repository: https://github.com/Lucycloud2024/GOTTO-JOB-DEMO

Final Note
This assignment strengthened my ability to operate in a real delivery environment, where planning, execution, deployment, and visibility are equally important.
I’m now comfortable contributing to teams that value small batches, fast feedback, and measurable delivery.

Creating and Managing Repositories on GitHub (With Git CLI Commands)

Ebelechukwu Lucy Okafor — Fri, 30 Jan 2026 06:43:13 +0000

If you have ever worked with code or followed a software project online, chances are you have come across GitHub. GitHub is a popular place for people to store code and work together on projects. The main thing that GitHub uses to organize all of this is something called a repository, or GitHub repository, which people often call a GitHub repo. A GitHub repository is a part of GitHub, and people use GitHub repositories to store their code and track changes to their code.

Knowing how repositories work is really important for developers and people who are just starting with version control.

They need to know how to manage them using GitHub and the command line.

This is a deal for developers, DevOps engineers and beginners who are learning version control with GitHub and the command line.

Repositories are a part of version control, and developers and beginners need to understand how they work with GitHub and the command line.

What Is a GitHub Repository?

A GitHub repository is like a place on the internet where you can store your project. This place has all your project files, like the code you write and the settings for your project. It also has things like a README file that tells people about your project. What is really cool about a GitHub repository is that it keeps track of every change you make to your files. It does this using something called Git, which is a system that helps you keep track of changes to your files. A GitHub repository is a tool because it uses Git to track these changes.

When you use Git, you can look at what changes were made, who actually made these changes and when these changes happened.

If something does not go as planned, you can easily go back to a previous version of Git.

Git repositories can be open for everyone to see. They can be private, which makes GitHub a good tool for open-source projects and for work that companies do privately with Git.

Creating a Repository on GitHub (Web Method)

To create a repository on GitHub:

Click the “+” icon at the top-right and select “New repository.”

Enter a repository name.

(Optional) Add a short description.

Choose Public or Private.

Check “Add a README file” (recommended).

Click “Create repository.”

When you make a repository on GitHub, GitHub gives you an address that you can use to link your computer to GitHub. This address is called the repository URL. You can use it to connect your local system to GitHub.

Creating a Repository Using Git CLI

A lot of developers like to use the command line. The command line is faster for them. It gives them more options. They can do things the way they want with the command line. The command line is really good, for developers because it is fast and it is flexible. Developers prefer the command line.

Step 1: Initialize Git in your project folder

git init

This command does something cool to your folder. It actually turns your folder into a Git repository. So now your folder is a Git repository.

Step 2. This is where you add your files to Git. You have to do this so that Git can keep track of the files. Add all the files you want to Git. This way, Git will know what files you are working with.

You are adding files to Git. This is a step. Make sure you add the files to Git.

To add all the files in the directory to git you should use the command git add.

This is what happens when you want Git to track all your files. It gets them ready, so Git can keep an eye on them. Git needs to track these files.

Step 3: Commit your changes

To start with, I will make my first git commit. The message for this git commit will be " commit". So the command for this git commit is git commit -m " commit". This git commit command is used to record the changes I made to my project.

When you make a commit, it saves a snapshot of your project at that moment. This snapshot is like a picture of your project. It shows exactly what your project looks like at that time. The commit saves this snapshot so you can look back at it later and see how your project was at that moment. This is really useful for keeping track of changes you make to your project over time. You can think of a commit as a way to save a copy of your project at a point in time.

Step 4: Connect your project to GitHub

To add a remote repository, you need to use the git remote add command. So you will do this by typing git remote add origin. Then you need to add the URL of your repository, which is https://github.com/username/repository-name.git.

So the full command is:

git remote add origin https://github.com/username/repository-name.git

Now we are at the step. This is Step 5. For Step 5 we need to push the code to GitHub. So the main task for GitHub, in Step 5 is to push the code to GitHub.

git branch -M main

git push -u origin main

Your local project is now uploaded to GitHub

How GitHub Repositories Work with Git

When you make a copy of a repository Git makes a copy of the project on your computer. This copy is the repository. The repository is what Git uses to keep track of the project. The project is stored in the repository. The repository is, like a folder that holds the project.

git clone https://github.com/username/repository-name.git

You can make changes to your work, on your computer then you can save these changes using commits. This way you can keep track of the changes you make to your work using commits.

git status

To add a file to git you need to use the command git add filename. When you type git add filename in the terminal you are telling git to add the filename file to the list of files that will be committed. The git add filename command is used to stage the filename file, which means it is preparing the filename file to be committed. You will use the git add filename command every time you want to add a file, such, as filename to your git repository. After you run git add filename you can then commit the filename file using the git commit command.

I just made a change, to the feature. I am going to save this with git commit and the message will be "Updated feature".

Finally, push your changes back to GitHub:

git push

This workflow is really helpful because it lets many people work on the project at the same time. The project workflow does this without letting people overwrite the work that other people have done on the project. This way the project workflow helps people to work together on the project.

Managing Files and Branches

When you are working on features branches are really helpful. They let you do this without messing up the code of the project. This way you can work on features and the main code at the same time and the main code will still work properly. Branches are very useful, for this reason.

Create a new branch

git branch feature-login

Switch to the branch

git checkout feature-login

(or)

git switch feature-login

After testing, merge it back into the main branch:

git checkout main

To combine the changes, from the feature login branch into the branch I will use the command git merge feature-login. This command will merge the feature-login branch into my branch. The feature-login branch contains all the new login features that I want to add to my project so I need to merge feature-login to get these features.

I will run the command git merge feature-login to do this. The git merge feature-login command is very important because it helps me to merge feature-login into my project.

Branches are really good for projects because they help keep everything organized. This way projects do not get all messy. Branches are very useful, for this purpose. They help people work on projects and keep them stable and organized which is what branches are supposed to do.

Collaboration Using Pull Requests

After pushing your branch to GitHub:

git push origin feature-login

You can open a Pull Request on GitHub. This is really helpful because your teammates can look at your code and tell you what they think. They can say what you should change. If it is good or not. This way, you can make sure your code is the best it can be. Pull Requests are a way to do this, and a lot of people use them for work and for open-source projects.

Useful Repository Management Tools

GitHub provides tools that make managing projects a lot easier. These tools help people work on projects together. GitHub has a lot of features that make project management easier. For example, GitHub has things like issue trackers and project boards that help people manage projects. GitHub is really useful for managing projects.

Issues Track bugs, tasks, and ideas

This is the README file for my project. It tells you what my project is about and what it does. My project is something I have been working on. I want to share it with you. The README file is where you can find all the information, about my project. It explains what my project does and how it works.

You need to control who can make changes to your code. This is about managing access to your code so you can decide who can edit it. Access control is important for your code. It helps you manage who can edit your code and who cannot.

I use GitHub Actions to automate things like testing and building my projects, and to make deployments easier. GitHub Actions is really helpful for automating these tasks. I do not have to do them manually every time. GitHub Actions automates testing. Deployments that save me a lot of time.

These tools are invaluable for your repository as it grows. Your repository can get really large. That is when these tools help it to keep going smoothly.

Creating and managing repositories on GitHub is a core skill in modern software development. Repositories help you store code, track changes, and collaborate efficiently. By learning both the GitHub interface and Git CLI commands, you gain full control over your projects. Whether you’re working alone or in a team, GitHub repositories form the foundation of effective version control and collaboration.

From Local Git Commits to a Live EC2 Website: Real DevOps Deployment

Ebelechukwu Lucy Okafor — Mon, 26 Jan 2026 07:32:00 +0000

DevOps stopped being abstract for me the moment my website went live on the internet.

As part of a hands-on DevOps assignment, I deployed a static portfolio website to an AWS EC2 Ubuntu server using Nginx, following production-style workflows instead of shortcuts. This wasn’t just about “making it work”; it was about doing it the right way.

In this post, I’ll walk through what I built, what broke, and what I learned while moving from local Git commits to a publicly accessible server.

Step 1: Laying the Foundation with Git
I started by creating a project called CodeTrack and initializing it as a Git repository.
Before writing any code, I focused on getting the basics right:

Initializing the repo correctly (git init)
Verifying repository state with git status
Understanding the role of the hidden .git directory
Configuring Git identity (local vs global)
This step taught me something important early on:
If your Git foundation is wrong, everything built on top of it becomes messy.

Step 2: Clean Commits, Not Just “Any Commit”
Instead of committing everything at once, I followed a real-world commit strategy:

First commit: UI scaffold (index.html, style.css)
Second commit: Small controlled content change (name, group, page text)
This mirrors how professional teams work. Small, focused commits make it easier to:

Review changes
Debug issues
Roll back safely if something goes wrong
Git stopped feeling like a requirement and started feeling like a safety net.

Step 3: Deploying to AWS EC2 with Nginx
Once the project was ready locally, it was time to deploy.

I connected to an Ubuntu EC2 instance using SSH key authentication and set up Nginx as the web server. The deployment flow looked like this:

Secure SSH access using a .pem key
Install and start Nginx
Copy project files from the local machine to EC2 using scp
Move files into Nginx’s web root
Verify deployment using:
curl -I http://localhost
Browser access via the EC2 public IP
Seeing my site load from a public IP was a big moment, that’s when it felt real.

Real DevOps Moment: Breaking and Fixing Things Safely
One part of the assignment required simulating a production failure.
I intentionally introduced a small syntax error into the Nginx configuration file and then:

Verified the failure using nginx -t
Diagnosed the issue
Fixed the configuration
Restarted Nginx safely
Confirmed recovery using curl
This exercise taught me a core DevOps lesson:

Breaking production is easy. Recovering safely is the real skill.

Challenges I Faced (And What They Taught Me)
I ran into multiple issues along the way, including:

Permission denied (publickey) errors during deployment
Incorrect SSH key paths
Missing file locations on the EC2 server
Each problem forced me to slow down, read errors properly, and understand why something failed instead of copying commands blindly. That process, not the deployment itself, was where the real learning happened.

Key DevOps Lessons I’m Taking Forward
Always verify before and after changes
Git discipline matters more than speed
SSH security is non-negotiable
Nginx validation (nginx -t) prevents outages
DevOps is about responsibility, not just automation
Final Outcome

✔ Website deployed and publicly accessible

✔ Nginx running and validated

✔ Clean Git commit history

✔ Real troubleshooting experience

This project strengthened my confidence in Linux, Git, AWS, and DevOps fundamentals, and it’s only the beginning.

live website

http://

Closing Thought

DevOps used to feel intimidating.
Now, it feels practical, logical, and powerful.

I’m excited to keep building one verified step at a time.