DEV Community: Ebelechukwu Lucy Okafor

Deploying Nginx with Argo CD on a Local Kubernetes Cluster: A Real-World GitOps Walkthrough kubernetes, Argo CD, gitops, devops

Ebelechukwu Lucy Okafor — Wed, 09 Sep 2026 07:42:50 +0000

Deploying Nginx with Argo CD on a Local Kubernetes Cluster — A Real-World GitOps Walkthrough

Most Argo CD tutorials show you a clean happy path: install, point it at a repo, watch it sync, done. That's useful for understanding the concept — but it doesn't prepare you for what actually happens when you build this on your own machine.
This post walks through a real deployment of Nginx to a local Kubernetes cluster (k3d) using Argo CD — including every infrastructure issue I hit along the way, why it happened, and how I fixed it. If you're learning GitOps, I think the debugging is actually the more valuable part.

Why GitOps, and why Argo CD
Traditional CI/CD is push-based: your pipeline authenticates to the cluster and runs kubectl apply or helm upgrade as its last

step. GitOps flips this to pull-based: a controller running inside the cluster (Argo CD, in this case) continuously watches a Git repository and reconciles the live cluster state to match what's declared there.

This has real, practical consequences:
Git becomes the source of truth. Want to know what's running in production? Read the repo, not the cluster.
Full audit trail. Every change is a commit — no more "who ran that kubectl command?"

Easy rollback. git revert is your rollback strategy.
No CI credentials in the cluster. CI only ever touches Git, never the cluster directly, tightening your security boundary considerably.
Drift detection and correction. If someone manually edits a resource, Argo CD notices and can revert it — this is called self-heal, and I'll demonstrate it later in this post.

Architecture overview

Developer → commits code → CI builds & pushes image → CI updates image tag in Git
│
▼
Config repo (Git)
│
Argo CD polls / receives webhook
│
▼
Diffs desired state vs live state
│
▼
Syncs Kubernetes cluster

Argo CD's core components: the API server (serves the UI/CLI), the repo server (clones and renders manifests), the application controller (the actual reconciliation loop), Redis (caching), and CRDs (Application, AppProject, ApplicationSet) that define what to track.

Setting up the local cluster

I used k3d — k3s running inside Docker containers — since it spins up fast and doesn't need a Linux host natively.
choco install docker-desktop kubernetes-cli k3d -y
k3d cluster create devcluster --servers 1 --agents 1 -p "8081:80@loadbalancer"

This should, in theory, "just work." In practice, I hit three separate infrastructure issues before the cluster came up healthy.
Issue 1 — Docker couldn't resolve external DNS
docker failed to pull the image 'ghcr.io/k3d-io/k3d-proxy:5.9.0':
dial tcp: lookup ghcr.io: no such host

Docker Desktop's internal DNS wasn't resolving external registries at all — a common issue caused by network config, VPNs, or a broken default resolver inside the WSL2 VM Docker runs on.
Fix: set an explicit DNS server in Docker Desktop's daemon config (Settings → Docker Engine):
{
"dns": ["8.8.8.8", "1.1.1.1"]
}

Verified with:
docker run --rm busybox nslookup ghcr.io

Issue 2 — kubelet refused to start (cgroup v1 vs v2)
Error: failed to validate kubelet configuration, error: kubelet is configured to not run on a
host using cgroup v1. cgroup v1 support is unsupported and will be removed in a future release

This one was buried under about a hundred repeating "connection refused" log lines — the real error was easy to miss. Modern k3s requires the unified cgroup v2 hierarchy, but my WSL2 environment was still exposing cgroup v1.
Fix: forced cgroup v2 via a WSL2 boot parameter.
wsl --update
wsl --shutdown

In %USERPROFILE%.wslconfig:
[wsl2]
kernelCommandLine=cgroup_no_v1=all

After restarting WSL2 and Docker Desktop, I confirmed the fix by checking for the v2 marker file:
docker run --rm busybox ls /sys/fs/cgroup

The presence of cgroup.controllers in the output confirms cgroup v2 is active (cgroup v1 exposes separate directories like cpu/, memory/, blkio/ instead).

*Issue 3 *— kubectl couldn't connect after everything looked fine
Unable to connect to the server: dial tcp 192.168.0.2:xxxxx: connectex:
No connection could be made because the target machine actively refused it.

The cluster and load balancer were both running and healthy — but kubectl was trying to reach host.docker.internal, which resolved to a LAN IP (192.168.0.2) instead of loopback. A quick Test-NetConnection -ComputerName localhost -Port confirmed the port was open on localhost — the hostname resolution was just wrong.
**Fix: **rewrote the kubeconfig to use localhost instead:
$config = Get-Content "$env:USERPROFILE.kube\config" -Raw
$config = $config -replace "host.docker.internal", "localhost"
Set-Content "$env:USERPROFILE.kube\config" -Value $config

After that:
kubectl get nodes

NAME STATUS ROLES AGE VERSION
k3d-devcluster-agent-0 Ready 19m v1.35.5+k3s1
k3d-devcluster-server-0 Ready control-plane 19m v1.35.5+k3s1

Cluster: finally healthy.

Installing Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Issue 4 — a CRD too large for client-side apply
The CustomResourceDefinition "applicationsets.argoproj.io" is invalid: metadata.annotations:
Too long: may not be more than 262144 bytes

kubectl apply's default client-side apply stores the entire applied configuration as an annotation on the object, and the ApplicationSet CRD is large enough to exceed Kubernetes' 262144-byte annotation limit. This is a known Argo CD installation quirk, not specific to my setup.

**Fix: **apply that CRD with server-side apply, which has the API server track field ownership instead of stuffing everything into an annotation:
kubectl apply --server-side --force-conflicts --validate=false --request-timeout=120s `
-f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/crds/applicationset-crd.yaml

Then restarted the dependent controller so it would pick up the newly available CRD:
kubectl rollout restart deployment/argocd-applicationset-controller -n argocd

All 7 Argo CD pods reached 1/1 Running after that.

Accessing the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

The initial admin password is auto-generated and stored as a base64-encoded Kubernetes Secret. Worth noting that kubectl get secret ... -o jsonpath only extracts the raw (still-encoded) value; it doesn't decode it:
$encoded = kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}"

Logged into https://localhost:8080 with admin and the decoded password.

Defining Nginx declaratively

nginx/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80

nginx/service.yaml

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: ClusterIP
selector:
app: nginx
ports:
- port: 80
targetPort: 80

Pushed both to a GitHub repo — this repo is now the only thing Argo CD needs to watch.
git init
git add .
git commit -m "Initial nginx manifests"
git branch -M main
git remote add origin https://github.com//.git
git push -u origin main

Creating the Argo CD Application
Via the UI: + NEW APP, filled in the repo URL, path (nginx), destination (https://kubernetes.default.svc, namespace default), and set Sync Policy to Automatic with Self Heal enabled.
Result:
Status: Healthy ✅ Synced ✅

Confirmed at the raw Kubernetes level too:
kubectl get pods -n default
kubectl get svc -n default

An unrelated but real infrastructure lesson: resource contention
Partway through, kubectl started throwing TLS handshake timeout on every command — including basic ones like kubectl get nodes. This turned out to have nothing to do with Argo CD or k3d directly:
docker stats --no-stream

CONTAINER CPU %
k3d-devcluster-server-0 260.04%
dev-cluster-control-plane 341.70%

An unrelated, unused kind cluster (dev-cluster-control-plane) had been left running from an earlier session, consuming more CPU than my actual working cluster — combined, they exceeded Docker Desktop's allocated CPU ceiling and starved the k3s API server of the resources it needed to respond to requests.
docker rm -f dev-cluster-control-plane

CPU pressure dropped immediately, and the cluster became responsive again. A good reminder to periodically audit what's actually running in Docker Desktop, especially on a resource-constrained laptop.

Proving the GitOps loop actually works
This is the part that matters most — everything above was just getting the environment ready to demonstrate this.

Automated sync from Git I changed replicas: 2 to replicas: 4 directly in the GitHub file editor and committed to main. Within Argo CD's poll interval, the Application flipped to OutOfSync, then automatically back to Synced as it applied the change — no kubectl command from me at any point. kubectl get pods -n default

NAME READY STATUS RESTARTS AGE
nginx-deployment-fd956d49d-8xcs8 1/1 Running 0 40m
nginx-deployment-fd956d49d-8xgcz 1/1 Running 0 46s
nginx-deployment-fd956d49d-dg9lz 1/1 Running 0 40m
nginx-deployment-fd956d49d-qzsf6 1/1 Running 0 46s

Four pods, matching Git — automatically.

Self-heal from manual drift To prove the reverse direction, I manually scaled the deployment down, bypassing Git entirely: kubectl scale deployment nginx-deployment -n default --replicas=1 kubectl get pods -n default -w

Kubernetes terminated three pods, leaving one running. Within seconds, Argo CD's reconciliation loop detected that live state (1 replica) no longer matched Git (replicas: 4), and created three new pods to restore it — automatically:
nginx-deployment-fd956d49d-zn4lh 1/1 Running 0 14s
nginx-deployment-fd956d49d-qgn44 1/1 Running 0 10s
nginx-deployment-fd956d49d-mvfnd 1/1 Running 0 11s

That's the core GitOps guarantee, demonstrated end-to-end: whatever happens to the live cluster- a bad manual command, a crashed pod, config drift of any kind- the system converges back to what's declared in Git.

Why Argo CD is efficient (not just trendy)
Having now built this from scratch and broken it a few times along the way, here's what actually stands out about Argo CD versus a traditional push-based pipeline:
Security boundary. CI never needs cluster credentials; it only ever needs write access to Git. That's a meaningfully smaller attack surface.
Auditability. Every deployment is a Git commit with a message and an author. No more digging through CI logs to figure out what changed and when.
Consistency at scale. With the "app of apps" pattern, adding a new microservice to your GitOps setup is just a new file in a repo — not a new pipeline to write and maintain.
Self-correction. Configuration drift — from a manual hotfix someone forgot to codify, or a partial failure during a rollout — gets corrected automatically instead of silently persisting.
Two clear states per app. Sync status (does live match Git?) and Health status (are the resources actually working?) give you a fast, unambiguous signal for every deployed service.

Closing thoughts
If you're learning Kubernetes and GitOps, I'd genuinely recommend doing this the "hard way" once — build it locally, and don't route around the errors when they show up. Every issue I hit here (DNS, cgroup versions, hostname resolution, CRD size limits, resource contention) is a real thing that happens in actual infrastructure work, just usually with higher stakes. Debugging it on a local cluster, where nothing is at risk, is the cheapest place to build that instinct.

If you found this useful, I write about Kubernetes, DevOps tooling, and cloud infrastructure — feel free to follow for more hands-on breakdowns like this one.

I Already Know This Stuff. That is Exactly Why I Am Documenting It.

Ebelechukwu Lucy Okafor — Tue, 04 Aug 2026 05:45:50 +0000

There is a version of Week 0 that would have felt completely foreign to me.

IP addresses, DNS, HTTP, TCP/IP, application architecture. For someone starting from zero, these concepts are a lot to absorb in one week. I remember what that felt like.

But I am not starting from zero.

I graduated from DMI Cohort 2 in May 2026. I was the App/Docker Lead for an 11-person team that deployed Spring PetClinic Microservices — 8 services, full CI/CD on AWS EKS, Prometheus scraping metrics every 15 seconds, Zipkin tracing requests across 4 services, alerts firing within 30 seconds of a service failure.

I have deployed on AWS. I have deployed on Azure. I have written Terraform modules, Ansible playbooks, GitHub Actions pipelines, and Kubernetes manifests. I know what a private subnet is because I put a MySQL database in one. I know what an A record is because I used one to point a domain to a VM's public IP.

So why am I doing Week 0 of Cohort 3 self-paced?

Because knowing something and documenting it clearly are two different skills. And the second one matters more for your career.

What Week 0 Actually Taught Me

Prompt Engineering is a Real Skill

Task 1 was writing a structured ChatGPT prompt to explain networking protocols. The key ingredients: context, specific question, format requirements, length constraints, and relevant background.

I have been doing this with AI tools — Claude Code and KIMCHI — since Cohort 2. But having a formal framework for it made me realise I was doing it intuitively without being able to explain why it worked. Now I can.

The discipline of a good AI prompt is identical to the discipline of a good Terraform variable definition. Be explicit. Constrain the output. Define expectations upfront. Garbage in, garbage out, whether you are talking to an LLM or provisioning cloud infrastructure.

Explaining Things Simply is Harder Than Doing Them

**Task 2 **asked me to explain packet switching, IP addresses, TCP/IP, and HTTPS in 100 to 150 words using the EpicReads bookstore scenario — a friend in Finland, customers in Nigeria.

I know all four concepts from production deployments. But fitting them into 150 words that a non-technical person could understand? That took four drafts. Every word had to earn its place.

Here is the version I ended up with:

When your friend's EpicReads website goes live in Finland, every device on the internet has a unique IP address — like a postal address. When a Nigerian user types the URL, DNS translates it to that Finnish IP address. The request does not travel in one piece. Packet switching breaks it into small chunks called packets. Each packet finds its own fastest route across the internet and they reassemble at the destination. TCP/IP manages this journey — TCP ensures every packet arrives, IP handles the routing between countries. HTTPS encrypts the conversation so no one between Nigeria and Finland can read the customer's payment details. That is how a click in Lagos reaches a server in Helsinki in under 200 milliseconds.

Architecture Diagrams Force Clarity

Two-tier versus three-tier. I have built both in production:

EpicBook on Azure: React frontend + Node.js backend + MySQL RDS in private subnet
Spring PetClinic: 8-service microservices with API Gateway, Config Server, Eureka, and 5 business services

The two-tier diagram is simple — frontend connects directly to database. The three-tier adds a backend layer that handles business logic between the two. The diagram does not capture the complexity of what I built. But it forces you to articulate the layers clearly — which is the foundation for understanding why microservices exist.

DNS in Production vs DNS in Theory

Task 4: connect epicreads.com to 52.172.142.222:3000 using the correct DNS record.

The answer is an A record. CNAME maps domain to domain — you cannot use it to point directly to an IP address. The port does not go in DNS at all. Nginx handles the port — accepting traffic on 80 or 443 and forwarding it internally to 3000. I did exactly this for EpicBook on Azure.

The theory confirms what I already knew from practice. That is the best kind of learning.

Why Public Documentation Matters

Every assignment gets pushed to GitHub. Every week adds a commit to my public portfolio. By the end of the self-paced programme alongside Cohort 3, I will have a documented, versioned record of everything I know, not just what I can do.

That is the difference between a developer who has done the work and one who can prove it, explain it, and teach it to someone else.

The work I did in Cohort 2 already proved I can build. This is me proving I can articulate.

If you are just starting DevOps, Cohort 3 is live now. What feels like fundamentals in Week 0 is what makes everything in Weeks 6 through 14 make sense.

**P.S. **This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/Lucycloud2024.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3

Building and Deploying Spring Petclinic Microservices on AWS: My Experience as Co-Project Lead and App & Docker Lead

Ebelechukwu Lucy Okafor — Wed, 17 Jun 2026 05:35:48 +0000

Introduction

As part of the DMI (DevOps Micro Internship) Cohort 2, our team successfully deployed the Spring Petclinic Microservices application on AWS using modern DevOps practices and cloud technologies.
Spring Petclinic is a microservices-based application that consists of multiple independent services working together through service discovery, centralised configuration, API gateways, monitoring, and observability tools.
This project provided valuable hands-on experience in containerization, cloud deployment, collaboration, troubleshooting, and DevOps workflows.
In this article, I will share my experience as the Co-Project Lead and App & Docker Lead, the tasks I completed, challenges I encountered, and the lessons I learned throughout the project.

Project Overview

Our objective was to deploy the Spring Petclinic Microservices application in a cloud environment while implementing DevOps best practices.

The application architecture included:
Config Server
Discovery Server (Eureka)
API Gateway
Customers Service
Visits Service
Vets Service
GenAI Service
Admin Server

We also integrated observability tools, including:
Prometheus
Grafana
Zipkin

These tools helped us monitor system health, application performance, and distributed tracing across services.

My Role in the Team
I served as:
Co-Project Lead
and
App & Docker Lead

My responsibilities included coordinating deployment activities and managing application containerization workflows.

Tasks I Personally Completed
**
**CONT-1: Validate Docker Compose Stack Locally
I validated the complete Docker Compose environment locally to ensure all microservices started correctly and remained healthy before deployment.

This involved:
Testing service startup order
Checking container health status
Validating network communication between services
Verifying application accessibility

CONT-2: Build Docker Images for Linux/AMD64
I built container images for all services targeting the Linux/AMD64 architecture.
This ensured compatibility with the AWS deployment environment.
Example command:
docker buildx build --platform linux/amd64 .

CONT-3: Tag Images with Git SHA
To improve version tracking and deployment consistency, I tagged container images using Git commit hashes.
Example:
docker tag petclinic-api-gateway:latest \
petclinic-api-gateway:

This approach provided traceability and easier rollback capability.

CONT-4: Authenticate Docker to Amazon ECR
I configured Docker authentication with Amazon Elastic Container Registry (ECR).
Example:
aws ecr get-login-password \
| docker login \
--username AWS \
--password-stdin

This enabled secure image publishing to AWS.

CONT-5: Push Images to Amazon ECR
After successful image builds and tagging, I pushed all application images to their respective ECR repositories.
This made the images available for deployment within AWS.

Key Technical Challenge

One of the biggest challenges was ensuring that all services were built successfully and could be deployed consistently.
Containerization can become complex when dealing with multiple services that depend on one another.
We had to carefully validate Docker images, verify service dependencies, and ensure proper communication between components.
Through collaboration, testing, and troubleshooting, we successfully resolved deployment issues and achieved a stable environment.

Technologies Used

During the project, we worked with:
Docker
Docker Compose
Amazon ECR
AWS Cloud Services
Spring Boot
GitHub
Prometheus
Grafana
Zipkin

These tools helped us implement a complete DevOps workflow from development through deployment and monitoring.

What I Learned

This project reinforced several important DevOps concepts:
Containerization
I gained deeper experience building, tagging, and managing Docker images for microservices.
Team Collaboration
Working with teammates taught me the importance of communication, task ownership, and coordination.
Cloud Deployment
I improved my understanding of deploying containerised applications within AWS environments.
Observability
Using Prometheus, Grafana, and Zipkin showed me how monitoring and tracing help identify issues and maintain application reliability.

What I Would Do Differently

If repeating this project, I would:
Automate more deployment tasks using CI/CD pipelines
Implement Infrastructure as Code more extensively
Enhance monitoring dashboards
Improve deployment documentation for faster onboarding
These improvements would increase scalability and operational efficiency.

Final Thoughts
Participating in DMI Cohort 2 was a valuable experience that strengthened both my technical and collaboration skills.
As Co-Project Lead and App & Docker Lead, I gained practical experience in Docker, AWS, container registries, cloud deployment, and observability tools.
Most importantly, I learned how effective teamwork contributes to the success of complex DevOps projects.
If you are interested in gaining real-world DevOps experience, DMI Cohort 3 starts on 27 June 2026.
Apply here:
https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform

DMI #DevOps #AWS #Docker #Microservices #CloudComputing #Prometheus #Grafana #Zipkin #TheCloudAdvisory

Deploying Spring Petclinic Microservices with Docker Compose: A Complete DevOps Walkthrough

Ebelechukwu Lucy Okafor — Tue, 16 Jun 2026 05:15:49 +0000

Introduction

As part of my DevOps learning journey in DMI Cohort 2, I deployed the Spring Petclinic Microservices application locally using Docker Compose.

Spring Petclinic is a cloud-native microservices application designed to demonstrate modern software architecture patterns. Instead of a single monolithic application, the system consists of multiple independent services that communicate with one another.

The deployment includes:

Config Server
Discovery Server (Eureka)
API Gateway
Customers Service
Visits Service
Vets Service
GenAI Service
Admin Server

In addition, the application includes a complete observability stack:

Prometheus
Grafana
Zipkin

The goal of this project was to deploy, verify, monitor, and troubleshoot a production-style microservices environment using Docker Compose.

Prerequisites

Before deployment, I installed and configured the following tools:

Docker

Docker was used to build and run all application containers.
Verify installation:
docker --version

Git

Git was used to clone and manage the repository.
Verify installation:
git --version

GitHub Codespaces

I used GitHub Codespaces as my development environment because my AWS account was unavailable during this project.

Step 1: Clone the Repository

I cloned the Spring Petclinic Microservices repository:
git clone https://github.com/PETCLINIC-PROJECT-GROUP-5/spring-petclinic-microservices.git

Navigate into the project:
cd spring-petclinic-microservices

Verify the repository contents:
ls

The repository contained all required microservices, Docker Compose configuration, Kubernetes manifests, and supporting documentation.

Step 2: Start the Application

The entire application can be deployed using a single command:
docker compose up -d

This command performs several tasks:

Pulls required Docker images
Creates containers
Creates a Docker network
Starts services in the background

After execution, Docker reported that all containers started successfully.
Particularly important were:
config-server
discovery-server
Both services became healthy before the remaining services started.

Why Config Server and Discovery Server Start First

The Config Server provides centralised configuration for all microservices.

The Discovery Server (Eureka) allows services to register themselves and discover other services dynamically.

Without these services running first:
Application services cannot load the configuration
Services cannot register with Eureka
Inter-service communication may fail
Docker Compose uses startup dependencies and health checks to ensure the correct startup sequence.

Step 3: Verify Running Containers

To verify deployment status, I ran:
docker compose ps

This displayed all running containers and their health status.
Services included:
config-server
discovery-server
api-gateway
customers-service
visits-service
vets-service
genai-service
admin-server
prometheus-server
grafana-server
tracing-server
All services reported a healthy or running status.

Step 4: Application Verification

After deployment, I verified each application endpoint.

Spring Petclinic
http://localhost:8080

The main application loaded successfully.
Eureka Dashboard
http://localhost:8761

Displayed all registered services.
Spring Boot Admin
http://localhost:9090

Provided centralized monitoring of Spring Boot applications.
Zipkin
http://localhost:9411

Displayed distributed traces across services.
Prometheus
http://localhost:9091

Collected and displayed application metrics.
Grafana
http://localhost:3030

Visualised metrics through dashboards.

Observability Stack
One of the most valuable parts of this project was understanding observability.

Prometheus
Prometheus collected metrics from application services.
I executed queries such as:
http_server_requests_seconds_count

This provided visibility into application requests and performance.

Grafana
Grafana converted Prometheus metrics into visual dashboards.
I was able to monitor:
Service health
Request counts
Response times
Application activity

Zipkin
Zipkin provided distributed tracing.
This allowed me to follow a request as it travelled through multiple microservices.
It demonstrated how modern cloud-native applications handle service-to-service communication.

Biggest Challenge
The most challenging part of this project was troubleshooting Docker in GitHub Codespaces.
Initially, the Codespace entered recovery mode because of container configuration issues.
Although Docker commands were installed, Docker could not connect to the daemon.

As a result:
Docker image builds failed
Docker Compose could not start containers
After reviewing the devcontainer configuration, rebuilding the Codespace environment, and validating Docker daemon connectivity, I successfully resolved the issue.
This experience improved my troubleshooting skills and deepened my understanding of Docker architecture.

Stopping and Cleaning Up
After completing verification and testing, I stopped the environment using:
docker compose down

This command:
Stops containers
Removes containers
Removes Docker networks
Free system resources

Cleaning up environments is an important DevOps practice.

Key Lessons Learned

This project taught me several valuable DevOps concepts:
Microservices architecture
Containerization with Docker
Service discovery using Eureka
Centralized configuration management
Observability using Prometheus, Grafana, and Zipkin
Troubleshooting Docker environments
Deploying and managing multi-container applications

Most importantly, I learned that successful DevOps work involves not only deployment but also monitoring, troubleshooting, and maintaining system reliability.

DMI Cohort 2 Experience
This project was completed as part of DMI Cohort 2.
The hands-on nature of the program provided practical experience with real-world DevOps tools and deployment workflows.

If you're interested in learning DevOps through practical projects, DMI Cohort 3 registration is open:
https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform
Thank you for reading, and happy learning!

Kubernetes Services & Networking — My Week 15 Hands-On Journey (ClusterIP, NodePort, LoadBalancer)

Ebelechukwu Lucy Okafor — Tue, 28 Apr 2026 06:50:08 +0000

If you’ve ever deployed an app on Kubernetes and thought:
“Okay… my Pods are running, but how do I actually reach them?”
Then you’re exactly where I was this week.
In this hands-on lab series, I explored one of the most important

Kubernetes concepts:
Services & Networking

I didn’t just read about it, I built, broke, tested, and fixed things myself.
Let me walk you through what I learned
Why Kubernetes Services Matter (Simple Explanation)

Think of Pods like people living in apartments:

They come and go (ephemeral)
Their “room numbers” (IP addresses) change
You can’t rely on reaching them directly

Kubernetes Services act like a reception desk:

One stable address
Routes requests to the right Pods
Only sends traffic to “healthy” Pods

Lab 7 — ClusterIP (Internal Communication)

What I Did

Created an NGINX Deployment with 2 replicas
Added labels (app: nginx) to connect Pods with Services
Created a ClusterIP Service

Verified:

Service IP
Endpoints
DNS resolution inside the cluster
Tested communication using a BusyBox test pod
Key Commands I Used
kubectl apply -f nginx-deployment.yaml
kubectl apply -f clusterip-service.yaml

kubectl get svc
kubectl get endpoints

kubectl run tester --image=busybox --restart=Never -- sleep 3600
kubectl exec -it tester -- wget -qO- http://nginx-clusterip
What I Learned
ClusterIP is internal-only (perfect for microservices)
Services use labels + selectors to find Pods
Only READY Pods receive traffic
Issue I Faced
Initially confused why traffic failed

How I Solved It

Checked:
kubectl describe svc nginx-clusterip
kubectl get endpoints

Realized:
Service works only if labels match Pods

Lab 8 — NodePort (External Access)

What I Did
Created a NodePort Service
Exposed my app on port 30080
Checked node IP
Tried accessing from browser
Key Commands
kubectl apply -f nodeport-service.yaml
kubectl get svc nginx-nodeport
kubectl get nodes -o wide

Issue I Faced
curl http://localhost:30080
❌ Failed to connect

Why It Happened

I was using:
WSL + kind cluster
NodePort doesn’t always work directly on localhost in this setup

How I Solved It

Option 1: Port Forward (Worked instantly)
kubectl port-forward svc/nginx-nodeport 8080:80

Then opened:
http://localhost:8080
Option 2: Internal Testing (Best Practice)
kubectl run tester --image=busybox --restart=Never -- sleep 3600
kubectl exec -it tester -- wget -qO- http://nginx-nodeport

What I Learned
NodePort exposes app via:
:

Works great for:
Local labs
On-prem setups
But depends on the network environment

Lab 9 — LoadBalancer (Cloud Simulation)

What I Did
Created a LoadBalancer Service
Applied it in my local environment

Observed:
EXTERNAL-IP stayed
Key Commands
kubectl apply -f loadbalancer-service.yaml
kubectl get svc
Issue I Faced
EXTERNAL-IP:

Why It Happened
I was NOT using cloud (like Microsoft Azure or AWS)
LoadBalancer needs a cloud provider integration
How I Solved It
Used Port Forward to simulate access
kubectl port-forward svc/nginx-loadbalancer 8080:80

Learned Alternative Options
Use:
Minikube tunnel
MetalLB (bare metal)
Or a real cloud like Microsoft Azure (AKS)

What I Learned
LoadBalancer gives:
Public IP
Internet access
But only works with:

Cloud providers (AKS, EKS, GKE)
Real DevOps Insight (This Changed My Understanding)
Before this lab, I thought:
“Services are just networking configs…”

Now I understand:
Services are the core of Kubernetes communication
Everything depends on them:
Microservices
APIs
External traffic
Load balancing
Real-World Application
Here’s how this applies in real DevOps work:
ClusterIP
→ Backend services talking internally
NodePort
→ Testing apps before production
LoadBalancer
→ Production apps exposed to users

My Reflection

The biggest lesson for me:
Kubernetes is not just about running containers…
It’s about making them reachable, scalable, and reliable
This lab made everything click.

Final Thoughts

If you're learning Kubernetes:
Don’t just watch tutorials
Break things. Test things. Fix things.
That’s where real understanding comes from.

Let’s Connect
If you're also learning DevOps or Kubernetes, I’d love to connect and share ideas!
What part of Kubernetes confused you the most?
Have you tried exposing apps yet?
Drop a comment

kubernetes #devops #cloudcomputing #learninginpublic #100daysofcode #azure #containers #docker #beginners

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.