DEV Community: Vivian Chiamaka Okose

Multi-Stage Docker Builds: How I Cut a React Image from 760MB to 94MB

Vivian Chiamaka Okose — Fri, 17 Apr 2026 15:07:31 +0000

I built two Docker images for the same React app this week.

One was 760MB. The other was 94MB. Both loaded the exact same website in the browser.

That 87.6% difference is the story of this post.

The Setup

This is Week 14 of my DevOps Micro Internship. The project: containerize a React app two ways, compare the results, and explain what changed and why it matters.

I am running everything on an Azure VM (Ubuntu 24.04 LTS) with Docker auto-installed via cloud-init.

The React app: https://github.com/pravinmishraaws/my-react-app

First: The .dockerignore

Before writing a single Dockerfile, I created a .dockerignore to keep things that should never be in an image out of the build context:

node_modules
build
.dockerignore
.git
.gitignore
*.md

This is especially important for node_modules. If you do not exclude it, Docker copies your entire local node_modules into the build context, which defeats the whole purpose of running npm ci inside the container.

Approach 1: Single-Stage Baseline (Dockerfile.single)

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
RUN npm install -g serve
EXPOSE 3000
CMD ["serve", "-s", "build", "-l", "3000"]

This image does everything in one go. Install dependencies, build the app, serve it. Simple.

The problem is that everything stays. Node.js, npm, all 1,342 packages, build tools. None of that is needed to serve a built React app. But it is all sitting there in the image.

Result: 760MB

Build command:

docker build -f Dockerfile.single -t react-single:latest .

Run command:

docker run -d --name react-single -p 3000:3000 --restart unless-stopped react-single:latest

Approach 2: Multi-Stage Build (Dockerfile)

# Stage 1 - build React app
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 - serve with nginx
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Two stages. Stage 1 builds the app. Stage 2 starts completely fresh with nginx:alpine and picks up only the finished build/ folder from Stage 1.

Node.js never makes it into the final image. Neither do npm or any of those 1,342 packages.

Result: 94MB

Build command:

docker build -t react-multi:latest .

Run command:

docker run -d --name react-multi -p 80:80 --restart unless-stopped react-multi:latest

The Comparison

docker images

Image	Size
react-single:latest	760 MB
react-multi:latest	94 MB
Reduction	87.6%

Both containers ran simultaneously. Both loaded the same React app. The only difference was what was inside each image.

Why This Matters Beyond the Numbers

Security: Every package not in the final image cannot be exploited. The multi-stage image has no Node.js, no npm, no build tools. An attacker who somehow gets into that container finds a bare Nginx server. Nothing else.

CI/CD Speed: Smaller images push and pull faster. If your pipeline deploys 10 times a day and each deployment pulls a 760MB image instead of a 94MB one, that is a significant amount of wasted time over weeks and months.

Layer Caching: Notice that both Dockerfiles copy package.json before the rest of the source code. This is intentional. Docker caches each layer. If your dependencies have not changed, Docker skips the npm ci step entirely on the next build and jumps straight to copying your source. This alone can shave minutes off build times.

Running Both Simultaneously

One of the most satisfying parts of this project was running both containers at the same time on the same VM:

docker ps

CONTAINER ID   IMAGE                 PORTS                    NAMES
837fb6d5def2   react-multi:latest    0.0.0.0:80->80/tcp       react-multi
66efa6b350bf   react-single:latest   0.0.0.0:3000->3000/tcp   react-single

Opening both in the browser showed the same React app on two different ports, proving the multi-stage approach produces an identical result in a fraction of the space.

Full Project

GitHub: https://github.com/vivianokose/cloud-vm-docker-deploy

See you in the next one.

How I Deployed a Live Website Using Docker on Azure (And Let Cloud-Init Do the Heavy Lifting)

Vivian Chiamaka Okose — Thu, 16 Apr 2026 20:39:44 +0000

What I Built

1 Linux VM on Azure (Ubuntu 24.04 LTS, Standard D2lds v6)
A cloud-init script that installed Docker automatically on first boot
A Dockerized static website served by Nginx
A live URL accessible from anywhere in the world

Step 1: Provisioning the Azure VM

I created the VM through the Azure Portal with these settings:

Field	Value
Resource Group	docker-project-rg
VM Name	docker-vm
Region	UK South
Image	Ubuntu 24.04 LTS
Size	Standard D2lds v6
Authentication	SSH public key

Under the Networking tab, I opened port 22 for SSH and port 80 for HTTP traffic by adding inbound rules to the Network Security Group.

Step 2: The Cloud-Init Script (This Is the Magic Part)

Before launching the VM, I pasted this script under the Advanced tab in the Custom Data field:

#cloud-config
package_update: true
package_upgrade: true
packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg
  - lsb-release

runcmd:
  - apt-get update -y
  - apt-get install -y docker.io
  - systemctl enable docker
  - systemctl start docker
  - usermod -aG docker azureuser

This script runs automatically the moment the VM boots. Docker installs itself, starts itself, and adds my user to the docker group. I had not even SSH'd in yet.

When I later ran:

sudo cat /var/log/cloud-init-output.log | grep -i docker

The log confirmed everything. Docker was installed by the startup script, not by me. That is infrastructure automation doing exactly what it is supposed to do.

Step 3: SSH Into the VM

Once deployment completed, I grabbed my public IP from the Azure Portal and connected:

chmod 400 docker-vm_key.pem
ssh -i docker-vm_key.pem azureuser@4.234.163.212

Then I verified Docker was running:

docker --version
# Docker version 29.1.3

docker ps
# Empty, no containers yet. But Docker is alive.

Step 4: Clone the Static Website

git clone https://github.com/pravinmishraaws/Azure-Static-Website.git
cd Azure-Static-Website
ls
# README.md  index.html

Simple. Just an index.html. That is all we need.

Step 5: Write the Dockerfile

FROM nginx:alpine
RUN rm -rf /usr/share/nginx/html/*
COPY . /usr/share/nginx/html
EXPOSE 80

Let me break this down:

FROM nginx:alpine — we are using a lightweight version of Nginx as our base image. Alpine Linux is tiny, which keeps our container small and fast.

RUN rm -rf /usr/share/nginx/html/* — wipes out the default Nginx welcome page so our site shows instead.

COPY . /usr/share/nginx/html — copies everything in our current folder (including index.html) into the Nginx web root.

EXPOSE 80 — tells Docker this container will accept traffic on port 80.

Step 6: Build the Image

docker build -t static-site:latest .

Docker pulls nginx:alpine, runs each step in the Dockerfile, and produces an image called static-site:latest. The whole process takes about a minute.

After building, I checked the image sizes:

Image	Size
nginx:alpine	93.5 MB
static-site:latest	92.9 MB

Our image is actually slightly smaller than the base because we replaced Nginx's default content with our own lighter files.

Step 7: Run the Container

docker run -d --name static-site \
  -p 80:80 \
  --restart unless-stopped \
  static-site:latest

Breaking down the flags:

-d runs the container in the background
--name static-site gives it a friendly name
-p 80:80 maps port 80 on the VM to port 80 inside the container
--restart unless-stopped means it comes back automatically after a VM reboot

Step 8: Verify and Open in Browser

docker ps

Output:

CONTAINER ID   IMAGE                PORTS                    NAMES
83cb16a6cb44   static-site:latest   0.0.0.0:80->80/tcp       static-site

Then I opened http://4.234.163.212 in my browser.

The site loaded.

I cannot fully explain how good that felt. Three months into learning DevOps, and I just served a live website from inside a Docker container running on a cloud VM I spun up myself.

What I Learned

Cloud-init is a game changer. The idea that a VM can configure itself on boot, without any human touching it, is what separates manual setups from real infrastructure automation.

Containers are not complicated. A Dockerfile is just a recipe. Build the recipe, get an image. Run the image, get a container. That is it.

nginx:alpine is perfect for static sites. Small, fast, and it just works.

The --restart flag matters. In production, you want your containers to survive reboots. Always add --restart unless-stopped.

Full Project

GitHub: https://github.com/vivianokose/cloud-vm-docker-deploy

See you in the next one.

I Automated a Full Application Deployment with Azure DevOps, Terraform, and Ansible

Vivian Chiamaka Okose — Fri, 10 Apr 2026 21:17:26 +0000

Four projects. Several weeks. One capstone.

This is the project where everything came together. Not just conceptually, but in practice, in a real pipeline, on real infrastructure, with real application code running live on Azure.

We deployed the EpicBook application using two repositories and two pipelines. One pipeline provisioned the infrastructure with Terraform. The other deployed and configured the application with Ansible. Both ran on the self-hosted agent I built back in Project 1. By the end, the application was live at a public IP, deployed entirely through automation with zero manual steps on the server.

Here is exactly how I built it, what went wrong, what I fixed, and what I would do differently next time.

Why Two Repositories?

This was the design decision I thought about the most before starting, and I think it is worth explaining properly because it is easy to miss why this matters.

When infrastructure and application code live in the same repository, every code change, even a small frontend tweak, can potentially trigger an infrastructure rebuild. Different people on a team cannot manage infrastructure and application changes independently without stepping on each other. Rolling back a bad deployment becomes complicated because the infrastructure and application histories are tangled together.

Separating them means each repository has one clear responsibility. The infra repo manages what exists on Azure. The app repo manages what runs on that infrastructure. Two repos, two concerns, two pipelines. The separation is intentional, and it reflects how real engineering teams actually work.

What the Infrastructure Pipeline Provisioned

The infra pipeline ran Terraform and created everything the application needed to run:

Resource Group: EpicBookRG
Virtual Network: epicbook-vnet (10.2.0.0/16)
Network Security Group with rules open on ports 22, 80, and 3306
Frontend VM: EpicBookFrontendVM (Standard_D2s_v3)
Backend VM: EpicBookBackendVM (Standard_D2s_v3)
Static Public IPs for both VMs

After terraform apply completed, the outputs were:

frontend_public_ip = "20.25.48.139"
backend_public_ip  = "20.124.125.115"

These IPs are what the Ansible inventory would later reference to configure each VM. Using static IPs here is deliberate. A dynamic IP changes every time the VM restarts, which would break the connection between the Terraform output and the Ansible inventory without any warning.

Setting Up Authentication: The Service Principal

This tripped me up the first time I tried to run Terraform inside a pipeline, so I want to explain it clearly.

Terraform cannot use your personal Azure login credentials inside an Azure DevOps pipeline. It needs a Service Principal, which is essentially a dedicated identity with specific permissions scoped to your subscription. You create it like this:

az ad sp create-for-rbac \
  --name "EpicBookTerraformSP" \
  --role Contributor \
  --scopes /subscriptions/YOUR_SUBSCRIPTION_ID

That command returns four values you need to hold onto:

appId (this is your Client ID)
password (this is your Client Secret)
tenant (your Tenant ID)
your Subscription ID

These four values go into an Azure Resource Manager service connection in Azure DevOps. Then in the pipeline, the AzureCLI@2 task with addSpnToEnvironment: true exposes them as environment variables that Terraform reads automatically. You do not hardcode credentials anywhere. They flow in securely at runtime.

If you skip the Service Principal setup and just try to run Terraform in a pipeline with your personal credentials, it will fail. This step is not optional.

SSH Keys and Secure Files

The private SSH key for VM access was generated locally:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/epicbook_key -N ""

The public key went into the Terraform VM configuration so the VMs were provisioned with it already authorized. The private key was uploaded to Azure DevOps Secure Files as epicbook_key. It never touched the repository at any point.

This is an important security habit to build early. Credentials and private keys should never live in a repository, even a private one. Secure Files in Azure DevOps is exactly what it sounds like: a safe place to store sensitive files that your pipeline can access at runtime without exposing them anywhere else.

In the App Pipeline, the key is downloaded and permissions are set like this:

- task: DownloadSecureFile@1
  inputs:
    secureFile: 'epicbook_key'
  name: SSHKey

- script: chmod 400 $(SSHKey.secureFilePath)

The chmod 400 is required. SSH will refuse to use a private key that has loose permissions. If you skip this step, the Ansible connection to your VMs will fail with a permissions error.

The Ansible Playbook

With the VMs provisioned and the keys in place, Ansible handled everything on the servers. Four roles were applied across two VMs:

- name: Configure Frontend VM
  hosts: frontend
  become: yes
  roles:
    - common
    - nginx
    - epicbook_frontend

- name: Configure Backend VM
  hosts: backend
  become: yes
  roles:
    - common
    - epicbook_backend

The common role ran on both VMs and handled shared setup tasks like package updates and base configuration. The nginx role installed and configured Nginx on the frontend only. The epicbook_frontend and epicbook_backend roles deployed the actual application code to each server.

Here is the actual PLAY RECAP from the pipeline run:

20.124.125.115  : ok=9    changed=7    unreachable=0    failed=0
20.25.48.139    : ok=11   changed=9    unreachable=0    failed=0

Zero failures on both VMs. Both fully configured in a single pipeline run.

Reading a clean Ansible recap with failed=0 after building all of this from scratch is a genuinely satisfying thing.

The Live Application

After both pipelines completed, I opened the browser at http://20.25.48.139 and the EpicBook application was running:

📚 EpicBook Application
Deployed by: Vivian Chiamaka Okose
Infrastructure: Terraform + Ansible + Azure DevOps
Server: Nginx on Ubuntu 22.04
Live on Azure

No manual SSH. No copying files by hand. No touching the server after the initial key setup. The pipelines handled everything from infrastructure creation to application deployment.

What I Would Do Differently

Two things stand out as areas I would improve in a production setup:

Terraform remote state. For this project, I ran Terraform locally to get stable outputs, then manually copied the VM IPs into the Ansible inventory. That worked here, but it does not scale and it introduces a manual step into what should be a fully automated process. The proper setup uses Azure Blob Storage as a Terraform backend so the state persists between pipeline runs. The IP outputs would then flow automatically into the App Pipeline without any human intervention. This is something I plan to implement in the next project.

Agent download workaround. When setting up the self-hosted agent in Project 1, the standard CDN domain for the Azure Pipelines agent was unreachable from my network. The fix was using the Azure DevOps API directly to get the exact download URL for the agent package. It was a bit of digging to figure out, but it is actually the more reliable approach and I think more onboarding guides should document it.

Looking Back at the Full Series

It is worth stepping back and seeing the whole picture:

Project 1 built the self-hosted agent that every subsequent pipeline ran on.

Project 2 deployed a static website to Nginx over SSH, which introduced the CopyFilesOverSSH task and the permissions fix for /var/www/html.

Project 3 built a four-stage React pipeline with build, test, publish, and deploy stages, and introduced pipeline artifacts and the dependsOn pattern.

Project 4 tied all of it together with real infrastructure automation, a Service Principal, Secure Files, Ansible roles, and two pipelines working in coordination.

Each project was harder than the one before it. Each one built directly on what came before. That layered progression is something I would recommend to anyone learning DevOps. You do not have to understand everything at once. You just have to understand the next piece well enough to build on it.

If any part of this was useful to you, share it with someone who is learning. It might save them a few hours.

Vivian Chiamaka Okose is a DevOps Engineer who documents her learning in public.

Building a 4-Stage CI/CD Pipeline for a React App with Azure DevOps

Vivian Chiamaka Okose — Fri, 10 Apr 2026 17:44:38 +0000

There is a big difference between deploying static HTML files and deploying a React application. I learned that difference firsthand in this project, and it changed how I think about pipelines.

This is Project 3 in my Azure DevOps series. In the previous project, I deployed a static finance website by copying HTML files directly to an Nginx server using SSH. Clean, simple, effective. But React is a different story. You cannot just copy the source files and call it done. The code has to be compiled first. And that compilation step is what makes a proper multi-stage pipeline not just useful, but necessary.

Four stages. Build, Test, Publish, Deploy. Each one depends on the previous. If any stage fails, the rest do not run. That is CI/CD working exactly the way it is supposed to.

Why React Cannot Be Deployed Like Static HTML

This is worth understanding before we get into the pipeline itself.

When you write a React app, you write in JSX. JSX is not something a browser can read directly. Before it can go live, it has to go through a build process that compiles everything into plain HTML, CSS, and JavaScript. Running npm run build produces a /build directory containing those optimized, browser-compatible files. That /build folder is what actually gets deployed to the server, not the source code.

So unlike Project 2 where I pushed the site files straight to Nginx, here the pipeline has to build the app first, verify the output, and only then copy it to the server. That extra step is what the first three stages of this pipeline are doing.

The Four Stages Explained

Stage 1: Build

This is where everything starts. The pipeline installs Node.js 18, runs npm install to pull in dependencies, then runs npm run build to compile the React app. The resulting /build directory is published as a pipeline artifact called react_build.

Publishing it as an artifact is important. It means the compiled output is saved and can be downloaded by later stages, even if those stages run on a different agent. You are not recompiling the app at every stage. You build once, save the result, and pass it forward.

Stage 2: Test

After the build succeeds, the pipeline runs the unit tests. There is one flag here that is easy to miss and very important to include:

npm test -- --watchAll=false

Without --watchAll=false, the test runner goes into watch mode. It sits there waiting for file changes that will never come because this is a CI environment, not a local dev machine. The pipeline just hangs. Adding this flag tells the test runner to run once, report the results, and exit. Always include this in any CI pipeline running React tests.

Stage 3: Publish

This stage downloads the react_build artifact and lists its contents. It might look like a minor step but it is doing something important: acting as a verification gate. Before anything touches the live server, you confirm that the right files are actually in the artifact. It is a sanity check that catches issues early, before they reach production.

Stage 4: Deploy

The final stage downloads the artifact, copies the compiled React files to /var/www/html on the Nginx VM over SSH, and then restarts Nginx to serve the updated content. The SSH service connection here (ubuntu-nginx-ssh-react) points to the same VM provisioned in the earlier project using Terraform.

Something Important I Learned About Server Files

Midway through this project, I thought about editing index.html directly on the server to update the content being displayed. It seemed like the fastest way to make a small change.

I am glad I paused and thought it through, because that would have been entirely wrong in a CI/CD setup.

The next pipeline run would overwrite that change completely. The server is not the source of truth. The repository is. Any change that needs to go live should happen in the source code, in Azure Repos, through a commit. That commit triggers the pipeline, which rebuilds the app, runs the tests, and deploys a fresh version of the site. Your change goes through the full process before it ever hits the server.

That is not just a best practice. It is the entire point of having a pipeline. CI/CD is designed to make the deployment process consistent and repeatable, and editing files directly on the server breaks that completely. Once you understand this, a lot of other DevOps concepts start to make more sense.

The Full Pipeline YAML

trigger:
  branches:
    include:
      - main

pool:
  name: SelfHostedPool

stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - checkout: self
          - task: NodeTool@0
            inputs:
              versionSpec: '18.x'
          - script: |
              npm install
              npm run build
            displayName: Build React App
          - publish: build
            artifact: react_build

  - stage: Test
    dependsOn: Build
    jobs:
      - job: TestJob
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '18.x'
          - script: |
              npm install
              npm test -- --watchAll=false
            displayName: Run Tests

  - stage: Publish
    dependsOn: Test
    jobs:
      - job: PublishJob
        steps:
          - download: current
            artifact: react_build
          - script: ls $(Pipeline.Workspace)/react_build
            displayName: Verify Artifact Contents

  - stage: Deploy
    dependsOn: Publish
    jobs:
      - job: DeployJob
        steps:
          - download: current
            artifact: react_build
          - task: CopyFilesOverSSH@0
            inputs:
              sshEndpoint: 'ubuntu-nginx-ssh-react'
              sourceFolder: '$(Pipeline.Workspace)/react_build'
              contents: '**'
              targetFolder: '/var/www/html'
              cleanTargetFolder: true
          - task: SSH@0
            inputs:
              sshEndpoint: 'ubuntu-nginx-ssh-react'
              runOptions: 'inline'
              inline: 'sudo systemctl restart nginx'

A few things worth noting in this YAML:

The dependsOn keyword is what creates the sequential chain. Each stage explicitly depends on the previous one, so if the build fails, the test stage never starts. If tests fail, nothing gets deployed. This is intentional. You do not want broken code reaching your server.

The cleanTargetFolder: true setting wipes /var/www/html before copying new files. This ensures you are always deploying a clean build with no leftover files from previous runs. If you ran into permission errors on this in an earlier project (I did), make sure the azureuser account owns /var/www/html before the pipeline runs.

Result

All four stages went green. React app live on Nginx. The custom content I added to verify the deployment was showing correctly:

Welcome to My React App (Finance APP)
Deployed by: Vivian Chiamaka Okose | Date: 08/04/2026

Total pipeline time from commit to live: 2 minutes and 51 seconds.

That is a fully compiled, tested, and deployed React application, triggered by a single push to main. No manual steps anywhere in the process.

Key Takeaways

A few things I would want anyone following this to keep in mind:

Never edit files directly on the server in a CI/CD setup. The pipeline will overwrite them on the next run. Your repo is the source of truth. Always.

Always use --watchAll=false for React tests in CI. Without it, your pipeline will hang indefinitely.

Use pipeline artifacts to pass build output between stages. Build once, share the result. Do not recompile at every stage.

The dependsOn keyword is how you enforce order. Stages run in parallel by default in Azure DevOps. If you need them sequential, you have to say so explicitly.

Three projects down in the Azure DevOps series. One more to go.

Vivian Chiamaka Okose is a DevOps Engineer building real pipelines and writing about what she learns.

How I Deployed a Static Website with Azure DevOps, Terraform, Ansible, and Nginx

Vivian Chiamaka Okose — Fri, 10 Apr 2026 16:12:25 +0000

There is something about pushing code and watching a website update itself on a live server that never gets old. No manual uploads. No FTP. No SSH copying. Just a commit, and the pipeline takes care of everything else.

This is Project 2 in my Azure DevOps series. In this one, I deployed a static finance website to an Ubuntu VM running Nginx, fully automated with a CI/CD pipeline that triggers on every push to main. Terraform handled the infrastructure. Ansible handled the server configuration. Azure DevOps handled the deployment. And one permissions error tried very hard to ruin my day.

Here is exactly how I built it, what broke, and how I fixed it.

The Stack

Before we dive in, here is everything I used:

Azure DevOps for the pipeline and code repository
Terraform to provision the Ubuntu VM on Azure
Ansible to install and configure Nginx on the server
SSH Service Connection in Azure DevOps for secure file transfer
YAML pipeline to automate the full deployment flow

Step 1: Import the Repository into Azure Repos

The first thing I did was import the finance website codebase into Azure Repos directly from GitHub:

https://github.com/pravinmishraaws/Azure-Static-Website

Once imported, I confirmed that index.html was visible in the repo. Simple step, but worth verifying before anything else.

Step 2: Provision the VM with Terraform

Next, I wrote a Terraform configuration to spin up the infrastructure on Azure. The config created:

A Resource Group
A Virtual Network and Subnet
A Network Security Group (NSG) with ports 22 and 80 open
A static Public IP address
An Ubuntu 22.04 LTS VM

After running terraform apply, I got the VM's public IP:

vm_public_ip = "20.124.184.86"

That IP is what the pipeline would later deploy to, and what the final site would be accessible from.

One thing worth noting: always use a static public IP when setting up a deployment target. If you use a dynamic IP, it changes every time the VM restarts and your pipeline will lose its connection.

Step 3: Configure Nginx with Ansible

With the VM up, I used Ansible to install and configure Nginx. The playbook was straightforward:

- name: Install Nginx
  apt:
    name: nginx
    state: present
    update_cache: yes

- name: Start Nginx
  systemd:
    name: nginx
    state: started
    enabled: yes

But there is a step most tutorials skip, and it is the one that will save you a headache later. After installing Nginx, I immediately ran these two commands:

sudo chown -R azureuser:azureuser /var/www/html
sudo chmod -R 755 /var/www/html

Here is why this matters: Nginx creates the /var/www/html directory owned by root. When the Azure DevOps pipeline tries to copy files into that folder, it runs as azureuser, not root. That user does not have write access. The pipeline fails. I will come back to this in a moment because even with this step in Ansible, I still hit the error the first time around.

Step 4: Create the SSH Service Connection in Azure DevOps

This is the connection that allows the pipeline to communicate with the VM over SSH.

In Azure DevOps, go to Project Settings, then Service Connections, then click New Service Connection. Choose SSH and fill in:

Host: your VM's public IP
Port: 22
Username: azureuser
Password (or private key)
Name: ubuntu-nginx-ssh

One thing that confused me at first: SSH service connections do not show a green verified badge the way other service connections do. That is completely normal. The only real test is whether the pipeline runs successfully. Do not let the missing badge throw you off.

Step 5: Write the Pipeline

With the service connection in place, I wrote the YAML pipeline. It has two tasks: copy the website files to the server, then verify the deployment ran correctly.

trigger:
  branches:
    include:
      - main

pool:
  name: SelfHostedPool

stages:
  - stage: Deploy
    jobs:
      - job: DeployJob
        steps:
          - checkout: self

          - task: CopyFilesOverSSH@0
            inputs:
              sshEndpoint: 'ubuntu-nginx-ssh'
              sourceFolder: '$(Build.SourcesDirectory)'
              contents: '**'
              targetFolder: '/var/www/html'
              cleanTargetFolder: true

          - task: SSH@0
            inputs:
              sshEndpoint: 'ubuntu-nginx-ssh'
              runOptions: 'inline'
              inline: 'ls /var/www/html'

The cleanTargetFolder: true setting tells the pipeline to wipe the target directory before copying new files. This is what caused the permission error on the first run, because it tries to run rm -rf on /var/www/html, and if root still owns that folder, the pipeline user gets blocked.

The Permission Error (And How to Fix It)

The first pipeline run failed with this:

rm: cannot remove '/var/www/html/index.nginx-debian.html': Permission denied
Failed to clean the target folder. Command rm -rf '/var/www/html'/* exited with code 1.

Even though I had added the chown command to the Ansible playbook, the error still appeared on this run because the VM had been provisioned before I added that step. The fix was simple: SSH into the VM manually and run:

sudo chown -R azureuser:azureuser /var/www/html
sudo chmod -R 755 /var/www/html

Then I reran the pipeline. It went fully green.

If you are following this setup from scratch and you run the Ansible playbook before the pipeline, you should not hit this error at all. But if you do, this is exactly what to check first.

Result

The site went live at http://20.124.184.86. Finance dashboard loading in the browser. Pipeline completed in 46 seconds from push to live.

That moment of opening the browser and seeing the site running on my own VM, deployed by a pipeline I built myself, is one of those moments where the learning stops feeling abstract.

What I Took Away From This

A few things I want to flag for anyone building something similar:

Permissions matter more than the pipeline. You can write perfect YAML and still fail because the server will not allow the pipeline user to write to a folder. Always check file ownership on your deployment path before you wire anything up.

Static IPs are not optional. A dynamic IP will break your service connection silently. Fix the IP before you configure anything that references it.

SSH service connections without a verified badge are fine. The badge not turning green does not mean the connection is broken. The pipeline run is the real test.

Run your Ansible playbook before your first pipeline run. The order matters. Server should be fully configured before the pipeline ever tries to touch it.

This is Project 2 of 4 in the Azure DevOps series. Two down, two more to go.

Vivian Chiamaka Okose is a DevOps Engineer documenting her hands-on learning journey through real projects.

How I Set Up a Self-Hosted Azure DevOps Agent on Ubuntu (And What I Learned the Hard Way)

Vivian Chiamaka Okose — Fri, 10 Apr 2026 12:56:49 +0000

When you are just starting out with Azure DevOps, the managed Microsoft-hosted agents seem like the easy choice. Clean environment, no setup, just works.

Then you hit the parallelism limit on a free plan and everything queues.

That is what sent me down the path of setting up my own self-hosted agent. Here is exactly what I built and what tripped me up along the way.

What a Self-Hosted Agent Actually Is

An agent is the thing that executes your pipeline jobs. When Azure DevOps runs a pipeline, it needs a machine to do the work.

Microsoft-hosted agents are temporary VMs that spin up, do the job, and disappear. Convenient but limited.

A self-hosted agent is one you run yourself, on infrastructure you control. It stays running between jobs, keeps its installed software, and has no parallelism limits.

What I Built

Ubuntu 22.04 VM on Azure (Standard_D2s_v3)
A custom agent pool called SelfHostedPool
Azure Pipelines agent v4.271.0 installed as a system service
A test pipeline that confirmed everything was working

Step 1: Create a Personal Access Token

In Azure DevOps, click your profile picture at the top right, then go to Personal Access Tokens. Create a new one with:

Agent Pools: Read and Manage
Build: Read and Execute

Copy it immediately. You will not see it again.

Step 2: Create the Agent Pool

Go to Organization Settings, then Pipelines, then Agent Pools. Click Add Pool.

Type: Self-hosted
Name: SelfHostedPool
Grant access to all pipelines: checked

Step 3: Provision the VM

I created a Standard_D2s_v3 Ubuntu 22.04 VM on Azure via the portal. The key thing is opening port 443 for outbound communication. The agent talks to Azure DevOps over HTTPS.

Step 4: Get the Agent Download URL

This is where I ran into my first real obstacle. The standard download domain was not resolving. The fix was to get the download URL directly from the Azure DevOps API:

curl -s "https://dev.azure.com/YOUR_ORG/_apis/distributedtask/packages/agent/linux-x64?top=1&api-version=3.0" \
  -u :YOUR_PAT | grep "downloadUrl"

This gives you the exact URL for the latest agent version registered for your organization. Use that URL to download.

Step 5: Install and Configure

mkdir -p ~/azagent && cd ~/azagent
curl -fSL "DOWNLOAD_URL_FROM_ABOVE" -o vsts-agent-linux-x64-4.271.0.tar.gz
tar zxvf vsts-agent-linux-x64-4.271.0.tar.gz
./config.sh

When prompted, enter your organization URL, PAT, and pool name. Then start it as a service:

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

Active and running.

Step 6: Verify in Azure DevOps

Go to Organization Settings, then Agent Pools, then SelfHostedPool. Your agent should appear as Online.

The Test Pipeline

trigger:
  - main

pool:
  name: SelfHostedPool

steps:
  - script: uname -a
    displayName: System Info
  - script: whoami
    displayName: Current User
  - script: df -h
    displayName: Disk Usage

Run it. Watch all three steps execute on your VM. That green checkmark means your pipeline is running on infrastructure you built.

What I Learned

Running as a system service is not optional for real use. If you run the agent interactively with ./run.sh, it dies when your SSH session ends. Install it as a service so it runs permanently.

Port 443 must be open outbound, not inbound. The agent calls Azure DevOps, not the other way around.

The API download method is more reliable than guessing version numbers. Always use it.

This agent pool powered every pipeline in my Azure DevOps series. Projects 2, 3, and 4 all ran on it. Building it first was the right call.

Vivian Chiamaka Okose is a DevOps Engineer documenting her learning journey in public.

From Zero to Production: Deploying Applications on Azure with Ansible and Terraform

Vivian Chiamaka Okose — Wed, 01 Apr 2026 07:32:43 +0000

There's a point in every DevOps engineer's journey where things start to click. This week was that moment for me. Five assignments, one Azure subscription, and a whole lot of terminal output later — I now understand why teams reach for Ansible the moment they need to configure more than one server.

This post walks through everything I built this week: setting up a production-ready Ansible workstation, automating a fleet of 4 Azure VMs with ad-hoc commands, deploying a static website with a multi-play playbook, and finally deploying two applications using Terraform + Ansible together — including a production-grade role-based setup.

Assignment 1: Building a Production-Ready Ansible Workstation

Before touching a single server, real teams standardise their local environment. That means isolated dependencies, consistent editor settings, and automated quality checks that run before every commit.

The first thing I did was create an isolated Python virtual environment:

python3 -m venv .venv && source .venv/bin/activate
pip install ansible ansible-lint yamllint pre-commit

Why a venv? Because installing Ansible globally with sudo pip is a trap. Different projects need different Ansible versions, and a global install means one project can silently break another. The venv keeps everything contained and reproducible — anyone can clone the repo, run pip install -r requirements.txt, and get the exact same setup.

I then configured VS Code with the Red Hat Ansible extension, set up an ansible.cfg with team-standard defaults, generated an ED25519 SSH key, and wired up pre-commit hooks to run yamllint automatically before every commit. From that point on, badly formatted YAML couldn't even make it into the repo.

Assignment 2: Fleet Automation with Ad-Hoc Commands

With the workstation ready, it was time to actually talk to some servers. I provisioned 4 Azure Ubuntu VMs with Terraform — all in a single main.tf using a count loop:

variable "vm_roles" {
  default = ["web1", "web2", "app1", "db1"]
}

Each VM got its own public IP, network interface, and NSG association. The SSH key was injected at provisioning time via the admin_ssh_key block — no passwords, ever.

After provisioning, I created a custom inventory with proper groups:

[web]
40.85.254.41
20.104.112.32

[app]
20.48.180.237

[db]
20.48.183.157

Then came the ad-hoc commands. This is where Ansible really shines for quick fleet operations:

# Ping all hosts
ansible all -i inventory.ini -m ping

# Check uptime across the fleet
ansible all -i inventory.ini -m command -a "uptime"

# Install nginx on web servers only
ansible web -i inventory.ini -m apt -a "update_cache=yes name=nginx state=present" --become

The --become flag is how Ansible escalates to root for privileged operations. Without it, package installs would fail with permission errors.

Assignment 3: Multi-Play Playbook for Web Deployment

Ad-hoc commands are great for quick tasks, but anything repeatable belongs in a playbook. This assignment introduced multi-play structure — separating install, deploy, and verify into distinct plays.

---
- name: Install and Configure Web Server
  hosts: web
  become: true
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

- name: Deploy Static Website Content
  hosts: web
  become: true
  handlers:
    - name: reload nginx
      service:
        name: nginx
        state: reloaded
  tasks:
    - name: Deploy index.html
      copy:
        src: files/index.html
        dest: /var/www/html/index.html
        owner: www-data
        mode: '0644'
      notify: reload nginx

- name: Verify Deployment
  hosts: localhost
  connection: local
  tasks:
    - name: Check HTTP 200
      uri:
        url: "http://{{ web_ip }}"
        status_code: 200

Why split into three plays? Because each play has a different responsibility. Play 1 handles infrastructure-level concerns (is the web server installed?). Play 2 handles application concerns (is the right content deployed?). Play 3 handles verification from the outside, the way a user would actually experience it.

The copy module pushes files from the controller to the remote hosts. The file lives on your machine, Ansible handles the transfer. No Git clones needed on the target servers.

Assignment 4: Mini Finance Site with Terraform + Ansible

This assignment introduced the clean separation that production teams live by: Terraform provisions infrastructure, Ansible configures it.

Terraform created the full Azure stack — resource group, VNet, subnet, NSG with ports 22 and 80, public IP, and a single Ubuntu VM. The output gave me the IP address which fed directly into the Ansible inventory.

One thing I learned here — the git module in Ansible keeps the SSH connection open during the clone, which can time out on slow connections. The workaround is using the shell module with a shallow clone:

- name: Clone repo
  shell: git clone --depth 1 https://github.com/repo /var/www/html
  args:
    creates: /var/www/html/index.html

The creates argument makes this idempotent — if the file already exists, the task is skipped.

Assignment 5: Production-Grade EpicBook with Ansible Roles

This was the most complex assignment — and the most realistic. Instead of tasks in a single playbook, everything was organised into roles:

ansible/
├── roles/
│   ├── common/       # system updates, baseline packages, SSH hardening
│   ├── nginx/        # install, Jinja2 config template, site management
│   └── epicbook/     # app directory, repo clone, ownership, reload handler
├── group_vars/
│   └── web.yml       # shared variables across roles
└── site.yml          # role orchestration

The site.yml becomes beautifully simple:

---
- name: Prepare system
  hosts: web
  become: true
  roles:
    - common

- name: Install Nginx
  hosts: web
  become: true
  roles:
    - nginx

- name: Deploy EpicBook
  hosts: web
  become: true
  roles:
    - epicbook

The nginx role used a Jinja2 template for the server block — meaning the document root path comes from a variable, not hardcoded into the config. Change the variable, re-run the playbook, and the config updates automatically.

The real proof of quality was the idempotency check. Running the playbook a second time returned mostly ok with zero failures and one intentional skipped for the clone task. That's the standard. A playbook that changes things on every run is a liability.

Key Takeaways

Ansible's strength isn't just automation — it's automation you can reason about. Each task either changes something or it doesn't, and you can see exactly which at a glance. Roles take that further by making your automation reusable across projects. The common role I wrote this week could drop into any future project and just work.

The Terraform + Ansible combination is genuinely powerful. Terraform gives you consistent, reproducible infrastructure. Ansible gives you consistent, reproducible configuration. Together they cover the full lifecycle from "cloud resources don't exist" to "application is running and verified."

All code is available on GitHub: ansible-devops-week12

Building Production-Grade Infrastructure on Azure with Terraform: A Complete Three-Tier Architecture

Vivian Chiamaka Okose — Sat, 21 Mar 2026 07:15:37 +0000

Building Production-Grade Infrastructure on Azure with Terraform: A Complete Three-Tier Architecture

By Vivian Chiamaka Okose
Tags: #terraform #azure #devops #threetier #applicationgateway #mysql #nextjs #nodejs #iac #cloud #security

This is the project where everything clicked.

Not because it went smoothly -- it absolutely did not. A VM got compromised by a cryptominer midway through. Regional capacity restrictions blocked MySQL provisioning twice. An Application Gateway TLS policy error required a specific fix. An IP address changed mid-deployment and locked me out of my own server.

But every one of those problems had a solution. And working through each one taught me something that no tutorial could replicate.

This is the story of Assignment 5: deploying the Book Review App on Azure using a production-grade three-tier Terraform architecture.

The Architecture

This project uses a proper three-tier design with strict security boundaries between each layer:

Network Layer:

One VNet with CIDR 10.0.0.0/16
6 subnets across the address space: 2 web tier, 2 app tier, 2 database tier, plus a dedicated Application Gateway subnet
NSGs per tier with explicit inbound rules
Private DNS Zone for MySQL VNet integration

Compute Layer:

Web Tier VM running Next.js frontend via Nginx reverse proxy
App Tier VM running Node.js backend on port 5000 via PM2
Public Application Gateway fronting the web tier
Internal Load Balancer fronting the app tier

Database Layer:

Azure MySQL Flexible Server with private VNet integration
Not publicly accessible -- reachable only through the VNet
Delegated subnets for MySQL service

Why Multiple Terraform Files Matter

Previous projects used a single main.tf. This project used seven:

terraform-bookreview-azure/
  main.tf           # Provider and resource group
  networking.tf     # VNet, subnets, NSGs, DNS
  compute.tf        # VMs, NICs, public IPs
  loadbalancer.tf   # App Gateway and Internal LB
  database.tf       # MySQL Flexible Server
  variables.tf      # All configurable values
  outputs.tf        # Endpoints and IPs

This is not organisational preference -- it is a practical necessity at this scale. When the Application Gateway takes 9 minutes to provision and the MySQL server takes 7 minutes, you need to be able to read the plan output and understand which file to look at when something fails. A 500-line main.tf becomes unreadable. Separated files make the dependency chain visible.

The variables file also eliminates a security risk. Sensitive values like database passwords are defined once with sensitive = true, which prevents them from ever appearing in plan output or logs.

The NSG Design

Each tier has its own Network Security Group with rules specific to its role.

Web tier NSG allows HTTP (80), HTTPS (443) and SSH from a specific IP only:

security_rule {
  name                       = "Allow-SSH"
  priority                   = 120
  direction                  = "Inbound"
  access                     = "Allow"
  protocol                   = "Tcp"
  source_port_range          = "*"
  destination_port_range     = "22"
  source_address_prefix      = var.my_ip
  destination_address_prefix = "*"
}

App tier NSG allows port 3001 only from the web subnet CIDR:

security_rule {
  name                       = "Allow-App-Port"
  priority                   = 100
  direction                  = "Inbound"
  access                     = "Allow"
  protocol                   = "Tcp"
  source_port_range          = "*"
  destination_port_range     = "3001"
  source_address_prefix      = "10.0.1.0/24"
  destination_address_prefix = "*"
}

The database tier has no NSG rule for public access at all. MySQL is accessible only through the VNet integration. There is no port 3306 open to any external IP.

The Errors That Taught Me the Most

Error 1: MySQL Provisioning Disabled in UK South

Status: "ProvisioningDisabled"
Message: "Provisioning is restricted in this region."

Azure restricts MySQL Flexible Server provisioning in certain regions for free tier subscriptions. The fix was switching to West Europe. This is the kind of constraint you only discover by trying -- no documentation lists it clearly.

Error 2: Application Gateway Deprecated TLS Policy

ApplicationGatewayDeprecatedTlsVersionUsedInSslPolicy

Azure now requires an explicit modern TLS policy on Application Gateways. Adding this block resolved it:

ssl_policy {
  policy_type = "Predefined"
  policy_name = "AppGwSslPolicy20220101"
}

Error 3: Zone Not Available

Status: "ZoneNotAvailableForRegion"

Specifying zone = "1" for the MySQL server failed because that zone was not available. Removing the zone specification entirely let Azure pick an available zone automatically.

Error 4: Read Replica Not Supported on Burstable Tier

ReplicationNotSupportedForBurstableEdition

The B_Standard_B1ms burstable tier does not support read replicas. This requires the General Purpose tier which costs significantly more. For a learning environment, the replica was removed. In production, you would use GP_Standard_D2ds_v4 or similar.

The Security Incident

Midway through the first deployment, the PM2 logs showed something alarming:

xmrig-6.21.0/xmrig -o pool.supportxmr.com:443
scanner_linux -t 1000

The VM had been compromised by a cryptominer within hours of deployment. The attack vector was password authentication on port 22 open to 0.0.0.0/0. Automated bots scan the entire internet for open SSH ports and attempt common passwords. The password BookReview@1234! was not weak by typical standards, but brute force tools eventually found it.

The response was immediate:

Exit the compromised VM
Run terraform destroy to wipe all infrastructure
Rebuild with SSH key authentication and IP-restricted NSG rules

The rebuilt configuration:

resource "azurerm_linux_virtual_machine" "web_vm" {
  disable_password_authentication = true

  admin_ssh_key {
    username   = var.admin_username
    public_key = var.admin_ssh_public_key
  }
}

And the NSG SSH rule restricted to a specific IP:

source_address_prefix = var.my_ip  # "102.90.126.10/32"

SSH keys are mathematically impossible to brute force. A 4096-bit RSA key has more possible values than atoms in the observable universe. Combined with IP restriction, the attack surface becomes essentially zero.

This was not a lab exercise in security. It was a real attack on a real VM that I responded to in real time. That experience is worth more than any security tutorial.

The Application Deployment

After the secure rebuild, the deployment went cleanly:

Backend startup confirmation:

Database 'book_review_db' connected successfully with SSL!
✅ Database schema updated successfully!
👤 Sample users added!
📚 Sample books added!
✍️ Sample reviews added!
🚀 Server running on port 5000

Nginx configuration proxying port 80 to Next.js on 3000 and API calls to backend on 5000:

server {
    listen 80;
    server_name _;

    location /api/ {
        proxy_pass http://localhost:5000/api/;
        proxy_http_version 1.1;
        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;
    }
}

The app loaded with books, reviews, user registration and login all working end to end.

What I Now Understand About Production Infrastructure

Tier isolation is not optional. Each layer having its own NSG with explicit inbound rules means a compromise at the web tier cannot automatically reach the database. Defence in depth is built into the network topology itself.

Terraform file organisation is architecture documentation. When someone new joins a team, networking.tf tells them the network design. database.tf tells them the data tier. The files are the architecture diagram expressed in executable code.

IP addresses change. Dynamic IPs on home connections mean NSG rules need updating whenever your IP changes. In production this is handled with VPN gateways or jump boxes. In a learning environment, it means keeping terraform apply fast and knowing how to update a single variable without destroying everything.

The rebuild is not failure. Destroying compromised infrastructure and rebuilding from scratch with security fixes applied is exactly what the immutable infrastructure pattern is designed for. Terraform made that rebuild take 25 minutes instead of days.

What Is Next

This was the fifth and final project in my Terraform series. The full series covered Azure VMs, AWS EC2 with custom VPC, React app deployment, full-stack EpicBook with RDS, and this production three-tier architecture.

Each project built on the last. The networking patterns from Assignment 2 informed the VPC design in Assignment 4. The Nginx SPA configuration from Assignment 3 carried directly into Assignment 5. The RDS security group design from Assignment 4 shaped the MySQL VNet integration approach here.

That is what a curriculum looks like when it is designed properly. And that is what I am taking forward into the next chapter of this DevOps journey.

I document cloud infrastructure projects in public. Follow along for Terraform, AWS, Azure, and real-world DevOps engineering.

GitHub: vivianokose

Building a Three-Tier Bookstore App on AWS from Scratch: Infrastructure, Deployment, and Every Debug Along the Way

Vivian Chiamaka Okose — Fri, 20 Mar 2026 17:28:00 +0000

Building a Three-Tier Bookstore App on AWS from Scratch: Infrastructure, Deployment, and Every Debug Along the Way

By Vivian Chiamaka Okose
Tags: #aws #terraform #rds #nodejs #devops #threetier #mysql #nginx #cloud #iac

I recently completed a project that I would describe as the most satisfying and the most frustrating thing I have built so far in my DevOps journey -- in equal measure.

The goal was to deploy The EpicBook, a full-stack bookstore application, on AWS using Terraform. Not just spin up a VM and call it done. A proper three-tier architecture: network layer, compute layer, and a managed database layer, all defined as infrastructure as code, all connected through deliberate security boundaries.

This is the story of how I built it, what broke along the way, and what I now understand about cloud architecture that I did not before.

The Architecture

Before writing a single line of code, I mapped out what needed to exist:

Network tier: A custom VPC with a public subnet for the EC2 instance and a private subnet for the RDS database. Internet Gateway, Route Table, and Route Table Association for public internet access. Two security groups -- one for EC2 and one for RDS -- with a deliberate trust boundary between them.

Compute tier: An EC2 t3.micro instance running Ubuntu 22.04 in the public subnet. Node.js 18 via nvm, Nginx as a reverse proxy, and the EpicBook Node.js application running on port 8080.

Database tier: Amazon RDS MySQL 8.0 in the private subnet. Not publicly accessible. Reachable only from the EC2 security group on port 3306.

Eleven Terraform resources total. One configuration, three files.

Why Three Files Instead of One?

For the first three projects in this series, I kept everything in a single main.tf. That works fine for small deployments. For this project, I split the configuration into three files:

variables.tf for all configurable values (region, CIDR blocks, instance types, credentials)
main.tf for all resource definitions
outputs.tf for what gets printed after deployment

The reason this matters: variables.tf eliminates hardcoded values scattered across resources. If I need to change the AWS region or the database password, I change one line in variables.tf and it propagates everywhere automatically. The sensitive = true flag on the database password means Terraform never prints it in plan output or logs:

variable "db_password" {
  description = "Master password for RDS"
  type        = string
  default     = "EpicBook123!"
  sensitive   = true
}

This is not just organisation. It is the foundation of maintainable infrastructure code.

The Security Design That Matters Most

This is the part of the project I am most proud of from an engineering perspective.

The RDS security group does not allow access from a CIDR block. It allows access specifically from the EC2 security group:

resource "aws_security_group" "rds_sg" {
  name        = "epicbook-rds-sg"
  description = "Allow MySQL from EC2 only"
  vpc_id      = aws_vpc.epicbook_vpc.id

  ingress {
    description     = "MySQL from EC2"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.ec2_sg.id]
  }
}

The difference is significant. A CIDR-based rule allows any resource in that IP range to reach the database. A security group reference allows only resources that belong to that specific security group. Even if another VM appeared in the same subnet with the same IP range, it could not reach the database unless it was explicitly assigned the EC2 security group.

This is zero-trust networking applied at the infrastructure layer. The database is unreachable from the internet, unreachable from other VPC resources, and reachable only from the specific compute layer we defined.

Deployment: What Went Smoothly

The Terraform apply ran cleanly:

Apply complete! Resources: 11 added, 0 changed, 0 destroyed.

Outputs:
ec2_public_ip  = "16.28.105.178"
rds_endpoint   = "epicbook-rds.c9yasg0i2xal.af-south-1.rds.amazonaws.com:3306"
rds_port       = 3306

The RDS instance took about 5 minutes to provision, which is normal. AWS is provisioning a managed database with storage, parameter groups, and subnet associations. That takes time.

The RDS connection test from EC2 worked immediately:

mysql -h epicbook-rds.c9yasg0i2xal.af-south-1.rds.amazonaws.com \
  -u admin -pEpicBook123! -P 3306 epicbook

Welcome to the MySQL monitor.
Server version: 8.0.44
mysql>

That connection working on the first try confirmed the security group design was correct.

Deployment: What Did Not Go Smoothly

Here is where the real learning happened.

Problem 1: The apt Lock

Ubuntu's default apt repository ships Node.js v12, which is too old for the EpicBook application. When I tried to upgrade via NodeSource, the setup script ran apt install internally, which conflicted with a background system update process that had locked the package manager:

E: Could not get lock /var/lib/dpkg/lock-frontend.
It is held by process 24847 (apt)

The fix was to bypass apt entirely using nvm, the Node Version Manager:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 18
nvm use 18
node -v  # v18.20.8

nvm downloads Node.js directly from the official distribution and installs it in the user's home directory. No package manager. No lock conflicts. No sudo required. This is the correct approach for application servers where you need a specific Node.js version and cannot wait for the package manager.

Problem 2: Hardcoded Database Names in SQL Files

The EpicBook repository includes SQL files for creating tables and seeding data. Those files were written for a database named bookstore, but the RDS database I provisioned is named epicbook. Running the files directly produced errors:

ERROR 1049 (42000): Unknown database 'bookstore'

The fix was sed, a command-line tool for stream editing text:

sed 's/bookstore/epicbook/g' db/BuyTheBook_Schema.sql > db/epicbook_schema.sql
sed 's/bookstore/epicbook/g' db/author_seed.sql > db/epicbook_author_seed.sql
sed 's/bookstore/epicbook/g' db/books_seed.sql > db/epicbook_books_seed.sql

This replaced every occurrence of bookstore with epicbook across all three files in seconds. The result: 53 authors and 54 books loaded cleanly into RDS.

Problem 3: Application Configuration

The config/config.json file shipped with the repository pointed to 127.0.0.1 (localhost). Running the app without updating this would have produced a connection refused error because there is no local MySQL server -- the database is RDS.

The updated configuration:

{
  "development": {
    "username": "admin",
    "password": "EpicBook123!",
    "database": "epicbook",
    "host": "epicbook-rds.c9yasg0i2xal.af-south-1.rds.amazonaws.com",
    "dialect": "mysql",
    "port": 3306
  }
}

Always verify application configuration against infrastructure outputs before starting a service. The outputs.tf file exists precisely for this reason.

The Result

going to html route
App listening on PORT 8080

Visiting http://16.28.105.178 loaded The EpicBook homepage with the full book catalogue from RDS. The cart accepted items, calculated totals, and processed orders end to end.

The Nginx reverse proxy configuration that made this work:

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://localhost:8080;
        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;
    }
}

Port 80 receives public traffic. Nginx forwards it to port 8080 where Node.js is running. The application never needs to run as root or bind to a privileged port.

What I Now Understand Differently

Security groups as identity, not location. Referencing a security group in an ingress rule is fundamentally different from specifying a CIDR block. It grants access based on what a resource is, not where it is. This is more secure and more maintainable.

nvm over apt for Node.js. On production servers, package manager locks, version staleness, and permission issues make apt a poor choice for language runtime management. nvm, pyenv, rbenv -- the language-specific version managers exist for good reasons.

sed for operational configuration fixes. When application configuration files have hardcoded values that do not match your infrastructure, sed is the fast, scriptable, auditable fix. It is a tool every DevOps engineer should be comfortable with.

Outputs.tf is a first-class deliverable. The RDS endpoint, EC2 IP, and port values printed after apply are not just convenient -- they are the interface between your infrastructure layer and your application configuration layer. Design them deliberately.

What Is Next

The final project in this series is the production-grade version: a six-subnet three-tier architecture across two availability zones, public and internal load balancers, RDS with multi-AZ and read replicas. Everything from this project applies -- the security group design, the variable structure, the application deployment patterns -- just at production scale.

I build and document cloud infrastructure projects in public. Follow along for Terraform, AWS, Azure, and real-world DevOps from someone who started in biochemistry and is building toward cloud engineering one deployment at a time.

GitHub: vivianokose

Nginx + React: How to Serve a Single Page Application Correctly (And Why Most Tutorials Get It Wrong)

Vivian Chiamaka Okose — Thu, 19 Mar 2026 19:20:16 +0000

Nginx + React: How to Serve a Single Page Application Correctly (And Why Most Tutorials Get It Wrong)

By Vivian Chiamaka Okose
Tags: #nginx #react #terraform #azure #devops #spa #nodejs #cloud #beginners

There is one Nginx configuration line that every React developer deploying to a Linux server needs to know. Most tutorials skip past it without explanation. I learned it the hard way -- by understanding exactly what breaks without it.

This is the story of Assignment 3 of my Terraform series: provisioning an Azure VM with Terraform, deploying a React application on it, and configuring Nginx to serve it correctly. Along the way I hit a Node.js version incompatibility and learned why try_files $uri /index.html is not optional for SPAs.

What I Built

Using Terraform, I provisioned the following on Microsoft Azure:

A Resource Group, Virtual Network, and Subnet
A Network Security Group with explicit SSH and HTTP rules
An NSG Association linking the security group to the subnet
A Static Public IP and Network Interface
An Ubuntu 20.04 LTS VM (Standard_D2ads_v7) at 20.90.152.5

Then on the VM itself:

Upgraded Node.js from v10 to v18.20.8 LTS
Installed and configured Nginx
Cloned, personalised, and built a React application
Deployed it to Nginx and configured SPA routing
Verified it live in the browser with my name on the page

Eight Terraform resources. One live React application. One important Nginx lesson.

The New Infrastructure Piece: Network Security Groups

Assignment 3 introduced something Assignment 1 did not have -- an explicit firewall.

In Azure, a Network Security Group (NSG) is the resource that controls inbound and outbound traffic rules at the subnet or NIC level. Without one, your VM has no defined firewall rules. This is a security risk in production.

resource "azurerm_network_security_group" "nsg" {
  name                = "react-nsg"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  security_rule {
    name                       = "Allow-SSH"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "Allow-HTTP"
    priority                   = 110
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

resource "azurerm_subnet_network_security_group_association" "nsg_assoc" {
  subnet_id                 = azurerm_subnet.subnet.id
  network_security_group_id = azurerm_network_security_group.nsg.id
}

The critical detail here is the association resource. Creating the NSG alone does nothing -- you have to explicitly link it to the subnet. This is the same pattern as AWS Route Table Associations from Assignment 2. Both clouds require an explicit linking step that is easy to forget and produces silent failures when missing.

Problem 1: Node.js Version Incompatibility

After SSH-ing into the VM, I installed Node.js and npm using the default Ubuntu apt package:

sudo apt update && sudo apt install nodejs npm git -y
node -v  # v10.19.0
npm -v   # 6.14.4

Running npm install produced a wall of warnings:

npm WARN notsup Unsupported engine for react-scripts@5.0.1:
wanted: {"node":">=14.0.0"} (current: {"node":"10.19.0"})

The React app requires Node.js 14 or higher. Ubuntu 20.04's default repository ships Node.js 10 because it prioritises stability. This is a real-world operational gap that catches many developers who assume the default package manager always ships current versions.

The fix: install from the NodeSource repository which ships maintained Node.js versions:

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
node -v  # v18.20.8
npm -v   # 10.8.2

Then clean and reinstall dependencies:

rm -rf node_modules
npm install

Clean install, no compatibility errors.

Problem 2 (That I Avoided): The SPA Routing Problem

This is the lesson I want to spend time on because it is the one most tutorials gloss over.

A React application is a Single Page Application. There is exactly one HTML file -- index.html -- and React's JavaScript router intercepts navigation events in the browser to simulate different pages without ever making a new server request.

When you type http://yourserver.com/about in the browser, here is what happens:

Without the correct Nginx config: Nginx receives a request for /about. It looks for a file called about or about/index.html in /var/www/html. That file does not exist. Nginx returns a 404. Your React app never loads.

With the correct Nginx config: Nginx receives a request for /about. It checks for the file, does not find it, falls back to index.html, and returns that. React loads, reads the URL, and renders the About component. Everything works.

The configuration that makes this happen is one directive:

server {
    listen 80;
    server_name _;
    root /var/www/html;
    index index.html;

    location / {
        try_files $uri /index.html;
    }
    error_page 404 /index.html;
}

try_files $uri /index.html means: "try to find a file matching the URI, and if you can not find one, serve index.html instead."

This is not optional. Without it, your React app works fine when users enter from the homepage, but any direct link, browser refresh, or bookmark to an inner page returns a 404. In production this is a user experience failure that can be hard to diagnose if you do not know what to look for.

This pattern is identical for Vue.js, Angular, and any other SPA framework. Learn it once, use it everywhere.

The Build and Deploy Flow

# Personalise the app
cd ~/my-react-app/src
nano App.js
# Updated: Deployed by: Vivian Chiamaka Okose | Date: 19/03/2026

# Install dependencies and build
cd ..
npm install
npm run build

# Output:
# Compiled successfully.
# 61.25 kB  build/static/js/main.d869c525.js

# Deploy to Nginx web root
sudo rm -rf /var/www/html/*
sudo cp -r build/* /var/www/html/
sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html
sudo systemctl restart nginx

Then visiting http://20.90.152.5 in the browser:

Welcome to My React App
This app is running on Nginx!
Deployed by: Vivian Chiamaka Okose
Date: 19/03/2026

Infrastructure I built with Terraform. Application I deployed manually. My name on the page. Live on the internet.

The Complete main.tf

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = false
    }
  }
}

resource "azurerm_resource_group" "rg" {
  name     = "react-app-rg"
  location = "UK South"
}

resource "azurerm_virtual_network" "vnet" {
  name                = "react-vnet"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "subnet" {
  name                 = "react-subnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

resource "azurerm_network_security_group" "nsg" {
  name                = "react-nsg"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  security_rule {
    name                       = "Allow-SSH"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "Allow-HTTP"
    priority                   = 110
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

resource "azurerm_subnet_network_security_group_association" "nsg_assoc" {
  subnet_id                 = azurerm_subnet.subnet.id
  network_security_group_id = azurerm_network_security_group.nsg.id
}

resource "azurerm_public_ip" "public_ip" {
  name                = "react-public-ip"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  allocation_method   = "Static"
  sku                 = "Standard"
}

resource "azurerm_network_interface" "nic" {
  name                = "react-nic"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.public_ip.id
  }
}

resource "azurerm_virtual_machine" "vm" {
  name                             = "react-vm"
  location                         = azurerm_resource_group.rg.location
  resource_group_name              = azurerm_resource_group.rg.name
  network_interface_ids            = [azurerm_network_interface.nic.id]
  vm_size                          = "Standard_D2ads_v7"
  delete_os_disk_on_termination    = true
  delete_data_disks_on_termination = true

  os_profile {
    computer_name  = "react-vm"
    admin_username = "azureuser"
    admin_password = "P@ssw0rd1234!"
  }

  os_profile_linux_config {
    disable_password_authentication = false
  }

  storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-focal"
    sku       = "20_04-lts-gen2"
    version   = "latest"
  }

  storage_os_disk {
    name              = "react-os-disk"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
}

output "public_ip_address" {
  description = "The public IP address of the VM"
  value       = azurerm_public_ip.public_ip.ip_address
}

Key Takeaways

NSG + Association is a two-step pattern. Creating the NSG defines the rules. The association activates them on the subnet. Both steps are required.

Ubuntu's default Node.js is outdated. Always install from NodeSource or nvm for any modern JavaScript application.

try_files $uri /index.html is mandatory for React SPAs. Without it, direct navigation and browser refreshes return 404 errors. This applies to all SPA frameworks.

npm install warnings are not errors. The deprecated and warn messages are informational. Watch for notsup messages -- those indicate genuine compatibility issues that need fixing before the build.

I am documenting my complete DevOps learning journey in public -- one deployment at a time.

GitHub: vivianokose

My Second Terraform Deployment: Building a Complete AWS Network from Scratch (And What I Learned That Surprised Me)

Vivian Chiamaka Okose — Tue, 17 Mar 2026 15:50:33 +0000

By Vivian Chiamaka Okose

I previously talked about how I learned how to provision a virtual machine on Azure. This present task taught me how networking actually works.

That might sound like an exaggeration, but it is not. When you have to build every single layer of a cloud network by hand -- in code -- and watch each piece slot into place before the next one can exist, something clicks that no amount of reading diagrams ever produces.

This is the story of my second Terraform deployment: an AWS EC2 instance inside a custom VPC, accessible via SSH, running Nginx. Eight resources, one configuration file, and a few lessons I will carry into every cloud project I work on.

What I Built

A custom VPC with CIDR 10.0.0.0/16 and DNS support enabled
A public subnet (10.0.1.0/24) in af-south-1a with auto-assign public IP
A private subnet (10.0.2.0/24) in af-south-1b for future backend resources
An Internet Gateway attached to the VPC
A Route Table routing all outbound traffic through the IGW
A Route Table Association linking the public subnet to that route table
A Security Group allowing SSH (port 22) and HTTP (port 80)
An EC2 instance running Ubuntu 22.04, accessible via SSH with Nginx installed

Eight resources. All defined in Terraform. All deployed in under two minutes.

The Four-Piece AWS Networking Puzzle

This is the single most important thing I learned in this assignment.

In AWS, internet connectivity for a resource requires four things working together:

1. A VPC -- your isolated private network. Think of it as your building.

2. An Internet Gateway (IGW) -- the physical door connecting your building to the outside world. Without this, nothing gets in or out, regardless of what IP addresses you assign.

3. A Route Table with an internet route -- the signpost that says "all traffic going outside? Use the front door (IGW)." The route 0.0.0.0/0 -> igw is that signpost.

4. A Route Table Association -- the act of putting that signpost specifically in your public subnet. Without this, the signpost exists but your subnet is not reading it.

Miss any one of these four and your EC2 has no internet access even with a public IP assigned. The public IP is just a label -- the routing infrastructure is what makes it actually reachable.

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

# The signpost
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

# Putting the signpost in the right subnet
resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public_rt.id
}

Once this pattern clicked, I could see it everywhere in cloud architecture diagrams. It is one of those fundamentals that everything else builds on.

The Complete main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "af-south-1"
}

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "terraform-vpc" }
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "af-south-1a"
  tags = { Name = "terraform-public-subnet" }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "af-south-1b"
  tags = { Name = "terraform-private-subnet" }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = { Name = "terraform-igw" }
}

resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "terraform-public-rt" }
}

resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public_rt.id
}

resource "aws_security_group" "ec2_sg" {
  name        = "terraform-ec2-sg"
  description = "Allow SSH and HTTP"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = { Name = "terraform-ec2-sg" }
}

resource "aws_instance" "ec2" {
  ami                         = "ami-0f256846cac23da94"
  instance_type               = "t3.micro"
  subnet_id                   = aws_subnet.public.id
  vpc_security_group_ids      = [aws_security_group.ec2_sg.id]
  associate_public_ip_address = true
  key_name                    = "terraform-ec2-key"
  tags = { Name = "terraform-ec2" }
}

output "ec2_public_ip" {
  description = "Public IP of the EC2 instance"
  value       = aws_instance.ec2.public_ip
}

SSH Key Pairs and Immutable Infrastructure

AWS EC2 uses SSH key pairs for authentication rather than passwords. I created the key pair before applying the configuration:

mkdir -p ~/.ssh
aws ec2 create-key-pair \
  --key-name terraform-ec2-key \
  --region af-south-1 \
  --query "KeyMaterial" \
  --output text > ~/.ssh/terraform-ec2-key.pem
chmod 400 ~/.ssh/terraform-ec2-key.pem

Something interesting: key_name is an immutable attribute on EC2 instances. You cannot attach a key pair to an already-running instance -- Terraform has to destroy and recreate it. This is immutable infrastructure in action. Some changes are too fundamental to apply in place. In production, this means a planned maintenance window. Understanding the difference between mutable and immutable attributes is an essential Terraform operations skill.

Deployment and Verification

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
ec2_public_ip = "13.246.221.152"

SSH into the instance:

ssh -i ~/.ssh/terraform-ec2-key.pem ubuntu@13.246.221.152
# Welcome to Ubuntu 22.04.4 LTS
# ubuntu@ip-10-0-1-134:~$

The private IP 10.0.1.134 confirmed the instance was sitting exactly where I placed it -- inside the 10.0.1.0/24 public subnet.

After installing Nginx and visiting http://13.246.221.152, the welcome page loaded. Infrastructure I built with code, serving traffic over the public internet.

AWS vs Azure: A Quick Comparison

Having completed both assignments back to back, the contrast is clear. Azure handles some connectivity implicitly. AWS is explicit about everything -- every routing layer is your responsibility to declare. This is more verbose but builds genuine understanding because nothing is hidden from you.

Neither is better in absolute terms. But the AWS approach forces you to understand networking deeply, which makes you a better cloud engineer on any platform.

I am documenting my full DevOps learning journey in public. Follow along for Terraform, AWS, Azure, and real-world infrastructure lessons.

GitHub: vivianokose

How I Provisioned My First Azure VM with Terraform (And the 5 Errors That Taught Me More Than Any Tutorial)

Vivian Chiamaka Okose — Mon, 16 Mar 2026 20:54:27 +0000

By Vivian Chiamaka Okose
Published on dev.to | Hashnode | Medium
Tags: #terraform #azure #devops #iac #beginners #cloud

I come from a background in biochemistry and biotechnology. A year ago, "infrastructure" to me meant lab equipment and sample storage. Today, I just provisioned a fully networked Azure virtual machine using nothing but code -- and destroyed it just as cleanly when I was done.

This is the story of how that happened, including every error I hit along the way.

What Is Terraform and Why Does It Matter?

Before I get into the how, let me explain the what.

Terraform is an Infrastructure as Code (IaC) tool built by HashiCorp. Instead of clicking around in the Azure portal to create resources, you write a configuration file that describes what you want your infrastructure to look like, and Terraform figures out how to make it happen. Every resource, every network setting, every dependency -- all defined in code, all version-controllable, all reproducible.

This matters because clicking around in a cloud console is not scalable. If you need to spin up the same environment ten times across ten different projects, you can not manually recreate it each time without introducing inconsistencies. With Terraform, you write it once and deploy it as many times as you need.

That is the power of Infrastructure as Code.

What I Built

For this assignment, I provisioned a complete virtual machine setup on Microsoft Azure using Terraform. Here is what the final infrastructure looked like:

Resource Group -- a logical container for all related resources
Virtual Network (VNet) -- the private network space (10.0.0.0/16)
Subnet -- a segment carved out of the VNet (10.0.1.0/24)
Public IP -- a static, externally reachable IP address
Network Interface Card (NIC) -- the bridge connecting the VM to the network
Virtual Machine -- Ubuntu 20.04 LTS Gen2 running on Standard_D2ads_v7

Six resources, all provisioned from a single main.tf file.

Setting Up the Environment

I run WSL2 Ubuntu on Windows, so the first step was installing Terraform and the Azure CLI directly in my WSL terminal.

Installing Terraform:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt-get install terraform -y
terraform -v
# Terraform v1.14.7

Installing and authenticating Azure CLI:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login
az account show

After az login, I authenticated through the browser device flow and confirmed my subscription was active. With that done, Terraform had everything it needed to talk to Azure.

The main.tf File

Here is the complete configuration I ended up with after troubleshooting (more on that shortly):

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = false
    }
  }
}

resource "azurerm_resource_group" "rg" {
  name     = "terraform-azure-vm-rg"
  location = "UK South"
}

resource "azurerm_virtual_network" "vnet" {
  name                = "terraform-vnet"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "subnet" {
  name                 = "terraform-subnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

resource "azurerm_public_ip" "public_ip" {
  name                = "terraform-public-ip"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  allocation_method   = "Static"
  sku                 = "Standard"
}

resource "azurerm_network_interface" "nic" {
  name                = "terraform-nic"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.public_ip.id
  }
}

resource "azurerm_virtual_machine" "vm" {
  name                             = "terraform-vm"
  location                         = azurerm_resource_group.rg.location
  resource_group_name              = azurerm_resource_group.rg.name
  network_interface_ids            = [azurerm_network_interface.nic.id]
  vm_size                          = "Standard_D2ads_v7"
  delete_os_disk_on_termination    = true
  delete_data_disks_on_termination = true

  os_profile {
    computer_name  = "terraform-vm"
    admin_username = "azureuser"
    admin_password = "P@ssw0rd1234!"
  }

  os_profile_linux_config {
    disable_password_authentication = false
  }

  storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-focal"
    sku       = "20_04-lts-gen2"
    version   = "latest"
  }

  storage_os_disk {
    name              = "terraform-os-disk"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
}

output "public_ip_address" {
  description = "The public IP address of the VM"
  value       = azurerm_public_ip.public_ip.ip_address
}

Notice how resources reference each other using dot notation -- azurerm_resource_group.rg.location instead of hardcoding "UK South" everywhere. This is not just clean code; it means if you change the location in one place, it updates throughout the entire configuration automatically.

The Deployment Flow

terraform init    # Download the AzureRM provider plugin
terraform plan    # Preview what will be created (dry run)
terraform apply   # Actually deploy to Azure

The terraform plan output is one of my favourite things about this tool. Before touching a single resource, it shows you exactly what it intends to create, change, or destroy -- marked with +, ~, or -. You can review and catch mistakes before they cost you money or cause an outage.

The 5 Errors That Actually Taught Me DevOps

Here is where things got real. I did not get a clean deployment on the first try. I got five errors, and each one taught me something important.

Error 1: Basic SKU Public IP Quota

IPv4BasicSkuPublicIpCountLimitReached: Cannot create more than 0 IPv4
Basic SKU public IP addresses for this subscription in this region.

What happened: Azure free-tier subscriptions have a quota of zero Basic SKU public IPs. The fix was adding sku = "Standard" to the public IP resource. One line. Lesson: always check your subscription quotas before deploying.

Error 2: VM Size Capacity Restriction

SkuNotAvailable: The requested VM size Standard_B1s is currently not
available in location 'eastus'.

What happened: The B-series VMs are restricted on free-tier subscriptions. Rather than guessing another size, I queried Azure directly:

az vm list-skus --location uksouth --resource-type virtualMachines --output table | grep "None"

This returned every VM size with no restrictions on my subscription, and I picked Standard_D2ads_v7 -- a small, affordable D-series with AMD processor. Always let the platform tell you what is available rather than guessing.

Error 3: Hypervisor Generation Mismatch

BadRequest: The selected VM size 'Standard_D2ads_v7' cannot boot
Hypervisor Generation '1'.

What happened: Modern VM sizes like D2ads_v7 require Generation 2 images, but Ubuntu 18.04 LTS is a Generation 1 image. Mixing them causes a boot failure at the hypervisor level. The fix was switching to Ubuntu 20.04 LTS Gen2 -- a newer, more secure image that is Gen2 compatible.

Error 4: Platform Image Not Found

PlatformImageNotFound: The platform image
'Canonical:UbuntuServer:20_04-lts-gen2:latest' is not available.

What happened: Azure's image naming is inconsistent across regions. The offer name UbuntuServer is a legacy name that does not include Gen2 images in UK South. I queried the available images directly:

az vm image list --location uksouth --publisher Canonical --offer 0001-com-ubuntu-server-focal --all --output table | grep "gen2"

The correct offer was 0001-com-ubuntu-server-focal with SKU 20_04-lts-gen2. Never assume image names -- always verify for your region.

Error 5: OS Disk Blocking Destroy

Error: deleting Resource Group "terraform-azure-vm-rg": the Resource Group
still contains Resources.
/Microsoft.Compute/disks/terraform-os-disk

What happened: When Azure creates a VM, it automatically provisions an OS disk as a child resource. Since our Terraform configuration did not explicitly manage that disk, it was not tracked in Terraform state -- so Terraform refused to delete the resource group containing it. The fix was adding two flags directly to the VM resource:

delete_os_disk_on_termination    = true
delete_data_disks_on_termination = true

The Successful Deployment

After all five fixes, the final terraform apply ran cleanly:

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Outputs:
public_ip_address = "51.11.128.165"

Verification via Azure CLI:

az vm list -d --query "[].{Name:name, Status:powerState}" --output table

Name          Status
------------  ----------
terraform-vm  VM running

And then a clean destroy:

terraform destroy
# Destroy complete! Resources: 1 destroyed.

Key Concepts I Now Understand Deeply

Declarative vs Imperative: Terraform is declarative -- you describe the desired end state, not the steps to get there. Terraform computes the steps automatically based on resource dependencies.

Providers: Plugins that teach Terraform how to communicate with a specific cloud platform. The azurerm provider is what lets Terraform understand Azure-specific resources.

State: Terraform maintains a state file that maps your configuration to real-world resources. This is how it knows what exists, what needs to change, and what to destroy.

Resource References: Using azurerm_resource_group.rg.location instead of hardcoded values keeps configurations flexible and consistent across every resource.

What Is Next

This was Assignment 1 of a five-assignment Terraform series. Next up: deploying an EC2 instance on AWS inside a custom VPC with public and private subnets. The networking complexity goes up significantly, and I am here for it.

If you are just starting your DevOps journey, my biggest takeaway from this exercise is this: do not fear the errors. Every error message is documentation. Read it carefully, query the platform for what it actually supports, and fix one thing at a time. That systematic approach is what DevOps engineering is really about.

Follow along as I document this full Terraform journey. I write about DevOps, cloud infrastructure, and what it actually looks like to transition into tech from a completely different background.

GitHub: vivianokose