DEV Community: Isaiah Izibili

Building a Multi-Cloud Infrastructure with Terraform (AWS + Azure)

Isaiah Izibili — Fri, 06 Mar 2026 01:41:13 +0000

Introduction

In modern cloud engineering, organizations increasingly adopt multi-cloud strategies to improve resilience, avoid vendor lock-in, and optimize cost.

In this project, I designed and deployed infrastructure across:

Amazon Web Services (AWS)
Microsoft Azure

Using a single Infrastructure as Code (IaC) tool:

🛠 Terraform

This article explains the architecture, configuration, deployment steps, and lessons learned.

Project Architecture Overview

AWS Resources

EC2 Instance (Ubuntu Server)
RDS MySQL Database

Azure Resources

Resource Group
Virtual Network + Subnet
Windows Virtual Machine
IIS Web Server
Public IP + NSG

All provisioned using Terraform providers for both clouds.

Step 1: Install Prerequisites

Before starting, install:

Terraform
AWS CLI
Azure CLI
Git
VS Code

Install Terraform
HashiCorp distributes Terraform as an executable CLI that you can install on supported operating systems, including Microsoft Windows, macOS, and several Linux distributions. You can also compile the Terraform CLI from source if a pre-compiled binary is not available for your system.

If you use a package manager to install software on your macOS, Windows, or Linux system, you can use it to install Terraform. For this project, the focus will be on the Windows installation.

Chocolatey https://chocolatey.org/is a free and open-source package management system for Windows. If you have Chocolatey installed, use it to install Terraform from your command line.

choco install terraform

NOTE: HashiCorp does not maintain Chocolatey or the Terraform package. The latest version of Terraform is always available for you to download and install manually. Refer to the Manual installation tab below for instructions.

Verify the Installation
Verify that the installation worked by opening a new terminal session and listing Terraform's available subcommands.

terraform -help

Install AWS CLI

For Windows:
Download the installer from AWS CLI official page (docs.aws.amazon.com in Bing).
Run the .msi installer and follow the prompts.

Verify installation with:

aws --version

Configure AWS CLI

Once installed, configure it with your credentials:

aws configure

It will ask for:

Install Azure CLI

For Windows:

Download the installer from Microsoft’s official page.
Run the .msi installer and follow the prompts.
Verify installation:

az --version

Step 2: Authenticate with Cloud Providers

AWS Login

aws configure

Provide:

AWS Access Key ID
AWS Secret Access Key
Default region name (e.g., us-east-1)
Default output format (e.g., json)

NOTE: Your AWS Access key and ID must have been created in your AWS console. For security purpose we advise creating a USER and GROUP under IAM resources.

Azure Login

az login

A browser window will open for you to authenticate with your Azure account.
Once logged in, the terminal will display your subscription details. Verify subscription:

az account show

Step 3: Define Terraform Providers

Create terraform.tf:

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

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

provider "aws" {
  region = "us-east-1"
}

provider "azurerm" {
  features {}
}

Note: terraform.tf is usually used for Terraform settings or backend configuration.
What goes inside: Terraform version, Required providers, Backend configuration

Step 4: Create AWS and Azure Infrastructure

Create main.tf (Complete Working Script):

AWS Resources: EC2 Instance, AWS RDS MySQL Database,

Azure Resources: Resource Group, Virtual Machine, Web Application

############################################
# Get Latest Ubuntu 22.04 AMI
############################################
data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

############################################
# Create EC2 Instance
############################################
resource "aws_instance" "isaiah" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "isaiah"
  }
}
#Get default VPC
data "aws_vpc" "default" {
  default = true
}

#GET subnets in default VPC
data "aws_subnets" "default" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.default.id]
  }
}

#Create Security Group for RDS
resource "aws_security_group" "rds_sg" {
  name   = "isaiah-rds-sg"
  vpc_id = data.aws_vpc.default.id

  ingress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # ⚠️ for testing only
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

#Create RDS Module
module "db" {
  source  = "terraform-aws-modules/rds/aws"
  version = "~> 6.0"

  identifier = "isaiah-demodb"

  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"   # cheaper for testing
  allocated_storage    = 20

  db_name  = "demodb"
  username = "isaiah"
  password = "IsaiahStrongPassword123!"   # change this
  port     = 3306

  publicly_accessible = true

  vpc_security_group_ids = [aws_security_group.rds_sg.id]

  create_db_subnet_group = true
  subnet_ids             = data.aws_subnets.default.ids

  family               = "mysql8.0"
  major_engine_version = "8.0"

  skip_final_snapshot = true
  deletion_protection = false

  tags = {
    Owner       = "Isaiah"
    Environment = "dev"
  }
}

#add random suffix
resource "random_string" "suffix" {
  length  = 5
  special = false
  upper   = false
}

#Resource group for Azure
resource "azurerm_resource_group" "isaiah_rg" {
  name     = "isaiah-webapp-rg"
  location = "West us 3"
}

#Add service plan
resource "azurerm_service_plan" "isaiah_plan" {
  name                = "isaiah-service-plan"
  resource_group_name = azurerm_resource_group.isaiah_rg.name
  location            = azurerm_resource_group.isaiah_rg.location
  sku_name            = "P1v2"
  os_type             = "Windows"
}

#Customize windows web app
resource "azurerm_windows_web_app" "isaiah_app" {
  name                = "isaiah-app-${random_string.suffix.result}"
  resource_group_name = azurerm_resource_group.isaiah_rg.name
  location            = azurerm_resource_group.isaiah_rg.location
  service_plan_id     = azurerm_service_plan.isaiah_plan.id

  site_config {
    always_on = true
  }

  app_settings = {
    "ENVIRONMENT" = "Production"
    "OWNER"       = "Isaiah"
    "WEBSITE_RUN_FROM_PACKAGE" = "1"
  }

  connection_string {
    name  = "Database"
    type  = "MySql"
    value = "Server=myserver.mysql.database.azure.com;Database=mydb;User Id=isaiah;Password=StrongPassword123;"
  }

  tags = {
    Owner       = "Isaiah"
    Environment = "Dev"
  }
}

# Create Resource Group
resource "azurerm_resource_group" "rg" {
  location = var.resource_group_location
  name     = "${var.prefix}-rg"
}

# Virtual Network
resource "azurerm_virtual_network" "vnet" {
  name                = "${var.prefix}-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

# Subnet
resource "azurerm_subnet" "subnet" {
  name                 = "${var.prefix}-subnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

# Public IP
resource "azurerm_public_ip" "public_ip" {
  name                = "${var.prefix}-public-ip"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  allocation_method   = "Static"
  sku                 = "Standard"
}

# Network Security Group
resource "azurerm_network_security_group" "nsg" {
  name                = "${var.prefix}-nsg"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  # RDP (You should replace with your public IP)
  security_rule {
    name                       = "Allow-RDP"
    priority                   = 1000
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "3389"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

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

# Network Interface
resource "azurerm_network_interface" "nic" {
  name                = "${var.prefix}-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
  }
}

# Associate NSG
resource "azurerm_network_interface_security_group_association" "nsg_association" {
  network_interface_id      = azurerm_network_interface.nic.id
  network_security_group_id = azurerm_network_security_group.nsg.id
}

# Storage Account for Boot Diagnostics
resource "azurerm_storage_account" "diag" {
  name                     = "diag${random_id.rand.hex}"
  location                 = azurerm_resource_group.rg.location
  resource_group_name      = azurerm_resource_group.rg.name
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

# Windows Virtual Machine
resource "azurerm_windows_virtual_machine" "vm" {
  name                  = "${var.prefix}-vm"
  location              = azurerm_resource_group.rg.location
  resource_group_name   = azurerm_resource_group.rg.name
  network_interface_ids = [azurerm_network_interface.nic.id]
  size                  = "Standard_B1s"  # cheaper for lab

  admin_username = "isaiahadmin"
  admin_password = random_password.password.result

  os_disk {
    name                 = "${var.prefix}-osdisk"
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "MicrosoftWindowsServer"
    offer     = "WindowsServer"
    sku       = "2022-datacenter-azure-edition"
    version   = "latest"
  }

  boot_diagnostics {
    storage_account_uri = azurerm_storage_account.diag.primary_blob_endpoint
  }
}

# Install IIS
resource "azurerm_virtual_machine_extension" "iis_install" {
  name                 = "iis-install"
  virtual_machine_id   = azurerm_windows_virtual_machine.vm.id
  publisher            = "Microsoft.Compute"
  type                 = "CustomScriptExtension"
  type_handler_version = "1.8"

  settings = <<SETTINGS
  {
    "commandToExecute": "powershell Install-WindowsFeature -Name Web-Server -IncludeManagementTools"
  }
  SETTINGS
}

# Random ID
resource "random_id" "rand" {
  byte_length = 4
}

# Random Password
resource "random_password" "password" {
  length  = 16
  special = true
}

NOTE: main.tf is the main infrastructure definition file.
It contains the actual resources Terraform will create.
Think of it as the core blueprint of your infrastructure.

Step 5: Create Variable.tf file

The main reason for creating variables.tf is for Azure VM. Before deploying a VM in main.tf in Terraform is important because it makes your infrastructure flexible, reusable, organized, and easier to maintain. Below is a clear explanation.

If you create a VM directly in main.tf without variables, you will hard-code values like region, VM name, or size.

variable "prefix" {
  description = "Prefix for all resources"
  default     = "isaiah"
}

variable "resource_group_location" {
  description = "Azure region"
  default     = "west US 3"
}

Step 6: Initialize and Deploy

1. Initialize Terraform:

terraform init

Purpose
Initializes the Terraform working directory.

Why is it important
This command prepares your project so Terraform can run properly.

_What it does

Downloads providers (e.g., Azure, AWS, Google Cloud)
Downloads modules
Creates the .terraform folder
Sets up the backend if configured

Running terraform init downloads the AWS and Azure provider plugin. It prepares the environment before Terraform can run.

2. Validate Terraform:

terraform validate

Purpose
Checks if the Terraform configuration syntax is correct.

Why it is important
It helps detect errors in your code before deployment.

What it checks

Syntax errors
Missing brackets
Incorrect variable references
Invalid configuration

It checks if your code is written correctly.

3. terraform plan

Purpose
Shows what Terraform will create, change, or delete before deployment.

Why it is important
It allows you to preview the changes before applying them.

What it shows

Resources to be created
Resources to be modified
Resources to be destroyed

Plan: 3 to add, 0 to change, 0 to destroy.

This means Terraform will create 12 new resources.

Simple explanation

👉 It shows the execution plan before making changes.

4. terraform apply

Purpose
Executes the plan and creates the infrastructure.

What it does

Deploys resources to the cloud
Creates VMs
Creates networks
Creates storage
Updates infrastructure

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

Simple explanation
👉 It actually builds the infrastructure.

Tree

The main purpose of tree is to visualize how files and folders are organized inside a directory.

Instead of listing files in a simple list like ls, tree shows the relationship between folders and subfolders.

Step 7 — Add Files to Git

git init
git add .
git commit -m "Initial commit: multi-cloud Terraform project"
git remote add origin https://github.com/izibili123/multi-cloud-terraform.git
git branch -M main
git push -u origin main

Step 8 Terraform destroy

In Terraform, the command terraform destroy is used to delete all the infrastructure resources that Terraform created.

This is done to Prevent Unnecessary Cloud Costs

Cloud resources keep running and continue charging money if not deleted.

Using terraform destroy helps you:

stop billing
avoid unexpected cloud charges
clean up test environments

This is very important when working with cloud providers

terraform destroy

Plan: 0 to add, 0 to change, 22 to destroy

Then you must confirm:

Do you really want to destroy all resources?
  Terraform will destroy all managed infrastructure.

Enter a value: yes

Plan: 0 to add, 0 to change, 22 to destroy

Key Lessons Learned

Multi-cloud requires clear provider separation.
State file protection is critical.
Always destroy lab infrastructure.
Azure and AWS networking models differ significantly.
Infrastructure as Code improves reproducibility and scalability.

Why Multi-Cloud Matters

Organizations use multi-cloud to:

Reduce vendor dependency
Improve disaster recovery
Optimize regional availability
Compare cost efficiency between providers Terraform makes multi-cloud deployment seamless.

Conclusion

This project demonstrates how Terraform can orchestrate infrastructure across AWS and Azure from a single configuration.

By implementing EC2, RDS, and Azure VM resources, I built a resilient, scalable, and reproducible multi-cloud environment.

Author
Isaiah Izibili
Cloud & DevOps Enthusiast

CloudForge CI/CD Lab

Isaiah Izibili — Mon, 12 Jan 2026 01:59:20 +0000

Building a Production-Grade CI/CD Pipeline with GitHub Actions, Docker & Kubernetes

Introduction

Modern DevOps is not about tools alone — it’s about repeatable, automated, and reliable workflows that take code from a developer’s laptop all the way to production.

In this article, I’ll walk you through CloudForge CI/CD Lab, a fully hands-on DevOps project that demonstrates:

How to build a real Node.js application
How to test it properly
How to containerize it securely with Docker
How to automate everything using GitHub Actions
How to deploy cleanly to Kubernetes using branch-based workflows

This is not a toy project. Every step mirrors what real teams do in production.

Prerequisites – Download These First!

Estimated time: 15–30 minutes

Before writing a single line of code, we need the right tools. DevOps workflows fail early if the environment isn’t consistent.

✅ Required Tools
1️⃣ Node.js (v18 or higher — LTS recommended)

Download: https://nodejs.org/
Choose LTS (v20.x as of 2025)

Verify installation:

node --version
npm --version

2️⃣ Git (Latest Stable)

Download: https://git-scm.com/downloads
Verify:

git --version

3️⃣ Docker Desktop

Download: https://www.docker.com/products/docker-desktop/
Install and start Docker Desktop

Verify:

docker --version
docker-compose --version

4️⃣ GitHub Account

Sign up at: https://github.com
This will host:

Your source code
Your CI/CD pipeline
Your container images (GHCR)

5️⃣ Code Editor (Recommended)

VS Code: https://code.visualstudio.com/

🔍 Verify Everything Is Installed

node --version     # v18.x+ or v20.x+
npm --version      # 9.x+
git --version      # 2.34+
docker --version   # 24.x+

If any command fails, fix it before proceeding.

Step 1: Set Up Git for Version Control
Why this matters

Git needs to know who you are so commits are traceable. This is critical in team environments and CI pipelines.

One-Time Git Configuration

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Create and Initialize the Project

mkdir cloudforge-ci-cd-lab
cd cloudforge-ci-cd-lab
git init

You now have a clean Git repository ready for automation.

Step 2: Build a Node.js Web Application

Estimated time: 10–15 minutes

This application is intentionally simple, but production-aware.

Initialize the Node.js Project

npm init -y

This creates a package.json file that manages dependencies and scripts.

Update package.json

{
  "name": "cloudforge-ci-cd-lab",
  "version": "1.0.0",
  "description": "Production-grade DevOps CI/CD lab",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "test": "jest",
    "dev": "node app.js",
    "lint": "eslint ."
  },
  "keywords": ["devops", "nodejs", "docker", "kubernetes"],
  "author": "Your Name",
  "license": "MIT",
  "engines": {
    "node": ">=18.0.0"
  },
  "devDependencies": {
    "jest": "^29.7.0",
    "eslint": "^8.57.0",
    "supertest": "^7.1.4"
  }
}

Create app.js
This server:

Exposes health endpoints
Emits Prometheus-style metrics
Handles graceful shutdown
Is Kubernetes-ready
Creates an HTTP server that listens on port 3000
Serves different endpoints (/, /health, /info, /metrics)
Includes security headers and proper error handling
Exports the server for testing (Your full app.js code goes here exactly as you provided — unchanged)

Update app.js

// core modules
const http = require("http");
const url = require("url");

// environment configuration
const PORT = process.env.PORT || 3000;
const ENVIRONMENT = process.env.NODE_ENV || "development";

let requestCount = 0;

// helper: send JSON responses
function sendJSON(res, statusCode, data) {
  res.statusCode = statusCode;
  res.setHeader("Content-Type", "application/json");
  res.end(JSON.stringify(data, null, 2));
}

// helper: send HTML responses
function sendHTML(res, statusCode, content) {
  res.statusCode = statusCode;
  res.setHeader("Content-Type", "text/html");
  res.end(content);
}

// helper: send Prometheus metrics
function sendMetrics(res) {
  const mem = process.memoryUsage();
  const metrics = `
# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total ${requestCount}

# HELP app_uptime_seconds Application uptime in seconds
# TYPE app_uptime_seconds gauge
app_uptime_seconds ${process.uptime()}

# HELP nodejs_memory_usage_bytes Node.js memory usage
# TYPE nodejs_memory_usage_bytes gauge
nodejs_memory_usage_bytes{type="rss"} ${mem.rss}
nodejs_memory_usage_bytes{type="heapUsed"} ${mem.heapUsed}
nodejs_memory_usage_bytes{type="heapTotal"} ${mem.heapTotal}
nodejs_memory_usage_bytes{type="external"} ${mem.external}
`;
  res.statusCode = 200;
  res.setHeader("Content-Type", "text/plain");
  res.end(metrics);
}

// main server
const server = http.createServer((req, res) => {
  requestCount++;
  const timestamp = new Date().toISOString();
  const { pathname } = url.parse(req.url, true);

  // logging
  console.log(
    `${timestamp} - ${req.method} ${pathname} - ${
      req.headers["user-agent"] || "Unknown"
    }`
  );

  // CORS headers
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type");

  // security headers
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("X-Frame-Options", "DENY");
  res.setHeader("X-XSS-Protection", "1; mode=block");

  // route handling
  switch (pathname) {
    case "/":
      sendHTML(
        res,
        200,
        `
<!DOCTYPE html>
<html>
<head>
  <title>DevOps Lab 2025</title>
  <style>
    body { font-family: Arial, sans-serif; max-width: 800px; margin: 50px auto; padding: 20px; }
    .header { background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); color: white; padding: 20px; border-radius: 8px; }
    .endpoint { background: #f8f9fa; padding: 15px; margin: 10px 0; border-radius: 5px; border-left: 4px solid #007bff; }
  </style>
</head>
<body>
  <div class="header">
    <h1>DevOps Lab 2025</h1>
    <p>Modern Node.js application with CI/CD pipeline</p>
  </div>
  <h2>Available Endpoints:</h2>
  <div class="endpoint"><strong>GET /</strong> - This welcome page</div>
  <div class="endpoint"><strong>GET /health</strong> - Health check (JSON)</div>
  <div class="endpoint"><strong>GET /info</strong> - System information</div>
  <div class="endpoint"><strong>GET /metrics</strong> - Prometheus metrics</div>
  <p>Environment: <strong>${ENVIRONMENT}</strong></p>
  <p>Server time: <strong>${timestamp}</strong></p>
  <p>Requests served: <strong>${requestCount}</strong></p>
</body>
</html>`
      );
      break;

    case "/health":
      sendJSON(res, 200, {
        status: "healthy",
        timestamp,
        uptime: process.uptime(),
        environment: ENVIRONMENT,
        version: "1.0.0",
        node_version: process.version,
        requests_served: requestCount,
      });
      break;

    case "/info":
      sendJSON(res, 200, {
        platform: process.platform,
        architecture: process.arch,
        node_version: process.version,
        memory_usage: process.memoryUsage(),
        environment: ENVIRONMENT,
        pid: process.pid,
        uptime: process.uptime(),
      });
      break;

    case "/metrics":
      sendMetrics(res);
      break;

    default:
      sendJSON(res, 404, {
        error: "Not Found",
        message: `Route ${pathname} not found`,
        timestamp,
      });
  }
});

// graceful shutdown
function shutdown(signal) {
  console.log(`\nReceived ${signal}, shutting down gracefully...`);
  server.close(() => {
    console.log("Server closed");
    process.exit(0);
  });
}
process.on("SIGTERM", () => shutdown("SIGTERM"));
process.on("SIGINT", () => shutdown("SIGINT"));

// start server
server.listen(PORT, () => {
  console.log(`🚀 Server running at http://localhost:${PORT}/`);
  console.log(`Environment: ${ENVIRONMENT}`);
  console.log(`Node.js version: ${process.version}`);
});

// export for testing
module.exports = server;

Install Dependencies

npm install --save-dev jest eslint supertest
npm install

You’ll now see:

node_modules/
package-lock.json

Step 3: Create Proper Automated Tests

Estimated time: 10 minutes
Testing is mandatory in CI/CD pipelines.

Create Test Directory

mkdir tests
touch tests/app.test.js

Add Tests
(Copy this code into tests/app.test.js exactly as provided)

const request = require('supertest');
const server = require('../app');

describe('App Endpoints', () => {
  afterAll(() => {
    server.close();
  });

  test('GET / should return welcome page', async () => {
    const response = await request(server).get('/');
    expect(response.status).toBe(200);
    expect(response.text).toContain('DevOps Lab 2025');
  });

  test('GET /health should return health status', async () => {
    const response = await request(server).get('/health');
    expect(response.status).toBe(200);
    expect(response.body.status).toBe('healthy');
    expect(response.body.timestamp).toBeDefined();
    expect(typeof response.body.uptime).toBe('number');
  });

  test('GET /info should return system info', async () => {
    const response = await request(server).get('/info');
    expect(response.status).toBe(200);
    expect(response.body.platform).toBeDefined();
    expect(response.body.node_version).toBeDefined();
  });

  test('GET /metrics should return prometheus metrics', async () => {
    const response = await request(server).get('/metrics');
    expect(response.status).toBe(200);
    expect(response.text).toContain('http_requests_total');
    expect(response.text).toContain('app_uptime_seconds');
  });

  test('GET /nonexistent should return 404', async () => {
    const response = await request(server).get('/nonexistent');
    expect(response.status).toBe(404);
    expect(response.body.error).toBe('Not Found');
  });
});

Create Jest configuration
Create jest.config.js:

module.exports = {
  testEnvironment: 'node',
  collectCoverage: true,
  coverageDirectory: 'coverage',
  testMatch: ['**/tests/**/*.test.js'],
  verbose: true
};

Step 4: GitHub Actions CI/CD Pipeline

Estimated time: 15 minutes

This pipeline:

Tests on multiple Node versions
Builds multi-arch Docker images
Scans for vulnerabilities
Pushes to GitHub Container Registry
Supports staging & production deployments

Create Workflow Directory

mkdir -p .github/workflows

Create CI/CD pipeline file

.github/workflows/ci.yml

(Use your full CI workflow YAML exactly as provided)

name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
    tags: [ 'v*' ]
  pull_request:
    branches: [ main ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: Test & Lint
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [20, 22]

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linting
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Security audit
        run: npm audit --audit-level=critical || echo "Audit completed with warnings"

  build:
    name: Build & Push Image
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push'

    permissions:
      contents: read
      packages: write
      security-events: write

    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}
      image-digest: ${{ steps.build.outputs.digest }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          platforms: linux/amd64,linux/arm64

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha,prefix={{branch}}-
            type=raw,value=${{ github.run_id }}
            type=raw,value=latest,enable={{is_default_branch}}
          labels: |
            org.opencontainers.image.title=DevOps Lab 2025
            org.opencontainers.image.description=Modern Node.js DevOps application

      - name: Build and push Docker image
        id: build
        uses: docker/build-push-action@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          target: production

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: ${{ steps.meta.outputs.tags }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
        continue-on-error: true

      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        if: always() && hashFiles('trivy-results.sarif') != ''
        with:
          sarif_file: 'trivy-results.sarif'

  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/develop'
    environment: staging

    steps:
      - name: Deploy to Staging
        run: |
          echo "🚀 Deploying to staging environment..."
          echo "Image: ${{ needs.build.outputs.image-tag }}"
          echo "Digest: ${{ needs.build.outputs.image-digest }}"
          # Add your staging deployment commands here (kubectl, helm, etc.)

  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main'
    environment: production

    steps:
      - name: Deploy to Production
        run: |
          echo "🎯 Deploying to production environment..."
          echo "Image: ${{ needs.build.outputs.image-tag }}"
          echo "Digest: ${{ needs.build.outputs.image-digest }}"
          # Add your production deployment commands here

This pipeline demonstrates real-world CI/CD maturity, not demo-level automation.

Step 5: Dockerfile (Production-Grade)

Estimated time: 5 minutes

This Dockerfile:

Uses multi-stage builds for smaller image size
Installs curl for health checks
Creates a non-root user for security
Sets up proper file permissions
Configures health checks

(Use your full Dockerfile exactly as provided)

Create Dockerfile:

# Multi-stage build for optimized image
FROM node:20-alpine AS dependencies

# Update packages for security
RUN apk update && apk upgrade --no-cache

WORKDIR /app

# Copy package files first for better caching
COPY package*.json ./

# Install only production dependencies
RUN npm ci --only=production && npm cache clean --force

# Production stage  
FROM node:20-alpine AS production

# Update packages and install necessary tools
RUN apk update && apk upgrade --no-cache && \
    apk add --no-cache curl dumb-init && \
    rm -rf /var/cache/apk/*

# Create non-root user with proper permissions
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodeuser -u 1001 -G nodejs

WORKDIR /app

# Copy dependencies from previous stage with proper ownership
COPY --from=dependencies --chown=nodeuser:nodejs /app/node_modules ./node_modules

# Copy application code with proper ownership
COPY --chown=nodeuser:nodejs package*.json ./
COPY --chown=nodeuser:nodejs app.js ./

# Switch to non-root user
USER nodeuser

# Expose port
EXPOSE 3000

# Health check with proper timing for Node.js startup
HEALTHCHECK --interval=30s --timeout=10s --start-period=15s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

# Use dumb-init for proper signal handling in containers
ENTRYPOINT ["dumb-init", "--"]

# Start application
CMD ["npm", "start"]

(Use your full Dockerfile exactly as provided)

Step 6: Essential Configuration Files

Estimated time: 5 minutes
What this step does: Creates configuration files that tell various tools what to ignore, how to behave, and what settings to use.

These files keep your repo clean and secure.

.dockerignore
.gitignore
.env.example
.eslintrc.js

(Use your provided configurations verbatim)

Create .dockerignore

touch .dockerignore

# Dependencies
node_modules
npm-debug.log*

# Git & GitHub
.git
.github

# Environment files
.env
.env.local
.env.*.local

# Logs
logs
*.log

# Coverage & test output
coverage
.nyc_output

# Editor/IDE configs
.vscode
.idea
*.swp
*.swo

# OS-specific files
.DS_Store
Thumbs.db

# Project files you don’t want in the image
README.md
tests/
jest.config.js
.eslintrc

Why this arrangement works
Grouped logically (dependencies, VCS, env files, logs, coverage, editor configs, OS junk, project files).

Each entry on its own line → Docker will correctly ignore them when building images.

Comments (# ...) → optional, but they make the file easier to read and maintain.

Create .gitignore
Create .gitignore:

# ===============================
# Dependencies
# ===============================
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# ===============================
# Runtime Data
# ===============================
pids
*.pid
*.seed
*.pid.lock

# ===============================
# Coverage & Test Reports
# ===============================
coverage/
.nyc_output/

# ===============================
# Environment Variables
# ===============================
.env
.env.local
.env.*.local

# ===============================
# Logs
# ===============================
logs/
*.log

# ===============================
# IDE / Editor
# ===============================
.vscode/
.idea/
*.swp
*.swo

# ===============================
# OS Files
# ===============================
.DS_Store
Thumbs.db

Create environment template
Create .env.example:

# ===============================
# Server Configuration
# ===============================
PORT=3000
NODE_ENV=production

# ===============================
# Logging Configuration
# ===============================
LOG_LEVEL=info

Create ESLint configuration
Create .eslintrc.js:

module.exports = {
  env: {
    node: true,
    es2021: true,
    jest: true
  },
  extends: ['eslint:recommended'],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module'
  },
  rules: {
    'no-console': 'off',
    'no-unused-vars': ['error', { 'argsIgnorePattern': '^_' }]
  }
};

Step 7: Docker Compose for Development
Time Required: 5 minutes

What this step does: Creates a Docker Compose file that makes it easy to run your application and any supporting services with a single command.

Create docker-compose.yml:

version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - PORT=3000
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s

Step 8: Test Everything Locally
Time Required: 10 minutes

What this step does: Shows you how to actually run and test your application locally before deploying it.

Install and Test Locally

# Install all dependencies from package.json
npm install

# Run your test suite to make sure everything works
npm test

# Start the application server
npm start

What you'll see:

Tests should pass with green checkmarks: ✓ GET / should return welcome page
Server starts and shows: 🚀 Server running at http://localhost:3000/

Test Endpoints

curl http://localhost:3000/
curl http://localhost:3000/health
curl http://localhost:3000/info
curl http://localhost:3000/metrics

Homepage

_Purpose: Tests that your application is serving its main route (/).

Why it matters:_

Confirms the server is running and listening on port 3000.
Ensures your app can respond to basic HTTP requests.
This is often the first check to verify deployment success.

Health check JSON

Purpose: Calls the /health endpoint, which usually returns a simple JSON like:
Why it matters:

Health checks are critical for monitoring and orchestration tools (Docker, Kubernetes, CI/CD pipelines).
They provide a lightweight way to confirm the app is alive without loading the full homepage.
Used by load balancers and cloud platforms to decide if traffic should be routed to this instance.

** System info JSON **
Purpose: Retrieves metadata about the system or application (version, environment, uptime, etc.).

Why it matters:

Helps developers and operators quickly see runtime details.
Useful for debugging and confirming the app is running with the expected configuration.
Can expose build info (commit hash, build date) for CI/CD traceability.

Prometheus metrics

Purpose: Exposes application metrics in a format Prometheus can scrape (e.g., request counts, latency, memory usage).

Why it matters:

Enables observability: monitoring performance, resource usage, and reliability.
Critical for production systems where you need dashboards (Grafana) and alerts.
Lets you track trends over time and detect anomalies (e.g., rising error rates).

Why These Steps Together Are Important

They form a complete validation suite:
/ → confirms the app is serving content.
/health → confirms the app is alive.
/info → confirms the app is running with the right config.
/metrics → confirms the app is observable and ready for monitoring.
This combination is standard in DevOps and CI/CD pipelines to ensure deployments are healthy before traffic is routed.

Docker Testing

These commands form a simple, reliable workflow to build, run, verify, and clean up your application as a container. In CI/CD, they help ensure every change can be packaged consistently, tested predictably, and deployed with confidence.

# Build image
docker build -t my-devops-app:latest .

# Run container
docker run -d \
  --name my-devops-container \
  -p 3000:3000 \
  --restart unless-stopped \
  my-devops-app:latest

# Check container status
docker ps
docker logs my-devops-container

# Test health check
curl http://localhost:3000/health

# Stop container
docker stop my-devops-container
docker rm my-devops-container

Build Image

docker build -t my-devops-app:latest .

What it does:

Reads the Dockerfile in the current directory (.).
Builds a container image containing your app and its dependencies.
Tags the image as my-devops-app:latest for easy reference.

Why it’s important in CI/CD:

Consistency: Every build produces the same image, eliminating “works on my machine” issues.
Portability: The image can be deployed across environments (dev, staging, prod).
Versioning: Tags (latest, commit SHA, release numbers) allow tracking and rollback.

2. Run container

    docker run -d \
  --name my-devops-container \
  -p 3000:3000 \
  --restart unless-stopped \
  my-devops-app:latest

1. What it does:

-d: Runs the container in detached mode so the process continues in the background.
--name my-devops-container: Assigns a stable name for easier management and log retrieval.
-p 3000:3000: Publishes container port 3000 to host port 3000, making the app reachable at localhost:3000.
--restart unless-stopped: Restarts the container automatically after failures or host reboots unless you explicitly stop it.

2. Why it matters in CI/CD:

Integration testing: Spins up a production‑like instance to run tests against real endpoints.
Environment parity: Mirrors how the app will run in production, catching config and runtime issues early.
Resilience during validation: Restart policies reduce flakiness in ephemeral CI environments.

3. Check container status

docker ps
docker logs my-devops-container

What they do:
docker ps: Lists running containers—quick confirmation that your app started successfully.
docker logs my-devops-container: Streams stdout/stderr from the container for diagnostics.
Why it matters in CI/CD:
Fast feedback: Detects startup failures (crashes, port conflicts, missing env vars) before tests run.
Actionable debugging: Logs reveal misconfigurations, dependency errors, or health probe failures.
Automated gates: Pipelines can parse logs or check docker ps to decide whether to proceed or fail early.

4. Test health check

curl http://localhost:3000/health

What it does:
Calls the app’s liveness/readiness endpoint, typically returning 200 OK with a simple JSON payload.
Why it matters in CI/CD:
Readiness assurance: Confirms the service is not only running but ready to serve traffic.
Deployment safety: Prevents promoting builds that start but aren’t healthy (e.g., DB not connected, migrations pending).
Automated validation: Pipelines can assert status codes and response bodies to enforce health standards.

5. Stop and remove container

docker stop my-devops-container
docker rm my-devops-container

What they do:
docker stop: Sends a graceful shutdown signal (SIGTERM) to the containerized process.
docker rm: Deletes the stopped container’s resources and metadata (the image remains int
act).
Why it matters in CI/CD:
Clean slate: Avoids port conflicts, stale state, and resource leaks between pipeline runs.
Resource hygiene: Frees CPU/memory on runners, keeping builds stable and predictable.
Determinism: Ensures each run starts from a known baseline, improving the reliability of test results.

Docker Compose Commands

These three docker-compose commands represent the full lifecycle of multi‑container applications in a DevOps CI/CD pipeline. Let’s break them down carefully:

1. Start all services

docker-compose up -d

What it does:
Reads the docker-compose.yml file in your project.
- Starts all services defined there (e.g., app, database, cache, message broker).
- -d runs them in detached mode, so they run in the background.
Why it’s important in CI/CD:
Multi‑service orchestration: Many apps depend on multiple components (e.g., Node.js + MongoDB + Redis). This command spins them all up together.
Consistency: Ensures every developer, tester, and pipeline runner uses the same service definitions.
Automation: Pipelines can bring up the full stack before running integration tests, mimicking production.

2. View real‑time logs

docker-compose logs -f

What it does:
Streams logs from all running services defined in docker-compose.yml.
-f means follow mode, so you see logs in real time as they’re generated.
Why it’s important in CI/CD:
Observability: Lets you monitor startup progress and catch errors (e.g., DB connection failures, missing env vars).
Debugging: If a pipeline fails, logs show exactly which service broke.
Validation: Confirms services are running correctly before tests proceed.

3. Stop and clean up

docker-compose down

What it does:
Stops all running services defined in docker-compose.yml.
Removes containers, networks, and temporary volumes created by docker-compose up.
Leaves images intact (so you don’t have to rebuild next time).
Why it’s important in CI/CD:
Clean environments: Prevents leftover containers or networks from interfering with future runs.
Resource hygiene: Frees CPU, memory, and disk space on build agents.
Repeatability: Ensures every pipeline run starts fresh, avoiding state leakage between builds.

Step 9: Push to GitHub
Estimated time: 10 minutes

git add .

This stages all the changes in your project directory (the . means “everything here”). It tells Git which files you want to include in the next commit.
Why it’s important: Without staging, Git won’t know which files to save. This step ensures your project files (code, configs, Dockerfiles, workflows) are prepared to be recorded in history.

git commit -m "Initial commit: Complete CloudForge CI/CD Lab"

This creates a snapshot of your staged files with a descriptive message. The commit becomes a permanent record in your repository’s history.
Why it’s important: Commits are the foundation of version control. They let you track changes, roll back if needed, and provide context for what was done. The message “Initial commit” marks the starting point of your project.

git branch -M main

This renames your current branch to main. GitHub uses main as the default branch for new repositories.
Why it’s important: Aligning with GitHub’s default branch ensures consistency. Your CI/CD workflows are often configured to run on main, so this step guarantees your pipeline will trigger correctly.

git remote add origin https://github.com/YOUR_USERNAME/cloudforge-ci-cd-lab.git

This links your local repository to a remote repository hosted on GitHub. The name origin is a shorthand reference to that remote.
Why it’s important: Without a remote, your code only exists locally. Adding GitHub as the remote allows you to push your project online, collaborate with others, and integrate with GitHub Actions for CI/CD.

git push -u origin main

This pushes your local main branch commits to the remote repository on GitHub. The -u flag sets origin/main as the default upstream branch, so future pushes and pulls are simpler.
Why it’s important: This is the moment your code leaves your machine and enters GitHub. Once it’s there, GitHub Actions detects the workflow file (.github/workflows/ci.yml) and automatically starts your CI/CD pipeline.

The CI/CD pipeline now runs automatically

Because you’ve pushed the workflow file to GitHub, every new commit or pull request to main (or other configured branches like develop) will trigger the pipeline. GitHub Actions will build, test, and validate your project without manual intervention.
Why it’s important: This automation ensures that every change is tested and verified before deployment, reducing errors and speeding up delivery. It’s the essence of DevOps — continuous integration and continuous delivery.

Step 10: Kubernetes Deployment Configurations

These steps define how your app should run in two environments—staging and production—using Kubernetes manifests. These files describe the desired state (replicas, images, ports, health checks, resources), and Kubernetes continuously enforces that state. In a CI/CD pipeline, your builds produce container images, and these manifests tell Kubernetes which image to run, how many copies, and how to expose and monitor them—so deployments become repeatable, observable, and safe.

Directory structure and environment separation

Purpose:

You create k8s/staging and k8s/production to keep environment-specific configs isolated. This prevents accidental cross-environment changes and makes promotion clear—staging uses one set of manifests, production another.
Why it matters in CI/CD:

Clear promotion paths: CI builds and tags images (e.g., develop-latest for staging, latest for production), then CD applies the corresponding manifests. Risk control: Staging can have fewer replicas, looser resource limits, or different probes, while production is stricter and scaled.

mkdir -p k8s/staging k8s/production

Staging deployment: intent and key fields

Create k8s/staging/deployment.yml

Copy and paste the following command into the just-created file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devops-app-staging
  namespace: staging
spec:
  replicas: 2
  selector:
    matchLabels:
      app: devops-app
      environment: staging
  template:
    metadata:
      labels:
        app: devops-app
        environment: staging
    spec:
      containers:
      - name: app
        image: ghcr.io/YOUR_GITHUB_USERNAME/my-devops-project:develop-latest
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "staging"
        - name: PORT
          value: "3000"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: devops-app-service-staging
  namespace: staging
spec:
  selector:
    app: devops-app
    environment: staging
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer

Why it matters in CI/CD:

Safe validation: Staging runs the latest develop image with health checks, so your pipeline can deploy, verify readiness, run tests, and catch issues before production. Observability: Probes provide automated signals to fail fast if the app isn’t healthy.

Production deployment: scaling, resources, and stricter controls
Create Production Deployment

Create: touch k8s/production/deployment.yml:

copy the commands into the just-created file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devops-app-production
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: devops-app
      environment: production
  template:
    metadata:
      labels:
        app: devops-app
        environment: production
    spec:
      containers:
      - name: app
        image: ghcr.io/YOUR_GITHUB_USERNAME/my-devops-project:latest
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "production"
        - name: PORT
          value: "3000"
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: devops-app-service-production
  namespace: production
spec:
  selector:
    app: devops-app
    environment: production
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer

Why it matters in CI/CD: Reliability and cost control: Resource requests/limits prevent overconsumption and stabilize workloads. Zero-downtime readiness: Readiness probes ensure new pods receive traffic only when ready, enabling safe rolling updates.

Image tags and CI/CD flow

Develop vs. latest:
Staging uses: develop-latest—built from the develop branch on each push.
Production uses: latest—built from main or tagged releases after passing tests.
Pipeline fit:
CI: Builds and pushes images to GHCR with branch-specific tags.
CD (staging): Applies k8s/staging/deployment.yml after CI succeeds, validates via probes/tests.
CD (production): Applies k8s/production/deployment.yml upon approval or automated promotion, leveraging readiness for safe rollout.

Step 11: Complete Deployment Workflow

This final step ties together everything you’ve built in your CI/CD pipeline by introducing a branch‑based deployment strategy. The idea is simple but powerful: each branch in your Git repository corresponds to a specific environment. The develop branch is used for staging, so whenever you push changes there, GitHub Actions automatically runs tests and deploys the latest build to the staging cluster. This allows you to validate new features in a safe, production‑like environment without affecting real users.

The main branch is reserved for production, meaning only code that has been tested and approved gets merged into it. Once you push to main, GitHub Actions executes the full pipeline again, but this time it deploys to your production environment, ensuring that only stable builds reach end users. Pull requests are handled differently: they trigger tests but do not deploy, which provides a safeguard by catching issues before merging into staging or production.

Deploy to staging:

# Create and switch to develop branch
git checkout -b develop

# Make your changes, then commit and push
git add .
git commit -m "Add new feature"
git push origin develop

Deploy to production:

# Switch to main branch
git checkout main

# Merge changes from develop
git merge develop

# Push to trigger production deployment
git push origin main

Monitor Deployments

After deployment, monitoring is critical. GitHub Actions provides real‑time visibility into pipeline runs, while the GitHub Container Registry stores your built images for traceability. Finally, health checks against your staging and production URLs confirm that the applications are live and responding correctly. This workflow enforces discipline, reduces risk, and ensures that every change follows a predictable path from development to production.

Conclusion: What CloudForge CI/CD Lab Really Teaches

CloudForge CI/CD Lab is not about learning individual tools — it is about understanding systems thinking in modern software delivery.

By building this pipeline from first principles, we moved deliberately through every layer of a real production workflow: version control discipline, application design for operability, automated testing, containerization, continuous integration, and declarative deployment. Each step was introduced not because it is fashionable, but because it solves a concrete problem that teams face in real-world environments.

More importantly, this project demonstrates a shift-left mindset. Problems are detected early through editor annotations, linting, and automated tests — long before they reach CI pipelines or production clusters. This is how high-performing teams reduce failures, shorten feedback loops, and ship confidently.

CloudForge CI/CD Lab also highlights that production readiness is not a single feature, but the accumulation of many small, intentional decisions: running containers as non-root, handling graceful shutdowns, enforcing resource limits, and treating infrastructure as code. None of these choices are optional in serious systems, and together they form the foundation of reliable delivery.

If you can build, explain, and reason about a pipeline like this, you are no longer just “using DevOps tools.” You are thinking like a DevOps engineer — one who understands why automation exists, how systems fail, and how to design workflows that scale with both code and teams.

This lab is not the end of the journey, but it is a solid, production-aligned starting point. From here, the same principles extend naturally into cloud platforms, advanced observability, progressive delivery, and platform engineering — without changing the fun

Complete Guide to Kubernetes Flavors, Their Categories & How to Install Minikube on Linux (with Docker Driver)

Isaiah Izibili — Sat, 06 Dec 2025 11:39:27 +0000

INTRODUCTION

Kubernetes has grown into the most powerful container orchestration system in the world, but it does not exist as a single product. Instead, it exists in multiple flavors, each tailored for different use cases such as enterprise production, hybrid cloud, edge, research, or local development.

This article breaks down the Kubernetes ecosystem into understandable categories and explains each distribution in detail. Toward the end, you will learn how to install Minikube using Docker as the driver, with full explanations of every installation command.

1. Understanding Kubernetes Flavors

Kubernetes distributions differ primarily in:
Deployment model (on-prem, cloud, hybrid, edge)
Support level (commercial vs. community)
Extra features (UI dashboards, multi-cluster management, security tools, lifecycle automation)
Operational complexity
Integration with cloud-native tooling

To make the choice easier, we classify them into four practical categories:

2. Kubernetes Distribution Categories

CATEGORY A — Commercial, Enterprise-Supported Kubernetes Distributions

These are paid Kubernetes platforms built for production workloads, strict compliance, zero-downtime upgrades, global scalability, and enterprise SLAs.

✔ Red Hat OpenShift

Type: Commercial enterprise Kubernetes
Best for: Large enterprises, secure environments, regulated industries
Why it stands out:

Built on Kubernetes with many enterprise features added
Includes CI/CD, service mesh, registries, security scanning
Comes with an opinionated workflow
Strong multi-cluster management (via ACM)
Runs on-prem, cloud, or hybrid

OpenShift is essentially “Kubernetes with batteries included,” removing most manual configuration.

✔ VMware Tanzu Kubernetes Grid (TKG)

Type: Commercial enterprise Kubernetes
Best for: VMware-based data centers & enterprises
Key features:

Deep integration with vSphere
Automated cluster lifecycle management
Multi-cloud capability
Strong enterprise governance and policy automation

TKG is ideal for organizations already invested in VMware infrastructure.

✔ SUSE Rancher Prime (Enterprise Rancher)

Type: Paid, enterprise version of Rancher
Best for: Managing many Kubernetes clusters across different environments
Key benefits:

Central management plane
RBAC, audit, monitoring, Istio service mesh
Integrates with RKE (Rancher Kubernetes Engine)
Production support included

Rancher simplifies multi-cluster operations for enterprises.

✔ Canonical Kubernetes (Kubeadm + Canonical Support)

Type: Commercial support for upstream Kubernetes
Best for: Businesses using Ubuntu-based infrastructure
Highlights:

Lightweight and fast
Comes with long-term support
Ideal for on-prem and air-gapped setups

This is pure upstream Kubernetes with professional support.

CATEGORY B — CNCF-Certified Open-Source Distributions

(Enterprise-Grade but Free)

These are open-source, production-ready platforms but may require paid support optionally. They follow the CNCF Kubernetes Conformance Program, meaning they behave like true Kubernetes.

✔ Kubernetes (Upstream - K8s The Hard Way)

This is the pure version maintained by CNCF.
No UI, no extras, just Kubernetes.
Suitable for:

Learning internals
Highly-custom deployments
Research

✔ K3s (Lightweight Kubernetes by SUSE)

Why it is unique:

Extremely small footprint
Optimized for IoT, Edge & ARM devices
Single binary installation

K3s is becoming the default Kubernetes for edge computing.

✔ RKE (Rancher Kubernetes Engine)

A Kubernetes distribution maintained by Rancher.
Designed for:

Simplicity
Fast bootstrap
On-prem clusters

RKE is often used together with Rancher for management.

✔ K0s (Zero Friction Kubernetes by Mirantis)

A minimal, single-binary Kubernetes with:

No OS dependencies
Very easy deployment
GitOps support built-in

Favored for edge and Kubernetes appliances.

CATEGORY C — Cloud Provider Kubernetes Services

(Managed Kubernetes)

These are Kubernetes platforms offered fully as a service. The cloud provider maintains:

control plane
security patches
upgrades
availability

You only manage worker nodes and workloads.

✔ Amazon Elastic Kubernetes Service (EKS)

AWS's managed Kubernetes with:

High availability control plane
Native integration with IAM, VPC, Load Balancers, ECR
Auto-scaling across AZs

Used heavily in production due to AWS's ecosystem.

✔ Google Kubernetes Engine (GKE)

Google created Kubernetes, so GKE is:

The most mature managed Kubernetes
Very stable, very scalable
Offers autopilot mode (serverless Kubernetes)

Often considered the best managed Kubernetes in the industry.

✔ Azure Kubernetes Service (AKS)

Strongly integrated with Azure Cloud with:

AAD authentication
Azure Monitor
Automated node scaling
Windows container support

Ideal for enterprises using Microsoft environments.

✔ Oracle OKE, IBM IKS, DigitalOcean DOKS

All offer:

Managed control planes
Autoscaling
Node pools
Cloud-native integrations These are great for teams who want Kubernetes without managing infrastructure.

CATEGORY D — Local Developer-Focused Kubernetes Options

These are for learning, testing, and local development.

✔ Minikube

A lightweight single-node Kubernetes cluster
Runs on:

Windows
Linux
macOS

It supports multiple drivers (VirtualBox, Docker, Hyper-V).

✔ Kind (Kubernetes IN Docker)

Allows spinning up Kubernetes clusters inside Docker containers.
Best for:

CI/CD
Testing multiple cluster versions

MicroK8s

Canonical’s single-node Kubernetes
Good for:

Local development
Edge computing
High availability (with clustering enabled)

3. Summary Table: Kubernetes Distribution Categories

4. Installing Minikube (Using Docker as the Driver)

Below is a complete guide. Every command is followed by a detailed explanation.

Minikube allows you to run a local Kubernetes cluster on your machine and is ideal for:

learning Kubernetes
testing applications before deploying
experimenting with operators and CRDs

Step-by-Step Setup (Ubuntu/WSL)

When working with Kubernetes locally, Minikube is one of the most popular tools to spin up a lightweight cluster. If you are using Windows and Visual Studio Code, the most reliable way to prepare your environment is by leveraging the Windows Subsystem for Linux (WSL). This ensures you have a proper Linux shell inside Windows, which makes installing and running Minikube seamless.

Step 1: Install WSL
Begin by opening PowerShell as Administrator and running:

wsl --install

This command installs WSL along with a default Linux distribution (usually Ubuntu). After installation, restart your machine to finalize the setup.

Step 2: Connect VS Code to WSL

Open Visual Studio Code and install the Remote – WSL extension. This allows you to connect directly to your Ubuntu environment from within VS Code. Once connected, you’ll be working inside a Linux terminal without leaving your Windows setup.

Step 3 — Update your package index

sudo apt update

Explanation:
This command refreshes Ubuntu’s knowledge of available packages.
It does not upgrade anything; it only updates the package list.

Step 4 — Install Docker (Recommended Driver for Minikube)

sudo apt install docker.io
sudo systemctl start docker
sudo systemctl enable docker

Explanation:

sudo apt install docker.io installs Docker CE from Ubuntu repos
sudo systemctl start docker starts the Docker service
sudo systemctl enable docker ensures Docker automatically starts on boot

Docker is the recommended Minikube driver because:

it is lightweight
fast
easy to manage
integrates smoothly with Kubernetes workloads

Step 5 — Download Minikube Binary

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

Explanation:

curl -LO downloads the latest Minikube binary
sudo install places it into /usr/local/bin and makes it executable

After this, you should be able to run the command:

minikube version

Step 6 — Install kubectl (The Kubernetes CLI) Properly

Kubernetes changed its repo structure in 2023–2024, so older tutorials are broken.
Here is the correct method:

sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gnupg

These packages allow secure HTTPS repository management.

Add the new Kubernetes signing key:

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.34/deb/Release.key \
  | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Explanation:
Downloads the GPG key and converts it to a format apt can use for validating packages.

Add the Kubernetes repository

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
  https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /" \
  | sudo tee /etc/apt/sources.list.d/kubernetes.list

Explanation:
Creates a new repo file so Ubuntu knows where to fetch kubectl.

Install kubectl

sudo apt update
sudo apt install -y kubectl

Step 7 — Start Minikube with Docker

minikube start --driver=docker

What this does:

Initializes Minikube
Uses Docker as the virtualization layer
Creates a Linux VM-like environment inside Docker
Deploys a full single-node Kubernetes cluster

After successful startup, you can verify:

kubectl get nodes

Note: if you just installed Minikube and Docker, you might need to restart your terminal or run :

eval $(minikube -p minikube docker-env)

Then the following Code in this order:

minikube start --driver=docker
kubectl config use-context minikube
minikube status
kubectl get nodes

Conclusion

Kubernetes has evolved into a rich ecosystem with many flavors, each optimized for different environments—from enterprise production (OpenShift, Tanzu, Rancher Prime) to cloud-managed solutions (AKS/EKS/GKE) and lightweight edge platforms (K3s, K0s).

However, for local learning and experimentation, Minikube remains the best starting point.
The installation guide provided above ensures that you set it up using the most reliable driver—Docker—while following best practices for installing kubectl.

Mastering Ubuntu: The Essential Commands You Need to Know

Isaiah Izibili — Sun, 28 Sep 2025 02:25:46 +0000

*Introduction *

Whether you're just dipping your toes into Linux or managing a full-blown Ubuntu server, knowing your way around the terminal is non-negotiable. In this guide, we’ll walk through the most essential Ubuntu commands—step by step—explaining not just how to use them, but why they matter. From installing packages to navigating directories and monitoring system health, this article is your launchpad into the world of Linux command-line mastery.

🐧 Essential Ubuntu Commands Explained Step-by-Step

Ubuntu is one of the most popular Linux distributions, widely used for development, server management, and learning Linux fundamentals. Below is a breakdown of key commands every Ubuntu user should know, what they do, and why they’re important.

🔐 sudo su

What it does: Switches to the superuser (root) account.
Why it matters: Some tasks require elevated privileges. sudo su gives you full access to the system.
How to use:

sudo su

You'll be prompted for your password. Once entered, your shell changes to root (# prompt).

📦 Package Management
apt update

What it does: Refreshes the list of available packages and versions.
Why it matters: Ensures you're installing the latest versions.
How to use:

sudo apt update

apt install vim

What it does: Installs the Vim text editor.
Why it matters: Vim is a powerful tool for editing configuration files and code.
How to use:

sudo apt install vim

apt install nginx

What it does: Installs the Nginx web server.
Why it matters: Nginx is widely used for hosting websites and reverse proxying.
How to use:

sudo apt install nginx

📁 File & Directory Management

mkdir

What it does: Creates a new directory.
Why it matters: Organize files into folders.
How to use:

mkdir my_folder

What it does: Lists files and directories.
Why it matters: Helps you see what’s in your current directory.
How to use:

ls

What it does: Changes the current directory.
Why it matters: Navigate your file system.
How to use:

cd my_folder

ls -l

What it does: Lists files with detailed info (permissions, size, date).
Why it matters: Useful for checking file attributes.
How to use:

ls -l

pwd

What it does: Prints the current working directory.
Why it matters: Know where you are in the file system.
How to use:

pwd

touch

What it does: Creates an empty file.
Why it matters: Useful for quickly generating files.
How to use:

touch myfile.txt

What it does: Deletes files.
Why it matters: Clean up unnecessary files.
How to use:

rm myfile.txt

rmdir

What it does: Removes empty directories.
Why it matters: Helps maintain a tidy file structure.
How to use:

rmdir my_folder

What it does: Copies files or directories.
Why it matters: Duplicate files or back them up.
How to use:

cp file1.txt file2.txt

What it does: Moves or renames files.
Why it matters: Organize or rename files.
How to use:

mv oldname.txt newname.txt

📊 System Monitoring
df -h

What it does: Shows disk space usage in human-readable format.
Why it matters: Monitor storage capacity.
How to use:

df -h

free -h

What it does: Displays memory usage.
Why it matters: Check RAM availability.
How to use:

free -h

uptime

What it does: Shows how long the system has been running.
Why it matters: Useful for server health checks.
How to use:

uptime

🔍 Searching & Environment

grep

What it does: Searches for patterns in text.
Why it matters: Find specific data in files or output.
How to use:

grep "search_term" filename.txt

env

What it does: Displays environment variables.
Why it matters: Useful for debugging and configuration.
How to use:

env

whoami

What it does: Shows the current user.
Why it matters: Confirm your identity, especially after switching users.
How to use:

whoami

🌐 Networking
nslookup

What it does: Queries DNS to resolve domain names.
Why it matters: Diagnose network issues.
How to use:

nslookup example.com

ping

What it does: Sends packets to a host to test connectivity.
Why it matters: Check if a server or website is reachable.
How to use:

ping google.com

System Info & File Viewing

uname

What it does: Displays system information.
Why it matters: Know your OS and kernel version.
How to use:

uname -a

cat

What it does: Displays file content.
Why it matters: Quickly read files.
How to use:

cat myfile.txt

What it does: Shows disk usage (not human-readable by default).
Why it matters: Monitor storage.
How to use:

df

Final Thoughts

Mastering these commands will give you a solid foundation in Ubuntu and Linux in general. Whether you're managing servers, writing scripts, or just exploring, these tools are your gateway to understanding and controlling your system.

Creating DNS Zones and Configuring DNS Settings in Azure

Isaiah Izibili — Mon, 15 Sep 2025 17:16:17 +0000

Introduction

In modern cloud environments, relying on IP addresses for internal communication is both inefficient and prone to errors. Organizations increasingly prefer using domain names for better readability, scalability, and manageability. Azure offers a built-in solution—Azure Private DNS—that enables secure, internal name resolution without deploying custom DNS servers.

This guide walks you through the process of creating and configuring a Private DNS zone, linking it to a virtual network, and setting up DNS records. Each step is explained not just technically, but also strategically—so you understand the why behind the how.

Scenario Overview
Your organization has the following requirements:

Internal workloads must use domain names instead of IP addresses.
No custom DNS solution should be added.
A Private DNS zone is needed for contoso.com.
The zone must be linked to the app-vnet virtual network.
A DNS record is required for the backend subnet.

Skilling Tasks

Create and configure a Private DNS zone
Create and configure DNS records
Configure DNS settings on a virtual network

Step 1: Create a Private DNS Zone

Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution. By using private DNS zones, you can use your own custom domain names rather than the Azure-provided names.

On the Azure portal, search for and select Private DNS zones.

2. Select + Create and configure the DNS zone.

Property                Value
Subscription            Select your subscription
Resource group          RG1
Name                    private.contoso.com
Region                  West US 3

3. Select Review + create and then select Create.
4. Wait for the DNS zone to deploy, and then select Go to resource.

Step 2: Link the DNS Zone to a Virtual Network

To resolve DNS records in a private DNS zone, resources must be linked to the private zone. A virtual network link associates the virtual network to the private zone.

In the portal, continue working on the private.contoso.com DNS zone.
In the DNS Management blade, select + Virtual network links.
Select + Add” and configure the virtual network link.

![Addon Virtuallink(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ir2fa2dznm1cp23xkukl.png)

4. Select Create and wait for the deployment to finish. If necessary, Refresh the page.


Property                  Value
Link name                 app-vnet-link
Virtual network               app-vnet
Enable auto registration      Enabled

Step 3: Create a DNS Record Set

DNS records map domain names to IP addresses. Creating an A record for the backend subnet allows internal services to reach the backend VM using a friendly name like backend.private.contoso.com.

Property                Value
Name                    backend
Type                A
TTL                 1
IP address          10.1.1.5

Note: This record set implies there is a virtual machine in app-vnet with a private IP address of 10.1.1.5.

Key takeaways
Congratulations on completing the exercise. Here are the main takeaways:

Azure DNS is a cloud service that allows you to host and manage domain name system (DNS) domains, also known as DNS zones.
Azure DNS public zones host domain name zone data for records that you intend to be resolved by any host on the internet.
Azure Private DNS zones allow you to configure a private DNS zone namespace for private Azure resources.
A DNS zone is a collection of DNS records. DNS records provide information about the domain.

Configuring Network Routing in Azure: Enforcing Firewall Policies with Custom Routes

Isaiah Izibili — Sun, 14 Sep 2025 23:51:10 +0000

As cloud applications grow in complexity and exposure, enforcing centralized security policies becomes essential. One of the most effective ways to do this in Azure is by routing outbound traffic through a firewall using custom route tables. This article walks you through the process of configuring network routing to ensure that all outbound traffic from your application subnets is filtered through Azure Firewall.

Scenario Overview
Your organization has deployed an application in Azure using a virtual network (app-vnet) with two subnets:

Frontend subnet: Hosts web servers.
Backend subnet: Hosts database servers.

To enforce firewall policies, all outbound traffic from these subnets must be routed through Azure Firewall using its private IP address. This requires:

Creating a custom route table.
Associating the route table with both subnets.
Defining a user-defined route (UDR) that redirects traffic to the firewall.

Step 1: Record the Firewall’s Private IP Address

What You Do:

In the Azure portal, search for Firewall.
Select your firewall instance (app-vnet-firewall).
Go to Overview and note the Private IP address.

Why It Matters:
This IP address will be used as the next hop in your custom route. It ensures that traffic is redirected to the firewall for inspection before leaving the virtual network.

Step 2: Create a Custom Route Table

In the search box, enter Route tables. When Route table appears in the search results, select it.

2. In the Route table page, select + Create and create the route table.

Property            Value
Subscription            Select your subscription
Resource group      RG1
Region                  West US 3
Name                    app-vnet-firewall-rt

3. Select Review + create and then select Create.
4. Wait for the route table to deploy, then select Go to resource.

Why It Matters:
Azure automatically creates system route tables for each subnet, but these default routes don’t enforce firewall policies. A custom route table allows you to override system routes and direct traffic through a Network Virtual Appliance (NVA) like Azure Firewall.

Step 3: Associate the Route Table with Subnets

In the portal, continue working with the route table, select app-vnet-firewall-rt.
In the Settings blade, select Subnets and then + Associate.
Configure an association to the frontend subnet, then select OK.

Property                   Value
Virtual network                app-vnet (RG1)
Subnet                         frontend

4. Configure an association to the backend subnet, then select OK.


Property                  Value
Virtual network               app-vnet (RG1)
Subnet                        backend

Associating the route table with both subnets ensures that all outbound traffic from these subnets follows the custom route you’ll define next. Without this association, the route won’t apply.

Step 4: Create a User-Defined Route (UDR)

In the portal, continue working with the route table, select app-vnet-firewall-rt.
In the Settings blade, select Routes and then + Add.
Configure the route, then select Add.

Property                        Value
Route name                      outbound-firewall
Destination type                    IP addresses
Destination IP addresses/CIDR range 0.0.0.0/0
Next hop type                       Virtual appliance
Next hop address                private IP address of the firewall

Why It Matters:
This route captures all outbound traffic (0.0.0.0/0) and redirects it to the firewall. The Virtual appliance hop type tells Azure to send traffic to a custom IP—your firewall—rather than directly to the internet.

Why This Architecture Matters
By routing traffic through Azure Firewall:

You enforce centralized security policies.
You gain visibility into outbound traffic.
You can apply application-level filtering, threat detection, and logging.
You reduce the risk of data exfiltration or unauthorized access.

This setup is especially critical for organizations using DevOps pipelines, external APIs, or internet-facing applications.

Final Thoughts
Routing in Azure isn’t just about connectivity—it’s about control. By configuring custom route tables and directing traffic through Azure Firewall, you build a secure, scalable, and compliant network architecture. Whether you're protecting sensitive data or managing complex workloads, this approach gives you the power to shape how traffic flows—and how threats are stopped.

Securing Azure Workloads with Azure Firewall: A Step-by-Step Implementation Guide

Isaiah Izibili — Sun, 14 Sep 2025 22:07:59 +0000

Introduction

As cloud applications scale, so do the threats they face. From unauthorized access to data exfiltration, the need for centralized, intelligent network security becomes non-negotiable. Enter Azure Firewall—a robust, cloud-native solution that offers deep packet inspection, application-level filtering, and threat intelligence.

In this guide, we walk through the deployment and configuration of Azure Firewall to protect an application virtual network (app-vnet). Each step is explained with its technical purpose and strategic value, so you can build not just a secure network—but a resilient one.

Scenario Overview

Your organization is preparing for increased application usage and continuous integration via Azure DevOps. To meet these demands securely, you’ve identified the following requirements:

Deploy Azure Firewall in app-vnet for centralized security.
Create a Firewall Policy to manage access rules.
Add an Application Rule to allow access to Azure DevOps.
Add a Network Rule to enable DNS resolution.

Step 1: Create Azure Firewall subnet in our existing virtual network

In the search box at the top of the portal, enter Virtual networks. Select Virtual networks in the search results.
Select app-vnet.
Select Subnets.
Select + Subnet.
Enter the following information and select Save.

**Property                      Value**
Name                                AzureFirewallSubnet
Address range                       10.1.63.0/26

Note: Leave all other settings as default.

Step 2: Create an Azure Firewall

In the search box at the top of the portal, enter Firewall. Select Firewall in the search results.
Select + Create.

3. Create a firewall by using the values in the following table. For any property that is not specified, use the default value.

Note: Azure Firewall can take a few minutes to deploy.

**Property              Value**
Resource group              RG1
Name                        app-vnet-firewall
Firewall SKU                Standard
Firewall management     Use a Firewall Policy to manage this firewall
Firewall policy             select Add new
Policy name             fw-policy
Region                      West US 3
Policy Tier             Standard
Choose a virtual network     Use existing
Virtual network              app-vnet (RG1)
Public IP address        Add new: fwpip
Enable Firewall Management NIC  uncheck the box

4. Select Review + create and then select Create.

Step 3: Configure the Firewall Policy

In the portal, search for and select Firewall Policies.
Select fw-policy.

Step 3a: Add an Application Rule

In the Settings blade, select Application rules and then Add a rule collection.
Configure the application rule collection and then select Add.

Property                   Value
Name                            app-vnet-fw-rule-collection
Rule collection type             Application
Priority                     200
Rule collection action           Allow
Rule collection group            DefaultApplicationRuleCollectionGroup
Name                             AllowAzurePipelines
Source type                  IP address
Source                           10.1.0.0/23
Protocol                     https
Destination type             FQDN
Destination                  dev.azure.com, azure.microsoft.com

Note: The AllowAzurePipelines rule allows the web application to access Azure Pipelines. The rule allows the web application to access the Azure DevOps service and the Azure website.

Why It Matters:
This rule allows your application servers to securely connect to Azure DevOps for continuous updates. Using FQDN filtering, Azure Firewall can inspect outbound traffic and allow only specific domains—critical for reducing exposure to malicious sites.

Step 3b: Add a Network Rule

In the Settings blade, select Network rules and then Add a network collection.
Configure the network rule and then select Add.


Property                Value
Name                        app-vnet-fw-nrc-dns
Rule collection type        Network
Priority                200
Rule collection action      Allow
Rule collection group       DefaultNetworkRuleCollectionGroup
Rule                        AllowDns
Source                      10.1.0.0/23
Protocol                    UDP
Destination ports           53
Destination addresses       1.1.1.1, 1.0.0.1

DNS is the backbone of internet communication. Without it, your servers can’t resolve domain names. This rule ensures that your workloads can reach Cloudflare’s DNS servers securely, enabling name resolution for outbound traffic.

Step 4: Verify Deployment Status

In the portal search for and select Firewall.
View the app-vnet-firewall and ensure the Provisioning state is Succeeded. This may take a few minutes.

In the portal serach for and select Firewall policies.
View the fw-policy and ensure the Provisioning state is Succeeded. This may take a few minutes.

Successful provisioning confirms that your firewall is active and ready to enforce rules. This step ensures that your security posture is operational before workloads begin communicating.

Congratulations on completing the exercise. Here are the main takeaways:

Key takeaways

Azure Firewall is a cloud-based security service that protects your Azure virtual network resources from incoming and outgoing threats.
An Azure firewall policy is a resource that contains one or more collections of NAT, network, and application rules.
Network rules allow or deny traffic based on IP addresses, ports, and protocols.
Application rules allow or deny traffic based on fully qualified domain names (FQDNs), URLs, and HTTP/HTTPS protocols.

Create the network infrastructure for the exercise

Isaiah Izibili — Sun, 14 Sep 2025 01:15:10 +0000

As organizations migrate applications to the cloud, securing network traffic becomes a top priority. In this article, we walk through a practical scenario where an organization uses Network Security Groups (NSGs) and Application Security Groups (ASGs) to tightly control traffic within an Azure virtual network (app-vnet). This hands-on guide explains each step and the rationale behind it, helping you build a secure and manageable cloud environment.

Scenario Overview
Your organization is deploying a web-based application in Azure. The architecture includes:

Frontend subnet: Hosts web servers accessible from the internet.
Backend subnet: Hosts database servers accessed only by the frontend.
Virtual machines: VM1 in the frontend subnet, VM2 in the backend subnet.
Security goals:
Group web servers using an ASG for simplified management
Use an NSG to control traffic to the backend subnet
Allow secure SSH access from frontend to backend

Step 1: Deploy the Virtual Machines

Note: This exercise requires the Lab 01 virtual networks and subnets to be installed. A template is provided if you need to deploy those resources. (kindly refer to my previous post with this link https://dev.to/isaiah_izibili_7a39b7d627/building-a-secure-network-architecture-in-azure-a-step-by-step-guide-3d8a)

Use the icon (top right) to launch a Cloud Shell session. Alternately, navigate directly to https://shell.azure.com.
If prompted to select either Bash or PowerShell, select PowerShell.
Storage is not required for this task Select your subscription. Apply your changes.
Use these commands to deploy the virtual machines required for this exercise.

Note: If the deployment fails for capacity restriction, edit the template and change the “location” value.

$RGName = "RG1"

New-AzResourceGroupDeployment -ResourceGroupName $RGName `
  -TemplateUri "https://raw.githubusercontent.com/MicrosoftLearning/Configure-secure-access-to-workloads-with-Azure-virtual-networking-services/main/Instructions/Labs/azuredeploy.json"

5. In the portal search for and select virtual machines. Verify both vm1 and vm2 are Running.

Why It Matters:
This sets up the infrastructure needed to test and validate your security configurations. Using a template ensures consistency and saves time.

Step 2: Create an Application Security Group (ASG)

Application security groups ASGs let you group VMs by function (e.g., web servers) and apply security rules to the group instead of individual IP addresses. This simplifies management and scales well.

In the portal, search for and select Application security groups.

2. Select + Create and configure the application security group.

**Property          Value**
Subscription            Select your subscription
Resource group          RG1
Name                    app-frontend-asg
Region                  WEST US 3

3. Select Review + create and then select Create.

Note: You are creating the application security group in the same region as the existing virtual network.

Step 3: Associate ASG with VM1

In the Azure portal, search for and select VM1.
In the Networking blade, select Application security groups and then select Add application security groups.
Select the app-frontend-asg and then select Add.

Step 4: Create and Associate the Network Security Group

NSGs are the backbone of Azure network security. They filter traffic using rules and can be applied to subnets or individual NICs.

In the portal search for and select Network security group.
Select + Create and configure the network security group.

Property              Value
Subscription              Select your subscription
Resource group            RG1
Name                      app-vnet-nsg
Region                    West US 3

3. Select Review + create and then select Create.

Step 5: Associate the NSG with the app-vnet backend subnet.

NSGs can be associated with subnets and/or individual network interfaces attached to Azure virtual machines.

Select Go to resource or navigate to the app-vnet-nsg resource.
In the Settings blade select Subnets.
Select + Associate
Select app-vnet (RG1) and then the Backend subnet. Select OK.

Step 6: Create Network Security Group rules

An NSG use security rules to filter inbound and outbound network traffic.

In the search box at the top of the portal, enter Network security groups. Select Network security groups in the search results.
Select app-vnet-nsg from the list of network security groups.
In the Settings blade, select Inbound security rules.
Select + Add and configure an inbound security rule.

Property                               Value
Source                                 Any
Source port ranges                     *
Destination                            Application Security group
Destination application security group     app-frontend-asg
Service                                    SSH
Action                                     Allow
Priority                                   100
Name                                       AllowSSH

Why It Matters:
This enables secure communication between web servers and database servers, while blocking all other traffic by default.

Key takeaways
Congratulations on completing the exercise. Here are the main takeaways:

Application security groups let you organize virtual machines and define network security policies based on your organization’s applications.
An Azure network security group is used to filter network traffic between Azure resources in an Azure virtual network.
You can associate zero, or one, network security group to each virtual network subnet and network interface in a virtual machine.
A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, Azure resources.
You join virtual machines to an application security group. Then you use the application security group as a source or destination in the network security group rules.

Building a Secure Network Architecture in Azure: A Step-by-Step Guide

Isaiah Izibili — Sat, 13 Sep 2025 20:51:02 +0000

As organizations increasingly migrate applications to the cloud, designing a secure and scalable network architecture becomes critical. In this article, we walk through the process of setting up a hub-and-spoke architecture in Microsoft Azure, tailored for a web-based application deployment.

Scenario overview
Your organization is migrating a web-based application to Azure. The first step is to establish the foundational networking components:

Two virtual networks: app-vnet and hub-vnet, simulating a hub-and-spoke topology.
app-vnet will host the application, split into: frontend-subnet for web servers backend-subnet for database servers
hub-vnet will contain a single firewall-subnet for centralized security.
Both networks must be securely peered to allow private communication.
All resources will reside in the same Azure region.

Architecture diagram

Step 1: Create hub and spoke virtual networks and subnets

An Azure virtual network enables many types of Azure resources to securely communicate with each other, the internet, and on-premises networks. All Azure resources in a virtual network are deployed into subnets within the virtual network.

Sign in to the Azure portal - https://portal.azure.com.
Search for and select Virtual Networks.

3. Select + Create and complete the configuration of the app-vnet. This virtual network requires two subnets, frontend and backend.

Property            Value
Resource group           RG1
Virtual network name     app-vnet
Region                   West US 3
IPv4 address space   10.1.0.0/16
Subnet name          frontend
Subnet address range     10.1.0.0/24
Subnet name          backend
Subnet address range     10.1.1.0/24

Note:Leave all other settings as their defaults. When finished select “Review + create and then Create.

Inside each virtual network, you carve out subnets:
_In app-vnet:

frontend-subnet: for web servers that handle user traffic.
backend-subnet: for database servers that store and process data.
In hub-vnet: firewall-subnet: for deploying Azure Firewall or other security appliances.

Why its important:
Subnets help organize resources and apply security rules. For example, you can restrict access so only the frontend talks to the backend, and all traffic flows through the firewall.

4. Create the Hub-vnet virtual network configuration. This virtual network has the firewall subnet.

Property           Value
Resource group         RG1
Name                   hub-vnet
Region                 West US 3
IPv4 address space     10.0.0.0/16
Subnet name        AzureFirewallSubnet
Subnet address range   10.0.0.0/26

5. Once the deployments are complete, search for and select your ‘virtual networks`.
6. Verify your virtual networks and subnets were deployed.

Note: we created two separate virtual networks:

app-vnet: where your application lives.
hub-vnet: where shared services like firewalls or VPN gateways reside.

Why It Matters:
This separation allows you to centralize security and routing in the hub, while keeping application workloads isolated in the spoke. It’s scalable, secure, and mirrors enterprise-grade architecture.

Step 2: Configure Virtual Network Peering

Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure. SO the the virtual network peering between app-vnet and hub-vnet allows them to communicate privately over Azure’s backbone network.

Search for and select the app-vnet virtual network.
In the Settings blade, select Peerings.
+ Add a peering between the two virtual networks.

Property Value
Remote peering link name app-vnet-to-hub
Virtual network hub-vnet
Local virtual network peering link name hub-to-app-vnet

Note: Leave all other settings as their defaults. Select “Add” to create the virtual network peering.

4. Once the deployment completes, verify the Peering status is Connected.

Why It Matters:
Peering avoids the need for public IPs or VPNs. It’s fast, secure, and cost-effective. You can control traffic flow and even route it through the firewall in the hub.

Key takeaways
Congratulations on completing the exercise. Here are the main takeaways:

Azure virtual networks (VNets) provide a secure and isolated network environment for your cloud resources. You can create multiple virtual networks per region per subscription.
When designing virtual networks make sure the VNet address space (CIDR block) doesn’t overlap with your organization’s other network ranges.
A subnet is a range of IP addresses in the VNet. You can segment VNets into different size subnets, creating as many subnets as you require for organization and security within the subscription limit. Each subnet must have a unique address range.
Certain Azure services, such as Azure Firewall, require their own subnet.
Virtual network peering enables you to seamlessly connect two Azure virtual networks. The virtual networks appear as one for connectivity purposes.

Git & GitHub — Step-by-Step: Push Your Resume from Local to GitHub

Isaiah Izibili — Tue, 09 Sep 2025 14:23:44 +0000

This walkthrough is designed to gently introduce you to the basics of Git and GitHub, using clear, step-by-step instructions. You’ll learn how to push a resume from your computer to a brand-new GitHub repository, using Git Bash across Windows, macOS, or Linux. We’ll stick with HTTPS for simplicity, but if you're curious, there's an optional section on SSH too.

Why bother?

Putting your resume on GitHub:

Shows tech-savvy professionalism.
Creates a versioned, shareable copy (PDF or Markdown).
Makes it easy to update and link in job applications or your portfolio.

Prerequisites

A GitHub account (github.com)
Git installed (Git Bash on Windows): https://git-scm.com/downloads
A resume file ready (PDF, DOCX, or a Markdown README.md)
Basic comfort with the terminal

1. Install & configure Git (one-time)
Open Git Bash and run:

# set your identity (replace with your real name & email)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# (optional) set helpful defaults
git config --global core.autocrlf input    # mac/linux; for Windows use true
git config --global init.defaultBranch main

Why? Commits include author info. init.defaultBranch main makes new repos use main (GitHub default).

2) Create a local folder for your resume project

# make a folder and file and move into it
mkdir resume
cd resume

Place your resume file in that file with Vim command as show in the screenshot. Example filenames: Isaiah_Izibili_Resume.pdf

touch index.html

This command will help us to edit our CV in the Vi index.html file.( we need to use the following steps to edit:
1. click Esc on the keyboard to escape the insert mode disappears
2. click on Shift and column. it moves the consul under the page
3. then type :wq and enter(note w is to save while q is to escape back to the coding areas.

3) Initialize a local Git repository

git init

Check the repo status:

git status

To see if the file is added
4) Add files and make your first commit

# add files to staging area
git add index.html(this should be the url from the created repository)

5) Create a GitHub repository (via the website)

Go to github.com and log in.
Click New repository (or + → New repository).
Name it (e.g., resume or isaiah-resume).
Do not initialize with a README (if you have already done one locally).
Click Create repository. You’ll be shown the repo’s remote URL. Use the HTTPS one (e.g., https://github.com/your-username/resume.git) unless you set up SSH.

6) Link the local repo to GitHub (add remote)

git remote add origin https://github.com/your-username/resume.git
Replace the URL below with the one GitHub gave you:

7) Make sure your main branch is named main (or use master if you prefer)

# force local branch name to main (safe even if already main)
git branch -M main

8) Push to GitHub

# push and set upstream, first push
git push -u origin main

9) Verify on GitHub

Open your repo URL in a browser — you should see README.md and your resume file. Click the resume to preview or download.

Deploy and configure Azure Monitor

Isaiah Izibili — Wed, 03 Sep 2025 17:23:38 +0000

Introduction

In today’s dynamic cloud environments, ensuring system health, performance, and security is critical for delivering seamless digital experiences. Azure Monitor provides a powerful, centralized platform for collecting, analyzing, and acting on telemetry data from applications, infrastructure, and network resources. By deploying and configuring Azure Monitor alongside Log Analytics, organizations can gain deep visibility into their cloud ecosystem, identify trends, and quickly address issues before they impact users.

This article provides a step-by-step guide to deploying and configuring Azure Monitor, setting up Log Analytics, monitoring web applications, tracking compute and networking services, and creating custom alerts. Whether you’re an IT administrator, DevOps engineer, or cloud enthusiast, these practices will help you implement a proactive monitoring strategy that supports business continuity and operational efficiency.

In this project, you’ll explore how to configure monitoring for workloads and infrastructure services using Azure Monitor. This article blends learning with hands-on practice, equipping you with practical skills to strengthen your cloud monitoring strategy.

By the end, you’ll be confident in:

Deploying and configuring Log Analytics to centralize and analyze logs.
Configuring monitoring for web applications to ensure performance and availability.
Monitoring compute and networking services for health, traffic, and resource optimization.
Configuring alerts to respond quickly to potential issues.

1. Prepare your Azure environment

Prepare your bring-your-own-subscription (BYOS)
This set of lab exercises assumes that you have global administrator permissions to an Azure subscription.

In the Azure Portal Search Bar, enter Resource Groups and select Resource groups from the list of results.
On the Resource Groups page, select Create.
On the Create a Resource Group page, select your subscription and enter the name rg-alpha. Set the region to East US, choose Review + Create, and then choose Create.

[!NOTE] This set of exercises assumes that you choose to deploy in the East US Region, but you can change this to another region if you choose. Just remember that each time you see East US mentioned in these instructions you will need to substitute the region you have chosen.

Create App Log Examiners security group
In this exercise, you create an Entra ID security group.

In the Azure Portal Search Bar, enter Azure Active Directory (or Entra ID) from the list of results.
On the Default Directory page, select Groups.

3. On the Groups page, choose New Group.
4. On the New Group page, provide the values in the following table and choose Create.

Property : Value
Group type : Security
Group name : App Log Examiners
Group description : App Log Examiners

Deploy and configure WS-VM1
In this exercise, you deploy and configure a Windows Server virtual machine.

In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.
On the Virtual Machines page, choose Create and select Azure Virtual Machine.

3. On the Basics page of the Create A Virtual Machine wizard, select the following settings and then choose Review + Create.

4. Review the settings and select Create.
5. Wait for the deployment to complete. Once deployment completes choose Go to resource.
6. On the WS-VM1 properties page, choose Networking.
7. On the Networking page, select the RDP rule.
8. On the RDP rule space, change the Source to My IP address and choose Save.
This restricts incoming RDP connections to the IP address you’re currently using.

9. On the Networking page, choose Add inbound port rule.
10. On the Add inbound security rule page, configure the following settings and choose Add.

11. On the WS-VM1 page, choose Connect.
12. Under Native RDP, choose Select.

13. On the Native RDP page, choose Download RDP file and then open the file.
Opening the RDP file opens the Remote Desktop Connection dialog box.
14. On the Windows Security dialog box, choose More Choices and then choose Use a different account.
15. Enter the username as .\prime and the password as the secure password you chose in Step 3, and choose OK.

16. When signed into the Windows Server virtual machine, right-click on the Start hint and then choose Windows PowerShell (Admin).

17. At the elevated command prompt, type the following command and press Enter. Install-WindowsFeature Web-Server -IncludeAllSubFeature -IncludeManagementTools
18. When the installation completes run the following command to change to the web server root directory. cd c:\inetpub\wwwroot_
_19. Run the following command. Wget https://raw.githubusercontent.com/Azure-Samples/html-docs-hello-world/master/index.html -OutFile index.html

Deploy and configure LX-VM2
In this exercise you deploy and configure a Linux virtual machine.

In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.
On the Virtual Machines page, choose Create and select Azure Virtual Machine.

3. On the Basics page of the Create A Virtual Machine wizard, select the following settings and then choose Review + Create.

4. Review the information and choose Create.
5. After the VM deploys, open the VM properties page and choose Extensions + Applications under Settings.
6. Choose Add and select the Network Watcher Agent for Linux. Choose Next and then choose Review and Create. Choose Create.

7. Configure the AzureNetworkWatcherExtension and the OmsAgentForLinux extension so that they automatically upgrade.

Deploy a web app with an SQL Database

Ensure that you’re signed into the Azure Portal.
In your browser, open a new browser tab and navigate to https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.web/web-app-sql-database 3. On the GitHub page, choose Deploy to Azure. 4. A new tab opens. If necessary, re-sign into Azure with the account that has Global Administrator privileges. 5. On the Basics page, select Edit template.

In the template editor, delete the contents of lines 158 to 174 inclusive and delete the “,” on line 157. Choose Save.

On the Basics page, provide the following information and choose Next.

8. Review the information presented and select Create.

9. After the deployment completes, choose Go to resource group.

Deploy a Linux web app

Ensure that you’re signed into the Azure Portal.
In your browser, open a new browser tab and navigate to https://learn.microsoft.com/en-us/samples/azure/azure-quickstart-templates/webapp-basic-linux/
On the GitHub page, choose Deploy to Azure.

On the Basics page, provide the following information and choose Next.

5. Review the information and choose Create.

2.Deploy Log Analytics

Task 1: Create a Log Analytics workspace

In the Azure Portal Search Bar, enter Log Analytics and select Log Analytics workspaces from the list of results.

On the Log Analytics workspaces page, choose Create.
On the Basics page of the Create Log Analytics workspace wizard, provide the following information and choose Review + Create.

4. Review the information and choose Create.

Task2: Configure Log Analytics data retention and archive policies

In the Azure Portal Search Bar, enter Log Analytics and select Log Analytics workspaces from the list of results.
On the Log Analytics workspaces page, choose LogAnalytics1.
On the Log Analytics workspace page for LogAnalytics1, choose Usage and estimated costs.
Select Data Retention and set the slider to 60 days. Choose OK.

On the Log Analytics workspace page for LogAnalytics1, choose Usage and estimated costs.
Select Daily cap. Choose On. Set the daily cap to 10 GB and choose OK.

Task3: Enable access to a Log Analytics workspace

In the Azure Portal Search Bar, enter Log Analytics and select Log Analytics workspaces from the list of results.
On the Log Analytics workspaces page, choose LogAnalytics1.
Select Access control (IAM).

Choose Add and then choose Add role assignment.
On the list of roles, select Log Analytics Reader and choose Next.

On the Members page, choose Select Members and choose the App Log Examiners security group. Choose Select.
On the Members space, choose Review + Assign.

3. Monitor web apps

Task1: Enable Application Insights

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose App Services for the Web App with an SQL Database.
Under Settings choose Application Insights.
On the Application Insights page, choose Turn On Application Insights.

On the Application Insights page, ensure that Create a new resource is selected and that the Log Analytics Workspace is set to LogAnalytics1 and choose Apply.

On the Apply monitoring settings dialog, choose Yes.

Tast2: Disable logging for .NET core snapshot debugger

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose App Services for the Web App with an SQL Database.
Under Settings choose Application Insights.

Under Instrument your application, choose .NET Core and then set the Snapshot Debugger setting to Off. Choose Apply.

On the Apply Monitoring Settings dialog box, choose Yes.

Task3: Configure web app HTTP logs to be written to a Log Analytics workspace

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose App Services for the Web App with an SQL Database.
Under Monitoring, choose Diagnostic settings.

On the Diagnostic settings page, select + Add diagnostic settings.
On the Diagnostic settings page, choose the following and select Save.

Task4: Configure SQL Insights data to be written to a Log Analytics workspace

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose the sample SQL database.
Under Monitoring, choose Diagnostic settings.

On the Diagnostic settings page, choose Add diagnostic setting.
On the Diagnostic setting page, provide the following information and choose Save.

Task5: Enable file and configuration change tracking for web apps

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose the AzureLinuxAppWXYZ-webapp.
Choose Diagnose and Solve Problems.
In the search dialog box, type Application Changes.

On the Change Analysis page, choose Configure.
On the Enable file and configuration change tracking page, change the Status slider to On and then choose Save.

4. Configure monitoring for compute services

Task1: Create a data collection endpoint

In the Azure Portal Search Bar, enter Monitor and select Monitor from the list of results.
In the Monitor page, under Settings, choose Data Collection Endpoints.
On the Data Collection Endpoints page, choose Create.

On the Create Data Collection Endpoint page, provide the following settings and then choose Review + Create.
Review the settings and choose Create.

![form8](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d37gnt4gsx0onei68yq5.png

Task 2: Create a data collection rule

In the Azure Portal Search Bar, enter Monitor and select Monitor from the list of results.
In the Monitor page, under Settings, choose Data Collection Rules.
On the Data Collection Rules page, choose Create.

On the Create Data Collection Rule page, configure the following settings and choose Next.

On the Resources page, choose Add Resources.

On the Select a scope page, enable the WS-VM1 checkbox and choose Apply.

7. On the Create Data Collection Rule page, choose Next.
8. On the Collect and Deliver page, choose Add data source.
9. On the Add data source page, select Windows Event Logs. In the Application category enable the Critical and Error categories. In the Security category, choose the Audit Failure category. In the System category, enable the Critical and Error categories.

10. Choose Next.
11. On the Destination page, configure the following settings:

12. Choose Add data source.
13. Choose Review + Create and then choose Create.

Task3: Add an IIS log collection to an existing data collection rule

In the Azure Portal Search Bar, enter Monitor and select Monitor from the list of results.
In the Monitor page, under Settings, choose Data Collection Rules.
Choose the WinVMDRC rule in rg-alpha.

Under Configuration, choose Data Sources.
On the Data Sources page, choose Add.
On the Add Data Source page, select IIS Logs.
Choose Next.

On the Destination page, configure the following settings:

9. Choose Add data source.

Task4: Configure Network Connection Monitor for a Linux IaaS virtual machine

In the Azure Portal Search Bar, enter Network Watcher and select Network Watcher from the list of results.

Under Monitoring, choose Connection Monitor.
On the Connection Monitor page, choose Create.
On the Basics page of the Create Connection Monitor wizard, provide the following information and choose Next.

5. On the Add test group details page, enter the name LinuxIPTest and choose Add sources.

6. On the Add Sources page, select Azure Endpoints and set the type to Virtual machines. Select Subnet and then enable the Linux-VM checkbox. Choose Add Endpoints.

7. Choose Add Test Configuration.
8. On the Add Test Configuration page, enter the name DefaultHTTP and then choose Add Test Configuration.

9. Choose Add Destinations. Select Azure Endpoints and set the type to Virtual machines. Select Subnet and then enable the WS-VM1 checkbox. Select Add Endpoints.

10. Choose Add Test Group.

11. Choose Review and Create and then choose Create.

5 Configure alerts

Task1: Create an action group to send an email

In the Azure Portal Search Bar, enter Monitor and select Monitor from the list of results.
Select Alerts in the navigation menu.
Choose Action Groups.

4. On the Action Groups page, choose Create.
5. On the Basics page of the Create Action Group wizard, configure the following settings and choose Next.

6. On the Notifications page, set the notification type to Email/SMS message/Push/Voice and the Name to NotificationEmail. Choose the Edit (pencil) icon.
7. On the Email/SMS message/Push/Voice enable the email checkbox and enter the address prime@fabrikam.com. Choose OK.
8. Choose Review and Create. Choose Create.

Task2: Create an alert for virtual machine CPU utilization

In the Azure Portal Search Bar, enter rg-alpha and select rg-alpha from the list of results.
From the list of items in the resource group, choose Linux-VM2.
On the Linux-VM2 properties page, choose Alerts under Monitoring.
On the Alerts page, choose Create and then choose Alert rule.

On the Condition page of the Create an Alert Rule wizard, set the Signal name to Percentage CPU. Use the default settings and choose Next.

On the Actions page, choose Select Action Group.
On the Select Action Groups page, choose NotifyCPU and choose Select.

On the Details page enter the Alert rule name HighCPU. Choose Review and Create and then choose Create.

Conclusion

Effective monitoring is a cornerstone of cloud success. By leveraging Azure Monitor’s integrated tools, IT teams can transform raw telemetry into actionable insights, ensuring that applications remain reliable, scalable, and secure. Configuring Log Analytics provides the foundation for deep analysis, while targeted monitoring of web apps, compute, and networking resources helps maintain optimal performance.

Implementing well-defined alerts ensures rapid response to potential issues, reducing downtime and improving user experience. With this deployment strategy, organizations can shift from reactive troubleshooting to proactive optimization—unlocking the full potential of Microsoft Azure’s cloud ecosystem.

Step-by-Step Guide: From Virtual Machine to Scale Set in Azure Porta

Isaiah Izibili — Wed, 20 Aug 2025 01:15:40 +0000

🚀 Step 1: Create Your First Virtual Machine (VM)

The journey begins with setting up a VM in the Azure Portal — think of it as building the foundation of your cloud house.

1. Sign in to Azure Portal

Head over to portal.azure.com and sign in with your Azure account.

2. Launch a New VM Wizard

In the left-hand menu, click Create a resource.

Under Compute, select Virtual Machine.

3. Configure the Basics

Here’s where you define the identity of your VM:

Subscription – Choose the subscription under which resources will be billed.
Resource group – Group related resources for easy management (create new or reuse).
VM Name
Region – Select a region close to your users for lower latency.

Availability options – Choose redundancy level (e.g., single zone, availability zone).
Image – Pick your operating system (Windows Server, Ubuntu, etc.).
Size – Select based on CPU/RAM needs.

Authentication – Password or SSH key (SSH is more secure for Linux).

4. Networking Setup

By default, Azure creates a new VNet and subnet.

You can customize if you already have a network design.

5. Management, Security, and Advanced Settings

Enable auto-shutdown to save costs.
Turn on boot diagnostics for easier troubleshooting.

6. Review + Create

Double-check everything, then click Create.

Azure will deploy your VM in a few minutes. 🎉

💾 Step 2: Enhance the VM (Add Storage, Security & Monitoring)

Now that your VM is alive, let’s give it more power and visibility.

1. Attach a Data Disk

Go to your VM → Disks → Add data disk.
Specify size, name, and caching preferences.

Hit Save.

💡 Pro Tip: Keep OS disk for system files only. Store applications/data on attached data disks for better performance and scalability.

2. Configure Networking

NSG Rules: Allow only required traffic (e.g., RDP 3389 for Windows, SSH 22 for Linux).

VNet/Subnet: Ensure your VM lives in the right subnet for connectivity.

3. Enable Monitoring

Under Monitoring, turn on Azure Monitor / Log Analytics (via AMA + DCRs).
This enables performance tracking and log collection for health insights.

4. Install Software and Extensions

Connect to your VM (RDP/SSH).

Install apps or use Extensions for automation (e.g., Custom Script Extension).

🖼 Step 3: Capture Your VM as a Reusable Image

Before scaling, you need a template image — this ensures all future VMs start with the same setup.

1. Prepare the VM

Install apps, apply patches, and configure settings.

Remove temporary files, browser history, or unique identifiers.

2. Generalize the VM (Windows)

RDP into VM → open Command Prompt (Admin).

Run:

%windir%\system32\sysprep\sysprep.exe /oobe /generalize /shutdown /quiet

⚠️ Note: /oobe ensures the VM boots into first-time setup mode.

📦 Step 4: Build a Shared Image Gallery

Think of this as your central library of VM images.

1. Create the Gallery

Go to Create a resource → Compute → Shared Image Gallery.

Enter name, region, resource group → Create.

2. Add Image Version

Inside the gallery, click + Image Version.

Select the captured image as source.

Define versioning (e.g., 1.0.0).

Publish.

3. Capture the VM

In Portal: VM → Operations → Capture.

Name your image.
Choose “Yes” to delete VM after capture.

Select Create a managed image.

⚖️ Step 5: Deploy a Virtual Machine Scale Set (VMSS)

VMSS = automatic scaling army of VMs built from your golden image.

1. Create VMSS

Portal → Create a resource → Compute → Virtual Machine Scale Set.

2. Basic Settings

Pick resource group, region, and name.
For Image, select your Shared Image Gallery image.

Choose size and instance count.

3. Networking

Attach to existing VNet/Subnet.

Add load balancer if traffic distribution is needed.

4. Scaling

Configure auto-scaling rules (CPU %, schedule-based).

Review + Create.

✅ Step 6: Test Your Scale Set

Scale Up → Increase instance count and watch Azure deploy new VMs.

Scale Down → Reduce instances and see cost optimization in action.