DEV Community: Duru Juliet Chinenye

production-grade deployment of The Epic Book, a Node.js + MySQL web application on AWS

Duru Juliet Chinenye — Thu, 23 Apr 2026 15:45:25 +0000

Just deployed a full-stack web application to AWS using Terraform + Ansible.

As part of my cloud engineering journey, I completed a

Here's what I built from scratch:

Infrastructure (Terraform)
• VPC, public subnet, internet gateway, and route tables
• Security groups with control
• Ubuntu 22.04 EC2 instance with SSH key authentication
• All infrastructure destroyed and recreated in minutes; that’s the power of IaC

Configuration Management (Ansible)
• 3 clean, reusable roles: common → nginx → epicbook
• Nginx configured as a reverse proxy in front of Node.js
• MySQL provisioned and configured automatically
• PM2 process manager keeping the app alive
• Fully idempotent: re-running the playbook shows zero failures

Result: A live, browser-accessible web app served over HTTP with nginx proxying to a Node.js backend connected to MySQL, all automated, repeatable, and production-ready.

Challenges I overcame:
• The app wasn't a static site; it had to switch from file serving to a full reverse proxy setup
• MySQL authentication required, matching the app's config exactly
• Port conflicts on re-runs taught me the importance of clean state management in automation

What this taught me: Real deployments are never just "run a script, and it works." They require understanding full-stack networking, web servers, application runtimes, databases, and process management and how they all connect.

This is exactly how production engineering teams operate, and I'm proud to have built it end-to-end.
Tech used: AWS EC2 · Terraform · Ansible · Nginx · Node.js · MySQL · PM2 · Ubuntu 22.04
I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana ,Mobarak Hosen,Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #Terraform #Ansible #CloudEngineering #IaC #Linux #Nginx #NodeJS #MySQL #LearningInPublic #CloudComputing #Infrastructure

Deployment of a Mini Finance Dashboard using Terraform and Ansible

Duru Juliet Chinenye — Thu, 23 Apr 2026 15:03:38 +0000

Deployed the Mini Finance Dashboard this week using Terraform and Ansible.

Here is what I built:
Provisioned an AWS EC2 instance using Terraform
Created VPC, Subnet, Internet Gateway and Security Groups as code
Configured passwordless SSH access with ED25519 keys
Used Ansible roles to install Nginx, Node.js, MySQL
Deployed the Mini Finance Dashboard, fully accessible from any browser
Verified the site loads live with HTTP 200 ✓
The best part? The entire infrastructure is code. I can destroy it and rebuild it in minutes. That is the power of doing it right.
Terraform handles the infrastructure. Ansible handles the configuration.
Real problems I hit and pushed through:
Nginx returned 403. The app is Node.js, not static files. Reconfigured as a full reverse proxy and kept moving

MySQL auth was failing; credentials had to match the app config exactly. Fixed native password authentication and moved on

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana ,Mobarak Hosen,Onuche Paul and Nkechi Anna Ahanonye

DevOps #AWS #Cloud #Terraform #Ansible #Linux #Ubuntu #NodeJS #MySQL #Nginx #MiniFinanceDashboard #Infrastructure #ShipIt #CareerGrowth #Tech

Deploying a full, three-tier book review web app on Azure

Duru Juliet Chinenye — Mon, 16 Mar 2026 05:52:00 +0000

I designed and deployed one of my most hands-on cloud engineering projects: deploying a secure, scalable book review application using a full three-tier architecture on Microsoft Azure.
But the real growth came from the challenge I hit along the way and how I solved it.

The Problem I Encountered
After deploying the backend (Node.js/Express) for the book review app in private subnets, the frontend couldn’t reach it.
The internal load balancer was healthy, and the backend was running on port 3001, but every request from the frontend timed out.
Everything looked correct: subnets, routes, health probes, VM status—yet the app simply wouldn’t connect.

How I Solved It
The issue turned out to be a Network Security Group (NSG) misconfiguration.
The App Tier NSG wasn’t allowing inbound traffic from the Web Tier on port 3001, even though the internal load balancer was configured correctly.

I fixed it by:
•Updating the App Tier NSG
•Allowing inbound traffic only from the Web Tier NSG
•Opening port 3001 specifically for internal communication
As soon as that rule was added, the Book Review app connected instantly.
This experience reinforced a key lesson: Azure NSGs don’t assume trust; you must define it explicitly.

What I Built
Here’s the full architecture behind the book review app:
Frontend (Web Tier)
•Next.js served via Nginx on Ubuntu
•Behind a Public Azure Load Balancer
•Lives in public subnets only
Backend (App Tier)
•Node.js/Express API on port 3001
•Deployed in private subnets
•Accessible only through an Internal Load Balancer
Database (Data Tier)
•Azure Database for MySQL Flexible Server
•Multi-AZ high availability
•Read replica for scaling
•NSGs allowing only App Tier traffic on port 3306
Networking
•Custom VNet (10.0.0.0/16)
•6 subnets across 2 zones
•Strict NSGs per tier
•No public exposure for backend or database

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana and Mobarak Hosen

CloudEngineering #Azure #DevOps #Nextjs #Nodejs #MySQL #ThreeTierArchitecture #CloudSecurity #AzureNetworking #LoadBalancing #FullStack #CloudProjects #TechJourney #MicrosoftAzure #CloudArchitect #BookReviewApp #DuruBuildsCloud

Deploying the Epic Book Web App on Azure: End-to-End, Production-Ready Architecture

Duru Juliet Chinenye — Mon, 16 Mar 2026 03:28:25 +0000

I just wrapped up one of my most comprehensive cloud engineering projects: designing, securing, and deploying a full-stack Epic Book web app on Microsoft Azure using real production patterns.
This project pushed me far beyond “just deploy a VM.”
I had to think like an architect: networking, security, scalability, and infrastructure design all mattered as much as the code itself.
Frontend Layer
I built a React frontend that communicates with an Express.js API over HTTPS.
The backend runs on port 5000, giving me a clean separation between UI, API, and infrastructure.
Application Layer (Public Subnet)
I deployed a Node.js + Nginx web server on Ubuntu 22.04, placed behind an Azure Load Balancer with a public IP.
To keep things secure, I locked down the Web NSG to ports 80 and 22 only and assigned a dedicated public IP + NIC for full network control.
Nginx handles reverse proxying to Node.js, improving performance and security.
Database Layer (Private Subnet)
For the database, I used Azure Database for MySQL Flexible Server (epiSQ-db).
It sits in a fully private subnet with zero public exposure.
•DB NSG allows only port 8006
•MySQL port 3306 is accessible only from within the VNet (10.0.0.0/16)
This ensures the database is completely isolated from the public internet.
Security-First Architecture
Security guided every decision I made:
•Private subnet isolation for the database
•Strict NSG rules on both web and DB layers
•Load Balancer as the only public entry point
•Zero-trust approach to MySQL access
•Controlled, predictable traffic flow end to end
Traffic Flow
Internet → Load Balancer → Web VM → MySQL Flexible Server
My Biggest Takeaway
This project reminded me that cloud engineering is more than writing code.
It’s about understanding how your application lives in the cloud, how it’s secured, how it scales, and how every component communicates.
If you're a developer looking to level up, start thinking beyond your local machine. The cloud is where your application truly becomes real.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana and Mobarak Hosen

High Availability (HA) two-tier web application architecture on AWS

Duru Juliet Chinenye — Thu, 26 Feb 2026 15:14:09 +0000

I completed a full High Availability (HA) WordPress architecture on AWS, built using production-grade DevOps patterns across multiple Availability Zones.
Core Architecture:
• Multi AZ VPC with public + private subnets, IGW, NAT
• Application Load Balancer distributing traffic across AZ a and AZ b
• Auto Scaling Group using a Launch Template with automated user data to install/configure WordPress
• RDS Multi AZ MySQL deployed in private subnets with SG to SG access only
• Security Group chaining enforcing strict east-west flow: Internet → ALB → EC2 → RDS
Automation & Self Healing:
• EC2 instances bootstrap WordPress automatically (runtime install, config, DB connection)
• ASG replaces failed instances without manual intervention
• ALB health checks ensure only healthy nodes receive traffic
HA Validation:
• Terminated EC2 instances → ASG launched replacements automatically
• Simulated AZ disruption → ALB continued serving traffic from the remaining AZ
• WordPress remained fully available throughout all tests
This project demonstrates end-to-end HA design: resilient networking, automated compute, fault-tolerant database, and real failure testing—key capabilities for modern Cloud/DevOps engineering.

three-tier web application architecture

Duru Juliet Chinenye — Thu, 26 Feb 2026 15:03:48 +0000

I engineered and deployed a High Availability (HA) three-tier web application architecture on AWS, built inside a VPC spanning multiple Availability Zones to ensure continuous uptime and fault tolerance. The design uses public, private application, and private database subnets, enforcing strict network isolation and enterprise-grade security.
The public tier hosts an internet-facing Application Load Balancer (ALB) that distributes traffic across AZs and performs real-time health checks. The application tier runs on EC2 instances inside private subnets, orchestrated by an Auto Scaling Group (ASG) with launch templates for consistent, repeatable deployments. The database tier uses Amazon RDS MySQL configured for Multi AZ failover, automated backups, and private-only access.
To validate the architecture’s resilience, I performed controlled failure testing by manually terminating active EC2 instances. The ASG immediately replaced them, and the ALB seamlessly routed traffic to healthy targets with zero downtime. The application remained fully accessible throughout the test, confirming the system’s ability to self-heal, scale automatically, and maintain strict tier isolation.
This deployment demonstrates my ability to design and operate production-ready, secure, and fault-tolerant cloud architectures aligned with modern DevOps and AWS best practices.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana, Mobarak Hosen, Onuche Paul

S #CloudArchitecture #DevOps #SolutionsArchitect #CloudComputing #AWSArchitecture #Tech #AWS, #CloudComputing, #DevOps, #CloudEngineering, #AWSSolutionsArchitect

HighAvailabili #ThreeTierArchitecture#TechCareer, #Hiring

#Recruiters #OpenToWork #ScalableArchitecture, #InfrastructureAsCode

and

Deploying a Static Website on Amazon S3

Duru Juliet Chinenye — Mon, 16 Feb 2026 03:51:33 +0000

Over the past few days, I completed a practical cloud engineering exercise: deploying a static website using Amazon S3.

This simple project taught me essential concepts around cloud storage, permissions, hosting, and real‑world deployment workflows.

In this article, I’m sharing the exact steps I followed, what I learned, and why this exercise is valuable for anyone building cloud or DevOps skills.

Creating the S3 Bucket**

I started by creating a new S3 bucket that would host my website files.

I ensured the bucket name was globally unique and selected the correct AWS Region.

This bucket became the storage location for all my HTML, CSS, and image files.

Uploading the Website Files**

Next, I uploaded the contents of my portfolio template.

A key lesson here: S3 requires index.html to be at the root level, not inside a folder.

I uploaded:

index.html
CSS files
Images and asset folders
Additional HTML pages

Once uploaded, I confirmed everything appeared correctly in the Objects tab.

Enabling Static Website Hosting

To turn the bucket into a functioning website, I enabled:

Properties → Static website hosting

I selected “Host a static website” and entered:

Index document:** index.html

AWS then generated a Website Endpoint URL, which acts as the public link to the site.

Making the Website Public**

By default, S3 buckets are private.

To allow public access, I updated two things:

a. Block Public Access Settings**
I ensured that “Block all public access” was turned off for this assignment.
b. Bucket Policy**
I added a policy that allows public read access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::pravin-portfolio-duru-eu-west-2/*"
    }
  ]
}

This step ensures that anyone can load the website files in their browser.

Testing the Website Endpoint

I opened the S3 Website Endpoint in my browser to verify that the site loaded correctly.

A quick hard refresh (Ctrl + F5) helped clear cached versions.

Seeing the homepage appear confirmed that:

Hosting was enabled
Permissions were correct
index.html was in the right place

This was the moment the deployment became real.

Updating and Redeploying

To simulate a real DevOps workflow, I made a small change to the homepage text in index.html, saved the file, and re‑uploaded it to S3.

AWS automatically overwrote the previous version.

Refreshing the website showed the updated content — a simple but powerful demonstration of the edit → deploy → verify cycle used in real CI/CD pipelines.

What I Learned

This project reinforced several important cloud engineering concepts:

Cloud storage structure matters
Permissions determine accessibility
Static hosting requires explicit configuration
Deployment is a repeatable workflow
Small changes require redeployment
Testing and verification are essential

Even though S3 hosting is simple, it teaches foundational skills that scale into more advanced cloud and DevOps practices.

Final Thoughts**

Deploying a static website on S3 is a great beginner‑friendly cloud project.

It builds confidence, strengthens understanding of AWS services, and mirrors real‑world deployment workflows.

I’m excited to continue building, learning, and sharing my cloud journey — one project at a time.

I want to sincerely thank my mentors,Pravin Mishra, Praveen Pandey, Abhishek Makwana and Mobarak Hosen
This post is part of the DevOps Micro Internship (DMI) Cohort 2 by Pravin Mashra

AWS #CloudComputing #DevOps #AmazonS3 #WebDevelopment

CloudEngineering #StaticWebsiteHosting #WomenInTech

LearningInPublic #TechJourney

DevOps lifecycle

Duru Juliet Chinenye — Fri, 13 Feb 2026 12:58:02 +0000

DevOps Micro‑Internship: Setting Up My Delivery Workflow
Today I completed the first practical task of the DevOps Micro‑Internship, and it was a full end-to-end workflow that mirrors how real engineering teams deliver software.
Here’s what I accomplished:
🔹 Set Up My Local Development Environment
Cloned the Pravin Mishra Portfolio Template repository and created a dedicated feature branch:
feature/footer-v1
This ensured I followed a clean, professional Git workflow.
🔹 Made My First UI Increment
Opened the project in VS Code and added the required footer text to the homepage.
Committed the change using a semantic commit message to keep history clean and traceable.
🔹 Deployed to My EC2 Instance
Uploaded the updated files using SCP, served them via Nginx, and verified the change live at:
👉 http://35.176.28.156
🔹 Updated Jira to Reflect Real Delivery Flow
Moved my Day 1 sub‑task from To Do → In Progress → Done
Added my Daily Scrum comment to the Story to maintain visibility and accountability.

What I Learned
• How to follow a real DevOps workflow: code → commit → deploy → verify
• Why all work should be done locally, not directly on EC2
• How to deploy static website changes using SCP + Nginx
• How to troubleshoot server issues (missing Nginx, missing directories, permissions)
• How to track work professionally in Jira using subtasks, sprint goals, and Daily Scrum updates
• The value of shipping small, visible increments instead of waiting for a big final change
• How to validate deployments by checking the live URL
This experience reinforced something I believe strongly:
DevOps is not just about tools — it’s about discipline, clarity, and delivering value in small, reliable steps.

I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana and Mobarak Hosen
This post is part of the DevOps Micro Internship (DMI) Cohort 2 by Pravin Mashra
hashtag

hashtag#DevOps hashtag#Scrum hashtag#Agile hashtag#Jira hashtag#Cloud hashtag#EC2 hashtag#Nginx hashtag#Git hashtag#SoftwareEngineering hashtag#LearningInPublic hashtag#ContinuousImprovement

Deploying a React Application on an Ubuntu EC2 Server (AWS) Using Nginx

Duru Juliet Chinenye — Thu, 22 Jan 2026 02:15:36 +0000

Overview
I successfully completed a remote Linux deployment project as part of DMI Cohort 2. In this project, I deployed a React application on an Ubuntu EC2 instance and served it through Nginx. The workflow covered end‑to‑end server setup, secure SSH access, installation of Node.js and Nginx, building the React application for production, and configuring Nginx to serve the optimized build. This experience strengthened my confidence in Linux administration, cloud deployment practices, and real‑world DevOps workflows

Prerequisites
An AWS account with permission to create EC2 instances
Linux commands (cd, ls, nano, sudo, etc.)
An SSH client such as Git Bash
Internet access for package installation and AWS connectivity
A React project that is ready for a production build

Step 1: Launching an Ubuntu EC2 Instance
I start by logging into the AWS Console and navigating to EC2.
From there, I launch a new instance and configure it with the following settings:
Name: react-app-server
AMI: Ubuntu Server 22.04 LTS
Instance type: t2.micro (Free Tier eligible)
Key pair: I create a new key
Network settings:
Allow SSH (22)
Allow HTTP (80)
Once the instance is running, I take note of the public IPv4 address because I’ll need it throughout the deployment.

Step 2: Connecting to the Server via SSH
After the instance is ready, I connect to it securely using SSH.
I ensure my key file has the correct permissions, and then I authenticate into the server using the public IP address.

Step 3: Installing Node.js, Nginx, and Required Build Tools
The first thing I do on the server is update the package list and install the tools I need.
I install Node.js (LTS version) because I’ll use it to build the React application.
Next, I install Nginx, which will serve the production build.
I enable and start Nginx so it runs automatically whenever the server boots.
At this point, I put the server’s public IP address in a browser, and I see the default Nginx welcome page. That confirms Nginx is running correctly.

Step 4: Configuring Nginx to Serve the React Application
With the production build ready, I configure Nginx to serve it. After testing the configuration, I reload Nginx. Once Nginx restarts, my React application becomes accessible through the server’s public IP address.

Step 6: Validating the Deployment
Finally, I open a browser and navigate to the server’s public IP address.
At this point, I see my React application running in production mode, served cleanly through Nginx.

Grateful to the DMI Cohort 2 community and mentors Pravin Mishra, Praveen Pandey, Abhishek Makwana, and the entire DMI community for the guidance and support throughout this Linux-focused session.
hashtag#Linux hashtag#AWS hashtag#EC2 hashtag#ReactJS hashtag#Nginx hashtag#DevOps hashtag#CloudComputing hashtag#DMICohort2 hashtag#MicroInternship