DEV Community: Daniel Inyang

🚀 End-to-End Deployment of “The EpicBook!” Application with Terraform, AWS, and Nginx

Daniel Inyang — Fri, 10 Apr 2026 14:20:42 +0000

Building and deploying real-world applications goes far beyond just writing code—it involves provisioning infrastructure, configuring services, and solving unexpected issues along the way. In this project, I implemented a complete end-to-end deployment of The EpicBook! application using Terraform, AWS EC2, and Nginx, while handling real-world challenges across the stack.

🧩 Project Overview

The goal was to deploy a full-stack application in a production-style environment, leveraging Infrastructure as Code (IaC) to ensure consistency, scalability, and repeatability.

This project covered:

Infrastructure provisioning
Backend and database setup
Reverse proxy configuration
End-to-end testing and troubleshooting

⚙️ 1. Infrastructure as Code with Terraform

I used Terraform to provision the core AWS infrastructure required to run the application. This included:

EC2 instance deployment
Networking configuration
Public IP allocation

By defining everything in code, I eliminated manual setup steps and ensured the environment could be recreated reliably at any time.

🧱 2. System Setup & Dependencies

Once the infrastructure was ready, the next step was preparing the server environment:

Installed Git for version control
Installed Node.js using NVM for flexibility
Installed npm for package management
Set up MySQL Server 5.7

Careful validation was done to ensure all services were installed correctly and running as expected.

📦 3. Application Deployment

With the system ready, I deployed the application:

Cloned The EpicBook! repository from GitHub
Installed dependencies using npm install
Started the Node.js backend server

This brought the application logic to life on the server.

🗄️ 4. Database Configuration

The database layer was configured to support the application:

Created a MySQL database
Executed schema and seed scripts
Updated the application’s database connection settings

This ensured proper communication between the backend and the database.

🌐 5. Reverse Proxy Setup with Nginx

To make the application accessible externally and production-ready:

Installed and configured Nginx
Set up a reverse proxy to route traffic to the Node.js app (port 8080)
Enabled access via the EC2 public IP

Nginx acted as the gateway, efficiently handling incoming requests and forwarding them to the application.

🧪 6. End-to-End Validation

After deployment, I performed full testing:

Accessed the application via a web browser
Verified frontend, backend, and database integration
Ensured all components communicated seamlessly

🛠️ 7. Troubleshooting in the Real World

This project wasn’t just about deploying—it was about solving real problems.

Some of the issues I encountered and resolved included:

MySQL temporary password and authentication errors
Node.js and npm installation challenges using NVM
Database connection failures (ECONNREFUSED, access denied)
Nginx errors such as 502 Bad Gateway and port conflicts
Permission and dependency-related issues

Each issue required investigation, debugging, and iterative fixes—exactly what happens in real production environments.

💡 Key Takeaways

Terraform enables consistent and repeatable infrastructure deployment
Nginx is essential for production-grade traffic routing and reverse proxying
Full-stack debugging is a critical DevOps skill
Real learning happens when systems break—and you fix them

🔥 Final Thoughts

From provisioning infrastructure to configuring services and resolving live issues, this project reflects what practical DevOps engineering truly looks like.

It reinforced the importance of:

Automation
System design
Troubleshooting under real conditions

And most importantly, it showed that growth comes from hands-on experience and persistence.

📌 Resources
GitHub Repository: https://lnkd.in/e_yBnf-8
Application URL: http://32.193.246.22
(terminated after validation)

Real progress in tech comes from building, breaking, and fixing.
On to the next challenge 🚀

Till next time, always stay positive 👍

🙌 Acknowledgment

Shout out to Pravin Mishra, Lead Co-Mentor: Praveen Pandey
🤝 Co-Mentors: Egwu Oko, Tanisha Borana, Ranbir Kaur

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this
Discord community ( https://lnkd.in/e4wTfknn ).

Getting Started with Model Context Protocol (MCP): Automating Terraform Security with Claude Code

Daniel Inyang — Fri, 27 Mar 2026 12:09:59 +0000

Artificial Intelligence is becoming increasingly useful in DevOps, but most AI tools still rely only on their training data. This means they can suggest solutions, but they often can’t interact with your real infrastructure or validate whether their suggestions actually work.

In this beginner-friendly guide, I’ll walk through my hands-on experience using Model Context Protocol (MCP) with Claude Code to audit, fix, and verify Terraform security issues automatically. By the end, you’ll understand what MCP is, why it matters, and how it enables AI to safely work with real tools like Terraform and AWS.

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is a framework that allows AI models to connect to external tools and data sources in a structured and secure way. Instead of relying only on static knowledge from training, MCP lets AI access:

Local development tools (like Terraform or Git)
Cloud APIs (such as AWS)
Project files and configurations

This means the AI can not only suggest changes but also validate and execute them using real software.

Why MCP is Important for DevOps

In traditional AI-assisted development, you might ask a model how to fix a Terraform issue, and it would generate code based on patterns it learned during training. However, it cannot confirm whether:

the syntax is correct,
the provider version supports the configuration,
or the change actually resolves the problem.

With MCP, the AI can:

Analyze your real Terraform files.
Modify them.
Run Terraform commands to validate the changes.

This creates a much safer and more reliable automation loop for infrastructure work.

My Setup: Connecting Claude Code to Terraform and AWS

To enable this workflow, I configured two MCP servers in my project:

Terraform MCP server running in Docker
AWS API MCP server using Python’s uvx runtime

These were defined in a .mcp.json file at the root of my project. This file tells Claude Code which tools it is allowed to start and how to communicate with them.

Sensitive information such as AWS credentials was stored separately in .claude/settings.local.json to keep secrets out of version control.

Once everything was configured, I ran the /mcp command in Claude Code and confirmed both servers were successfully connected.

Running a Real DevOps Workflow: Audit → Fix → Verify

To test the setup, I ran a simple but realistic workflow on my Terraform project.

Step 1: Auditing Terraform for Security Issues

I asked Claude Code:

Audit my Terraform files for security issues

The security-auditor agent scanned my Terraform configuration and flagged a problem:
My S3 bucket did not have server-side encryption enabled.

This is a common security issue because unencrypted storage can expose sensitive data if accessed improperly.

Step 2: Automatically Fixing the Issue

Next, I asked Claude:

Add S3 server-side encryption to my Terraform code using AES256

The tf-writer agent updated my Terraform configuration by adding a server-side encryption block to the S3 bucket resource. Behind the scenes, it used the Terraform MCP server to ensure the syntax and resource configuration were valid for my environment.

This step was important because it ensured the AI-generated code was not just theoretically correct but actually compatible with the Terraform version and provider I was using.

Step 3: Verifying the Fix

Finally, I ran the audit again:

Audit my Terraform files for security issues

This time, the encryption issue was no longer reported. The system confirmed that the configuration was now compliant with recommended security practices.

This completed the full audit → fix → verify loop without me manually editing a single Terraform file.

Understanding the Role of AI Agents in This Workflow

One of the most interesting lessons from this exercise was how different AI agents used MCP differently.

The Security Auditor Did Not Need MCP

The security-auditor agent only needed to read Terraform files and apply known security best practices. Since Terraform is a text-based configuration language, the AI could analyze it without running any external tools.

The Terraform Writer Did Need MCP

The tf-writer agent, on the other hand, needed MCP because it had to:

generate new Terraform code,
validate it using the real Terraform binary,
and ensure the configuration would not break the infrastructure deployment.

This clearly showed that reasoning tasks can often be done without tool access, while execution and validation tasks require MCP.

Key Takeaways for Beginners

If you’re new to MCP and AI-assisted DevOps, here are the main lessons from this experience:

MCP allows AI to work with live tools instead of relying only on training data.
This makes AI-generated changes more reliable and safer to apply in real environments.
Separating configuration (.mcp.json) from secrets (settings.local.json) is critical for security.
Not every AI task needs tool access — but any task that modifies or validates infrastructure usually does.

Why This Matters for the Future of DevOps

As infrastructure becomes more complex, the ability to automate not just code generation but also validation and compliance checks will be a major advantage. MCP represents a step toward AI systems that can act as true assistants in DevOps pipelines, capable of performing real tasks while still operating within controlled and secure boundaries.

For beginners, learning MCP now provides a strong foundation for understanding how AI will integrate into future cloud and platform engineering workflows.

If you’re exploring Terraform, cloud security, or AI-assisted development, experimenting with MCP is a great way to see how these technologies can work together in practical, real-world scenarios.

Till next time, always stay positive 👍

Shout out to Pravin Mishra, Lead Co-Mentor: Praveen Pandey
🤝 Co-Mentors: Egwu Oko, Tanisha Borana, Ranbir Kaur

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this
Discord community ( https://lnkd.in/e4wTfknn ).

3-Tier Architecture Deployment on Azure

Daniel Inyang — Fri, 06 Mar 2026 19:25:33 +0000

A complete step-by-step guide to deploying a production-grade Next.js + Node.js + MySQL stack on Azure

Architecture Overview

→ Internet → Azure Application Gateway (Web Tier)
→ Web VM (Next.js + Nginx) — Public Subnets
→ Internal Load Balancer (App Tier)
→ App VM (Node.js backend) — Private Subnets
→ Azure Database for MySQL (HA + Read Replica) — Private Subnets

Phase 1: The Foundation

Networking — Virtual Network, 6 Subnets, NAT Gateway, Route Tables

Step 1: Create a Resource Group

All Azure resources must live inside a Resource Group. This is your project container.

Go to the Azure Portal (portal.azure.com) > search Resource Groups > Create.
Subscription: Select your subscription.
Resource group name: capstone-rg
Region: East US (or your preferred region — choose ONE and use it consistently).
Click Review + Create > Create.

Step 2: Create the Virtual Network (VNet)

This is the Azure equivalent of a VPC with a 10.0.0.0/16 address space.

Search Virtual Networks > Create.
Resource group: capstone-rg
Name: capstone-vnet
Region: East US
Click Next: IP Addresses.
Set IPv4 address space: 10.0.0.0/16
Delete any default subnet that appears. We will add ours manually.
Click Review + Create > Create.

Step 3: Create the 6 Subnets

Navigate to capstone-vnet > Subnets. Click + Subnet for each one below:

⚠️ Critical: The db-private-a and db-private-b subnets must be delegated to Microsoft.DBforMySQL/flexibleServers. When creating these subnets, under Subnet Delegation select Microsoft.DBforMySQL/flexibleServers. Do NOT attach an NSG to delegated subnets — Azure will block it.

Step 4: Create the NAT Gateway

This allows your private App and DB servers to download packages without direct internet exposure.

Search NAT Gateway > Create.
Resource group: capstone-rg | Name: capstone-nat | Region: East US.
Under Outbound IP, click Create a new public IP address. Name: capstone-nat-ip.
Click Next: Subnet. Associate the NAT gateway with: web-public-a and web-public-b.

💡 Note: Azure NAT Gateways associate at the subnet level, not a standalone ‘attachment’. By associating it with the public subnets, resources in private subnets that route through them will use this NAT.

Click Review + Create > Create.

Step 5: Configure Route Tables (UDRs)

Azure automatically handles basic routing, but we need custom User-Defined Routes for private subnets to reach the NAT.

Public Route Table

Search Route Tables > Create.
Name: capstone-public-rt | Resource group: capstone-rg | Region: East US.
After creation, go to the resource > Settings > Subnets > Associate. Add web-public-a and web-public-b.

💡 Note: Azure VNets have built-in internet routing for public subnets. No explicit 0.0.0.0/0 → Internet route is needed unless you have overriding rules.

Private Route Table

Create another Route Table: capstone-private-rt.
Go to Settings > Routes > Add. Add a route: Name: default-to-nat | Address prefix: 0.0.0.0/0 | Next hop type: Internet. (Azure NAT Gateway intercepts this and applies SNAT automatically).
Go to Settings > Subnets > Associate. Add: app-private-a, app-private-b.

💡 Note: Do NOT associate the db subnets with this route table — they are delegated to MySQL and Azure manages their routing.

Phase 2: The Firewalls

Network Security Groups (NSGs) — Azure’s equivalent to AWS Security Groups
In Azure, NSGs can be attached to subnets or individual VM NICs. We follow the same strict chain as the AWS architecture:

• Internet → App Gateway NSG
• App Gateway NSG → Web VM NSG
• Web VM NSG → Internal LB NSG
• Internal LB NSG → App VM NSG
• App VM NSG → DB NSG

⚠️ Critical: Azure NSGs use Priority numbers (100–4096). Lower number = higher priority. Always assign priorities with gaps (e.g. 100, 200, 300) to leave room for future rules.

Step 1: Public App Gateway NSG

Search Network Security Groups > Create.
Name: capstone-appgw-nsg | Resource group: capstone-rg.
After creation, go to Inbound security rules > Add: • Name: Allow-HTTP-Internet | Priority: 100 | Source: Any | Dest. Port: 80 | Protocol: TCP | Action: Allow • Name: Allow-HTTPS-Internet | Priority: 110 | Source: Any | Dest. Port: 443 | Protocol: TCP | Action: Allow • Name: Allow-AppGW-Infra | Priority: 120 | Source: GatewayManager | Dest. Port: 65200–65535 | Protocol: TCP | Action: Allow

⚠️ Critical: The GatewayManager rule on ports 65200–65535 is MANDATORY for Azure Application Gateway. Without it, the App Gateway health probes will fail and it will not provision correctly.

Attach this NSG to web-public-a and web-public-b subnets.

Step 2: Web VM NSG

Create NSG: capstone-web-vm-nsg
Inbound rules: • Name: Allow-HTTP-FromAppGW | Priority: 100 | Source: (App Gateway subnet CIDR 10.0.1.0/24 & 10.0.2.0/24) | Dest. Port: 80 | Action: Allow • Name: Allow-SSH-MyIP | Priority: 200 | Source: Your IP address | Dest. Port: 22 | Protocol: TCP | Action: Allow
Attach to web-public-a and web-public-b subnets.

Step 3: Internal Load Balancer NSG

Create NSG: capstone-internal-lb-nsg
Inbound rules: • Name: Allow-HTTP-FromWebVMs | Priority: 100 | Source: 10.0.1.0/24, 10.0.2.0/24 | Dest. Port: 80 | Action: Allow • Name: Allow-AzureLoadBalancer | Priority: 200 | Source: AzureLoadBalancer (service tag) | Dest. Port: * | Action: Allow
Attach to app-private-a and app-private-b subnets.

Step 4: App VM NSG

Create NSG: capstone-app-vm-nsg
Inbound rules: • Name: Allow-3001-FromInternalLB | Priority: 100 | Source: 10.0.3.0/24, 10.0.4.0/24 | Dest. Port: 3001 | Action: Allow • Name: Allow-SSH-FromWebVM | Priority: 200 | Source: 10.0.1.0/24, 10.0.2.0/24 | Dest. Port: 22 | Protocol: TCP | Action: Allow • Name: Allow-AzureLoadBalancer | Priority: 300 | Source: AzureLoadBalancer | Dest. Port: * | Action: Allow
Attach to app-private-a and app-private-b subnets.

Step 5: Database NSG

Create NSG: capstone-db-nsg
Inbound rules: • Name: Allow-MySQL-FromAppVM | Priority: 100 | Source: 10.0.3.0/24, 10.0.4.0/24 | Dest. Port: 3306 | Protocol: TCP | Action: Allow

💡 Note: For delegated MySQL subnets, Azure may manage some NSG rules automatically. If you encounter issues, verify the NSG is not conflicting with delegation requirements.

Attach to db-private-a and db-private-b subnets.

Phase 3: The Data Layer

Azure Database for MySQL — Flexible Server (HA + Read Replica)
Azure Database for MySQL Flexible Server is the direct replacement for AWS RDS MySQL. It supports zone-redundant high availability (equivalent to Multi-AZ) and read replicas.

Step 1: Create the Primary MySQL Flexible Server (HA)

Search Azure Database for MySQL flexible servers > Create.
Resource group: capstone-rg
Server name: capstone-db (This becomes part of your hostname: capstone-db.mysql.database.azure.com)
Region: East US
MySQL version: 8.0
Compute + storage: Click Configure server. Select Burstable tier > B2ms (2 vCores, 8GB RAM). This is equivalent to db.t3.micro cost-tier.
Under High Availability: Check Enable High Availability. Mode: Zone-redundant (equivalent to RDS Multi-AZ — deploys a standby in a separate Availability Zone).
Standby availability zone: 2 (Primary will be in Zone 1).
Admin username: admin
Password: Password123! (or note whatever you use)
Click Next: Networking. Networking Configuration
Connectivity method: Private access (VNet Integration).
Virtual network: capstone-vnet.
Subnet: Select db-private-a (must be the delegated subnet).
Private DNS zone: Create new. Name: capstone-db.private.mysql.database.azure.com.

⚠️ Critical: Private DNS zone is critical. Without it, your App VMs cannot resolve the MySQL hostname. Azure creates this automatically if you select ‘Create new’.

Click Review + Create > Create. This takes 5–10 minutes.

Step 2: Create the Initial Database
Unlike AWS RDS which lets you set an initial DB name during creation, in Azure you must create the database after the server is provisioned.

Once the server is Available, go to the resource > Databases (left menu) > Add.
Database name: bookreview
Click Save.

Step 3: Create the Read Replica

Go to your capstone-db server > Settings > Replication > Add replica.
Server name: capstone-db-replica
Location: East US (same region for low latency).
Click OK. Wait 5–10 minutes for it to become available.

💡 Note: Azure MySQL Flexible Server read replicas are asynchronous, same as AWS RDS read replicas. They are read-only and can be used for reporting/analytics queries.

Phase 4: The Business Layer

Internal Load Balancer + Node.js Backend VM
Step 1: Create the App VM (Backend)

Search Virtual Machines > Create > Azure virtual machine.
Resource group: capstone-rg
Virtual machine name: capstone-app-vm
Region: East US | Availability zone: Zone 1
Image: Ubuntu Server 22.04 LTS
Size: Click See all sizes. Choose Standard_B1ms (1 vCPU, 2GB) — equivalent to t2.micro.
Authentication type: SSH public key.
Username: azureuser
SSH public key source: Generate new key pair. Name: capstone-key. Download the .pem file when prompted.
Click Next: Disks > Next: Networking. Networking Settings
Virtual network: capstone-vnet
Subnet: app-private-a
Public IP: None (CRITICAL — must be private only!)
NIC network security group: None (our NSG is attached to the subnet already).
Click Review + Create > Create.

Step 2: Create the Web VM (Jump Host + Frontend)

Create another VM: capstone-web-vm
Region: East US | Availability zone: Zone 1
Image: Ubuntu Server 22.04 LTS | Size: Standard_B1ms
SSH key: Use existing key (upload your capstone-key.pub).
Networking: Virtual network: capstone-vnet | Subnet: web-public-a
Public IP: Create new. Name: capstone-web-pip | SKU: Standard | Assignment: Static.
NIC network security group: None.
Click Review + Create > Create. ** Step 3: Connect and Configure the App VM (SSH Jump)** Because the App VM has no public IP, you must SSH into the Web VM first, then jump to the App VM. From your local machine — copy the key to the Web VM scp -i capstone-key.pem capstone-key.pem azureuser@:/home/azureuser/

NOTE: “azureuser” is my VMs username, so replace it with your VMs username

SSH into the Web VM
ssh -i capstone-key.pem azureuser@
From inside Web VM — jump to App VM
chmod 400 capstone-key.pem
ssh -i capstone-key.pem azureuser@

Step 4: Configure the Node.js Backend
Run the following commands inside the App VM:
Install Packages
sudo apt update && sudo apt install nodejs npm mysql-client -y
Clone and Configure the App
git clone https://github.com/pravinmishraaws/book-review-app.git
cd book-review-app/backend
npm install
sudo npm install -g pm2

Edit the Environment File
nano .env
Update these values:
• DB_HOST=capstone-db.mysql.database.azure.com
• DB_USER=admin
• DB_PASSWORD=Password123!
• DB_NAME=bookreview
• PORT=3001

💡 Note: The Azure MySQL hostname format is .mysql.database.azure.com — find it on the Azure Portal under your MySQL Flexible Server > Overview > Server name.

Seed and Start the Backend

node src/server.js

You should see ‘Server running on port 3001’ and ‘Database connected’. Press Ctrl+C to stop.
pm2 start src/server.js — name “backend”
pm2 save
pm2 startup
Copy and run the generated sudo command that pm2 startup outputs.
pm2 status

Step 5: Create the Internal Load Balancer
Create the Backend Pool

Search Load Balancers > Create.
Name: capstone-internal-lb | SKU: Standard | Type: Internal | Tier: Regional.
Virtual network: capstone-vnet | Subnet: app-private-a.
IP address assignment: Dynamic.
Click Next: Backend Pools > Add a backend pool.
Name: capstone-app-pool. Add capstone-app-vm by NIC.
Click Next: Inbound Rules > Add a load balancing rule.
Name: app-lb-rule | Frontend IP: (auto-assigned private IP) | Protocol: TCP | Port: 80 | Backend port: 3001.
Health probe: Create new. Name: app-health-probe | Protocol: HTTP | Port: 3001 | Path: /
Click Review + Create > Create.

💡 Note: Note the Internal LB’s private IP address from the Overview page. This is your equivalent to the Internal ALB DNS name.

Phase 5: The Presentation Layer
Web VM (Next.js + Nginx) + Azure Application Gateway

Step 1: Configure the Web VM (Frontend)

SSH back into your Web VM. Run these commands:
sudo apt update && sudo apt install nodejs npm nginx -y
sudo npm install -g pm2
git clone https://github.com/pravinmishraaws/book-review-app.git
cd book-review-app/frontend
npm install

Step 2: Create the Environment File
nano .env
Add this line:
NEXT_PUBLIC_API_URL=/api
Save and exit (Ctrl+O, Enter, Ctrl+X).

Step 3: Build and Start Next.js
npm run build
pm2 start npm — name “frontend” start
pm2 save && pm2 startup
Run the generated sudo command from pm2 startup.

Step 4: Configure Nginx
sudo nano /etc/nginx/sites-available/default

Delete everything and paste this configuration (replace the proxy_pass address with your Internal LB private IP):

server {
listen 80;
server_name _;
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;
proxy_cache_bypass $http_upgrade;
}
location /api/ {
rewrite ^/api/(.*) /$1 break;
proxy_pass http://;
proxy_http_version 1.1;
proxy_set_header Host $host;
}
}

Save and exit (Ctrl+O, Enter, Ctrl+X)

Then,
sudo nginx -t
sudo systemctl restart nginx

Step 5: Create the Azure Application Gateway (Public ALB)
Azure Application Gateway is the equivalent of AWS’s Public Application Load Balancer. It operates at Layer 7.

Search Application Gateway > Create.
Name: capstone-appgw | Region: East US | Tier: Standard V2.
Autoscaling: Minimum 1, Maximum 2 (cost saving).
Virtual network: capstone-vnet | Subnet: web-public-a.
Click Next: Frontends.
Frontend IP type: Public. Create new public IP: capstone-appgw-ip.
Click Next: Backends. Add a backend pool.
Name: capstone-web-pool. Add capstone-web-vm (by NIC or IP).
Click Next: Configuration. Add a routing rule.
Rule name: http-rule | Priority: 100.
Listener: Name: http-listener | Frontend IP: Public | Protocol: HTTP | Port: 80.
Backend targets: Target type: Backend pool | Backend pool: capstone-web-pool.
HTTP settings: Create new. Name: web-http-settings | Protocol: HTTP | Port: 80.
Click Review + Create > Create. This takes 5–10 minutes.

💡 Note: After creation, get the Application Gateway’s public IP from the Frontend IP configurations. This is what your users will browse to.

POSSIBLE PROBLEM YOU MIGHT ENCOUNTER IN STEP 5

I keep getting this error at step 5 “Subnet must only have application gateway”
This is a very common Azure Application Gateway gotcha.
Exact cause. The error is clear and the fix is straightforward. Here’s what’s happening and how to fix it:

The Problem
Azure Application Gateway requires a dedicated subnet — you cannot deploy any other resource in the Application Gateway subnet.

You are trying to deploy the Application Gateway into web-public-a, which already has your Web VM sitting in it. Azure is rejecting this because the subnet is not empty.

The Fix: Create a dedicated subnet for the Application Gateway
Go to capstone-vnet > Subnets > + Subnet and add a new one:

Name: appgw-subnet
CIDR: 10.0.7.0/24
NSG: capstone-appgw-nsg

Then go back to your Application Gateway creation and select appgw-subnet instead of web-public-a.

Step 6: Update CORS in the Backend

SSH back to the App VM (via Web VM jump), then update CORS:
cd ~/book-review-app/backend
nano .env
Add or update:
ALLOWED_ORIGINS=http://
pm2 restart backend

Open your browser and navigate to: http://
The Book Review App should load successfully!

QUICK TEST:

Restart one of the DBs and see if your application is still reachable
Restart the VM also to see if pm2 auto starts the application.

OPTIONAL
Phase 6: High Availability with VM Scale Sets

Equivalent to AWS Auto Scaling Groups (ASGs) with Launch Templates

Step 1: Create Golden VM Images
Before scaling, capture the perfectly configured VMs as reusable images.

Go to capstone-app-vm > Click Capture (from the top menu).
Share image to Azure Compute Gallery: No (use Managed Image for simplicity).
Image name: capstone-app-golden-image.
Check: Automatically delete this virtual machine after creating the image.
Click Review + Create > Create. Wait for the image to be created.
Repeat for capstone-web-vm. Image name: capstone-web-golden-image.

⚠️ Critical: Capturing an image deallocates and deletes the source VM. Make sure your backend is fully configured and tested before capturing.

Step 2: Create the App Tier VM Scale Set (VMSS)

Search Virtual machine scale sets > Create.
Resource group: capstone-rg | Name: capstone-app-vmss.
Region: East US | Availability zones: 1, 2.
Image: Click See all images > My images tab > Select capstone-app-golden-image.
Size: Standard_B1ms.
Authentication: SSH key > username: ubuntu > Use existing key.
Scaling: Scaling mode: Autoscaling. Instances: Min 2, Max 4, Default 2.
Click Next: Networking.
Virtual network: capstone-vnet | NIC subnet: app-private-a.
Load balancing: Select Load balancer > capstone-internal-lb > Backend pool: capstone-app-pool.
Public inbound ports: None.
Click Review + Create > Create.

Step 3: Create the Web Tier VM Scale Set (VMSS)

Create another scale set: capstone-web-vmss.
Image: capstone-web-golden-image.
Availability zones: 1, 2.
Scaling: Min 2, Max 4, Default 2.
Networking: VNet: capstone-vnet | Subnet: web-public-a.
Public IP per instance: Enabled (so each VM gets a public IP for the App Gateway health checks).
Load balancing: Application Gateway > capstone-appgw > Backend pool: capstone-web-pool.
Click Review + Create > Create.

Step 4: Chaos Test — Prove High Availability
Your architecture is now highly available. Prove it:

Go to Virtual Machines. Manually stop or delete one of the VMSS instances.
The VMSS will detect the missing instance and auto-launch a replacement using the golden image.
pm2 will auto-start the application on the new VM.
Wait 3–5 minutes, then refresh the Application Gateway URL. The app will still be running.

Phase 7: Cleanup — Destroy All Resources

Always delete resources after your lab to avoid unnecessary charges. Follow this order:

Step 1: Delete Scale Sets & VMs

Go to Virtual machine scale sets > Delete capstone-app-vmss and capstone-web-vmss.
Go to Virtual machines > Delete any remaining VMs.

Step 2: Delete Load Balancers & Application Gateway

Search Application Gateway > Delete capstone-appgw.
Search Load Balancers > Delete capstone-internal-lb.
Go to Public IP addresses > Delete capstone-appgw-ip and capstone-web-pip and capstone-nat-ip.

Step 3: Delete MySQL Flexible Server

Search Azure Database for MySQL flexible servers.
Delete capstone-db-replica first.
Delete capstone-db (primary). Confirm deletion — no final snapshot needed for lab cleanup.
Delete the Private DNS Zone: capstone-db.private.mysql.database.azure.com.

Step 4: Delete NAT Gateway

Search NAT Gateways > Delete capstone-nat.
Delete capstone-nat-ip public IP address. Step 5: Delete the Resource Group (Nuclear Option)
Go to Resource Groups > capstone-rg.
Click Delete resource group.
Type the resource group name to confirm > Delete.

⚠️ Critical: Deleting the resource group deletes ALL resources inside it in one sweep — VNet, subnets, NSGs, route tables, VMs, disks, and everything else. This is the fastest cleanup method.

Step 6: Delete VM Images & Key

Search Images > Delete capstone-app-golden-image and capstone-web-golden-image.
If you stored the SSH key in Azure Key Vault or SSH Keys resource, delete it.

And its a wrap

Thank you for the opportunity to share my little knowledge. I hope this was informative.

Comments are welcome.

Till next time, always stay positive 👍

Shout out to Pravin Mishra, Lead Co-Mentor: Praveen Pandey
🤝 Co-Mentors: Egwu Oko, Tanisha Borana, Ranbir Kaur

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this
Discord community ( https://lnkd.in/e4wTfknn ).

DMI #Azure #CloudComputing #DevOps #CloudEngineering #Architecture #NextJS #NodeJS #MySQL #LearningInPublic

From Local VM to AWS: My Journey Mastering Git and Nginx

Daniel Inyang — Thu, 29 Jan 2026 16:21:16 +0000

In the world of DevOps, understanding the flow of code—from a developer’s keyboard to a live server—is the most critical skill you can have. This week, I took a hands-on approach to mastering this "code-to-cloud" journey.

Here is a breakdown of how I used Git, GitHub, and AWS to build a reliable development workflow.

1. Why Git is the Heart of Development

Before diving into the cloud, I started with the basics of Version Control. Git is more than just a "save" button; it’s a time machine for your code.

By practicing locally on a Virtual Machine (VM), I mastered the core essentials:

Initialization: Transforming a regular folder into a tracked repository.
The Staging Area: Learning to "bundle" specific changes before committing them.
Logging: Using git log to audit history and see exactly who changed what and when.

2. Safe Experimentation via Branching

One of my biggest "aha!" moments was working with branches. In a professional setting, you never want to experiment directly on the main (production) branch.

I practiced creating secondary branches to test new features. Once I was satisfied, I merged them back into the main branch. This process taught me:

How to keep the "production" code stable.
How to resolve merge conflicts when two branches have different ideas about the same line of code.

3. Taking it to the Cloud: AWS EC2 & Nginx

Once the code was versioned and ready, it was time to move it to the real world. I migrated my repository from my local VM to an AWS EC2 instance.

To make the website accessible to the public, I set up an Nginx web server. This involved:

Installing Nginx on the Linux instance.
Moving my website files into the /var/www/html directory.
Configuring permissions so the server could "serve" the content to visitors.

The Verdict: Why This Matters

This exercise wasn't just about learning commands like git commit or sudo apt install nginx. It was about understanding the DevOps lifecycle.

By using Git, I ensured my work was safe and collaborative. By using AWS and Nginx, I learned how to make that work available to the world. Whether you are working alone or in a team of hundreds, these tools provide the structure needed to build and deploy software reliably.

What's next? I’m looking forward to automating this entire process so that every time I "push" my code, the server updates itself automatically!

Till next time, always stay positive 👍

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this
Discord community ( https://lnkd.in/e4wTfknn ).

Host a simple Website using Nginx

Daniel Inyang — Fri, 23 Jan 2026 09:16:54 +0000

Hi Guys,

I worked on a simple website and hosted it on EC2 and served using Nginx.
The website wasn’t designed or deployed by me, I just used it to practice and update my skills on Linux and Nginx.

Here are the steps I followed:

✅ Create and launch an EC2 Instance

Used Ubuntu OS

Make sure you allow ports 22 (SSH) and 80 (http)

✅Install Nginx

Sudo apt install nginx -y

Nginx -v

✅Downloaded the websites zipped file from a github repo (https://github.com/pravinmishraaws/Pravin-Mishra-Portfolio-Template)

wget https://github.com/pravinmishraaws/Pravin-Mishra-Portfolio-Template

Then I unzipped the downloaded zip file

First install zip:

sudo apt install zip

Now unzip the file:

unzip file.zip

✅Deploy Website Files to Nginx Web Directory

Copied all uzipped files to nginx web directory which is at /var/www/html

Then I made some modification to the index.html file

✅Verify the Deployment

Ensure Nginx is correctly serving the website:

curl your-public-ip

✅Access the Website using the servers Public IP

http://your-public-ip

✅Now the Website is deployed on an Ubuntu VM with Nginx, accessible from a public IP.

Live Link (Available for 12hours): http://samplewebsite.cloudworks.com.ng/

or http://52.201.61.175/

I hope this was insightful

Till next time, always stay positive 👍

Objective Truths I have Discovered

Daniel Inyang — Thu, 15 Jan 2026 13:42:14 +0000

Hello Guys, so this is my little writeup about some objective truths I have come to know. Fisrt of all, what is an objective truth?

Objective truths are facts or realities that are true regardless of personal feelings, opinions, beliefs, or perspectives. They can be verified independently and remain the same for everyone.

So these are three of mine I have experimented with and there results.

Truth #1: Consistency Beats Talent and Intensity

Evidence from my life: I used to always be that person that was never consistent when learning things and it showed gaps in knowledge. Then I started being consistent by learning things everyday no matter how little it was and it automatically improved my knowledge retention and skill upgrade.

Truth #2: Sleep is Non-Negotiable for Health

Evidence from my life: Since I started having a healthy sleep habit, I noticed that I rarely fall sick or feel tired when I start focusing on work or learning or upskilling. Prioritizing sleep improves productivity, mood, and longevity.

Truth #3: Having a healthy goal/target to achieve helps with motivation

Evidence from my life: I used to just read or learn stuff without even knowing why , I just wanted to learn stuff, but at one point it got tiring and boring. Then I decided to start having a target or a goal to achieve and that gave me the motivation to keep going until I hit the stated target.

I just thought I should share the outcomes of these truths as it affected me.

Till next time, stay positive .

My Version 2.0 self (Journalistic Writeup)

Daniel Inyang — Tue, 13 Jan 2026 17:28:57 +0000

This is a writeup about one of the brilliant and successful minds in the DevOps landscape, Mr Daniel Inyang.

Daniel is a skilled DevOps Engineer with a strong reputation for building reliable infrastructure and automating complex systems. His transition into DevOps was marked by deliberate hands-on experimentation and consistent delivery of real-world solutions rather than theory alone.

By the late 2020s, Daniel had built and shipped multiple end-to-end DevOps projects that demonstrated deep technical competence. His portfolio included CI/CD pipelines using GitHub Actions and Jenkins, containerized applications deployed with Docker and Kubernetes, and cloud infrastructure provisioned using Terraform on Microsoft Azure. He designed secure Azure environments featuring Virtual Networks, Network Security Groups, VPN Gateways, and VNet Peering, all documented with clear architecture diagrams and deployment steps. These projects were publicly available on his GitHub, where regular commits, issue tracking, and versioned releases showed professional engineering practices.

In 2027, he had earned industry-recognized certifications that validated his skills, including Linux administration and cloud fundamentals certifications aligned with his day-to-day responsibilities. Daniel published technical blogs that broke down DevOps concepts such as CI/CD workflows, DNS resolution, Linux permissions, Git version control, and infrastructure as code. His writing focused on practical explanations backed by labs and screenshots, making his content especially valuable to beginners. Several of his blog posts were shared across DevOps learning communities and study groups.

In his professional role, Daniel worked as a DevOps Engineer supporting production systems. He automated deployment pipelines, reduced manual configuration errors, and improved system reliability through monitoring and logging solutions. He collaborated closely with developers, QA engineers, and network teams to resolve incidents and optimize release processes. His contributions directly reduced deployment time and improved system uptime.

Leadership showed through action. Daniel mentored junior engineers, reviewed pull requests, and created internal documentation that simplified onboarding. Outside work, he contributed to the DevOps community by sharing reusable scripts, lab guides, and troubleshooting walkthroughs, particularly supporting learners from emerging tech markets.

By this stage, Daniel had contributed immensely in the DevOps space defined by evidence: shipped systems, verified skills, documented learning, and meaningful impact. His journey reflected disciplined growth, curiosity, and a career built on genuine interest rather than short-lived trends.

This is what I aspire to become in the near future through consistency, dedication and focus.

My LinkedIn Profile: https://www.linkedin.com/in/daniel-inyang/

“This is part of DevOps Micro-Internship (DMI) by Pravin Mishra.”

Connect with him on LinkedIn: https://www.linkedin.com/in/pravin-mishra-aws-trainer/

My First DevOps Project

Daniel Inyang — Wed, 26 Nov 2025 15:30:38 +0000

Hi Guys, welcome to my DevOps project writeup. I was tasked with deploying a personal portfolio website and hosting it on Killercoda using Nginx. To accomplish this, I used

startbootstrap for their templates
Vscode for editing files
Nginx as my webserver of choice
Killercoda ubuntu playground

This is a walkthrough on how I accomplished it.

Step 1: Getting a Template
I went to https://startbootstrap.com/ and selected my preferred template to download.

Step 2: Accessing the files via VS Code
I extracted the downloaded template and opened the folder via VS Code

Changes I made include:

My name
A brief bio
DevOp skills I would like to learn and so on

Viewing the site via "Open with Live Server" displayed:

Notice the URL: http://127.0.0.1:5500/index.html
or http://localhost:5500/index.html

Step 3: Moving Files to Github
I went to https://github.com

Created a "tsacademystaticwebsite" repository on Github

On Local system; Lauched VS Code > Terminal window Navigated to the directory where my template files are located

Started running git commands

git init
git config --global user.name "Daniel Inyang"
git config --global user.email "iny**********@gmail.com"
git add .
git commit -m "Tracking all files"
git remote add origin https://github.com/danielinyang/tsacademystaticwebsite.git
git push -u origin main

Step 4: Accessing Killercoda Ubuntu Playground

I went to https://killercoda.com/playgrounds/scenario/ubuntu

I got access to a cloud ubuntu environment where I could deploy and host my project.

Step 5: Install NGINX Webserver

on the ubuntu terminal prompt, i ran the command to insatll nginx

sudo apt install nginx -y

Check that the nginx service is running

sudo systemctl status nginx

I also Opened the Web Traffic/Port on port 80 to also confirm that Nginx was running

Step 6: Cloning the Github Repo

Now I will create a folder on the ubuntu server called "First_Project"

sudo mkdir First_Project
cd First_Project

Now I intialize the folder with git and theclone the Github repo created earlier (tsacademystaticwebsite)

git init
git clone https://github.com/danielinyang/tsacademystaticwebsite.git

Step 7: Navigating to the Webserver Directory

By default nginx serves files from /var/www/html

I checked to see the content of that folder

sudo ls /var/www/html

i found the file "index.nginx-debian.html" which serves the default nginx welcome screen

Step 8: Delete the contents of the Webserver Directory

I have to delete that file "index.nginx-debian.html"

To delete

cd /var/www/html
rm index.nginx-debian.html

Now when you check the content of /var/www/html, it will be empty

The nginx welcome screen will show an error message

Step 9: Move files to the NGINX Webserver Directory

I have to move the files I cloned from Github into First_Project folder to the webserver directory (/var/www/html)

cd First_Project
cd tsacademystaticwebsite
mv * /var/www/html

Step 10: My Website is Live

Using the site URL provided by killercoda to view the site

https://2760473c40b0-10-244-11-177-80.spch.r.killercoda.com/

Now if we refresh the nginx site again, we see this:

!!! SUCCESS !!!

NOTICE: The site on my localhost URL is the same as that on the Killercoda URL

Unfortunately the killercoda playground access only last for 60 minutes, so by the time you checkout the site, it most probably will already be down.

Conclusion

This was my first project I successfully deployed as an aspiring DevOps Engineer. I hope this was helpful and simple enough to understand and follow.

I am still learning, so please feel free to give feedback and advice.

Kindly leave a comment or a question If you have any; and I will be glad to respond.

Till next time, stay safe.