DEV Community: John Ogbonna

DevOps by Doing: Deploying NGINX on Azure Kubernetes Service (AKS) with Terraform

John Ogbonna — Sun, 05 Oct 2025 18:19:24 +0000

Kubernetes has become the go-to platform for deploying and managing containerized applications at scale. In this guide, we’ll walk through how to provision an AKS cluster and deploy a sample NGINX application — all using Terraform.

By the end, you’ll have a fully running NGINX service exposed on a public IP via an Azure Load Balancer, deployed automatically from Infrastructure as Code.

Why Use Terraform with AKS?

Terraform lets you manage both your infrastructure and your application workloads as code — a concept known as Infrastructure as Code (IaC).

With IaC, you describe everything your environment needs (from clusters to pods) in declarative configuration files instead of setting them up manually. This makes your deployments consistent, repeatable, and version-controlled — just like your application source code.

In practice, Terraform can handle both:

Provisioning the AKS cluster (the infrastructure)

Deploying the Kubernetes resources (the workloads)

That means no need to manually run az aks create or kubectl apply. Terraform can build the cluster, connect to it, and deploy your app — all in one automated workflow.

Prerequisites

Before you start, ensure you have:

An Azure account
Terraform installed (v1.5+)
kubectl installed and configured
Azure CLI installed and authenticated

Step 1: Create the Terraform Configuration

Create a new directory for your project and a file named main.tf.

mkdir terraform-aks-nginx
cd terraform-aks-nginx
touch main.tf

Add the following Terraform code to main.tf to define your AKS cluster and supporting resources:

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

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "aks_rg" {
  name     = "aks-nginx-rg"
  location = "East US"
}

resource "azurerm_kubernetes_cluster" "aks_cluster" {
  name                = "nginx-aks-cluster"
  location            = azurerm_resource_group.aks_rg.location
  resource_group_name = azurerm_resource_group.aks_rg.name
  dns_prefix          = "nginxaksdemo"

  default_node_pool {
    name       = "default"
    node_count = 1
    vm_size    = "Standard_B2s"
  }

  identity {
    type = "SystemAssigned"
  }
}

output "kube_config" {
  value     = azurerm_kubernetes_cluster.aks_cluster.kube_config_raw
  sensitive = true
}

Explanation for each component in main.tf:

Component / Block	Type	Description / Purpose	Tags / Notes
`terraform`	Block	Defines global Terraform settings and required providers.	N/A
`required_providers`	Sub-block	Specifies providers Terraform uses (here, AzureRM).	`azurerm` is from HashiCorp registry, version `~>3.0`.
`provider "azurerm"`	Provider	Connects Terraform to Microsoft Azure resources.	`features {}` enables provider functionality (mandatory).
`azurerm_resource_group` `"aks_rg"`	Resource	Creates an Azure Resource Group to organize related resources.	Tags added: `environment`, `project`, `managed_by`.
`name`	Attribute	Name of the resource group (`aks-nginx-rg`).	Descriptive and project-specific.
`location`	Attribute	Azure region where resources are deployed (`West US`).	Matches cluster location.
`azurerm_kubernetes_cluster` `"aks_cluster"`	Resource	Deploys an Azure Kubernetes Service (AKS) cluster.	Tags match the resource group for consistency.
`name`	Attribute	Name of the AKS cluster (`nginx-aks-cluster`).	Helps identify cluster.
`location`	Attribute	Inherits location from resource group.	Ensures both resources are co-located.
`resource_group_name`	Attribute	Links AKS cluster to the resource group created above.	References `azurerm_resource_group.aks_rg.name`.
`dns_prefix`	Attribute	Prefix for the cluster’s public DNS name.	Used by Azure-managed API server endpoint.
`default_node_pool`	Block	Defines node configuration (VM size, count, etc.).	Node pool name: `default`.
`node_count`	Attribute	Number of worker nodes to start with (here, `1`).	Can be scaled later.
`vm_size`	Attribute	VM type used for each node (`Standard_B2s`).	Small, cost-effective VM for demos.
`identity`	Block	Assigns a managed identity for Azure authentication.	Type `SystemAssigned` allows Azure to manage the identity.
`tags`	Attribute Block	Adds metadata to resources for organization and management.	`environment`, `project`, `managed_by`.
`output "kube_config"`	Output Block	Displays AKS kubeconfig data for `kubectl` access.	Marked `sensitive = true` to hide from logs.
`sensitive`	Attribute	Protects sensitive data from appearing in plain text output.	Ensures secrets are hidden.
`tags.environment`	Tag	Describes the environment (e.g., `demo`, `prod`, `dev`).	Helps separate environments.
`tags.project`	Tag	Indicates which project the resource belongs to (`nginx-aks`).	Aids in billing and tracking.
`tags.managed_by`	Tag	Specifies management source (`terraform`).	Helps identify IaC-managed resources.

Step 2: Initialize and Apply Terraform

Run the following commands to create your AKS cluster:

terraform init
terraform apply -auto-approve

This process will:

Create a resource group
Deploy an AKS cluster
Output the Kubernetes configuration

Step 3: Connect to Your AKS Cluster

After deployment, connect kubectl to your new cluster:

az aks get-credentials --resource-group aks-nginx-rg --name nginx-aks-cluster

Step 4: Deploy NGINX

Create a file named nginx.yaml with the following content:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Then apply it:

kubectl apply -f nginx.yaml

This will:

Deploy two NGINX pods
Expose them through a LoadBalancer Service, which automatically provisions an Azure Load Balancer

Step 5: Verify Deployment

Check the running pods:

kubectl get pods

And get the external IP address:

kubectl get service nginx-service

You should see something like:

Do You Need a Load Balancer?

The LoadBalancer type service is not strictly required but highly recommended if you want public access.
If you only need internal or private traffic, you can use:

ClusterIP – for internal cluster communication only
NodePort – for debugging or development access on node IPs

Step 6: Clean Up

To remove all resources and avoid extra costs:

terraform destroy -auto-approve

Once complete, the Resource Group will be destroyed;

Summary

You’ve successfully deployed a scalable NGINX application on Azure Kubernetes Service (AKS) using Terraform!
This setup demonstrates how infrastructure as code (IaC) simplifies provisioning and how AKS handles orchestration and scaling out of the box.

DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 2

John Ogbonna — Sun, 21 Sep 2025 18:05:13 +0000

What this part covers

In Part 1, we built the foundation: Git setup, Node.js app, dependencies, and automated tests.

In Part 2, we’ll take the next big steps toward a production-ready setup by:

Creating a .gitignore file
Setting up a .env.example for environment variables
Adding ESLint for code quality
Writing a Dockerfile to containerize our app
Creating a .dockerignore to slim images
Using Docker Compose for local development
Running & testing the app in Docker
Setting up GitHub repository + pushing code
Configuring GitHub Actions CI/CD pipeline for build + test
Deploying to GitHub (first automated deployment)
Monitoring build/deployment success

By the end of this article, you’ll have your project running in Docker, connected to GitHub, and building automatically via CI/CD.

Step 1: GitHub Actions CI/CD Pipeline

What this step does

We’re now moving from local development into automation. In this step, we’ll create a GitHub Actions pipeline that:

Runs linting, tests, and security audits on every push and pull request.
Builds and pushes Docker images to GitHub’s container registry (GHCR).
Runs a vulnerability scan against the built image.
Deploys automatically to staging (develop branch) and production (main branch).

This is the backbone of modern DevOps: CI/CD automation that ensures code is tested, packaged, secured, and ready for deployment — with no manual intervention required.

Create workflow directory:

# Create the GitHub Actions directory structure
mkdir -p github/workflows

Create ci.yml:

touch .github/workflows/ci.yml

Create the pipeline definition

Inside .github/workflows/ci.yml, add the following:

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 setup:

Ensures we only build/test on pushes to main or develop, pull requests to main, or tagged releases.
Runs in Node 20 and 22 to validate across multiple versions
For the building and pushing of Docker Images, it only runs on push events and after tests pass it:
- Uses Buildx for multi-arch images (amd64 + arm64).
- Pushes to GitHub Container Registry.
- Adds labels and tags for traceability.
- Runs Trivy for vulnerability scanning.
Separates staging and production deployments by branch:
- develop → staging
- main → production

Why this matters

By the end of this step, you now have:
✅ Automated linting, tests, and audits on every change.
✅ Docker images built and pushed to GHCR automatically.
✅ Security scans integrated directly into CI/CD.
✅ Branch-based deployments ready for staging and production.

This is the minimum baseline for modern DevOps — continuous integration, containerized builds, automated deployments, and built-in security.

Step 2: Dockerfile

What this step does

The Dockerfile defines how to package your application into a container image that can run consistently anywhere — locally, in CI/CD pipelines, or in cloud environments.

In this step, we’ll create a production-ready Dockerfile that:

Uses multi-stage builds to keep images small.
Runs as a non-root user for security.
Sets up health checks for monitoring.
Includes signal handling for clean shutdowns.
This makes your app portable, secure, and reliable.

Create Dockerfile

Enter:

touch Dockerfile

In Dockerfile, Paste:

# 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"]

Dockerfile Explained

Dependencies Stage:

Based on node:20-alpine for a minimal footprint.
Installs only production dependencies.
Cleans up cache to keep size small.

Production Stage

Installs required tools (curl, dumb-init).
Creates a non-root user (nodeuser) with proper permissions.
Copies dependencies and app code with correct ownership.
Defines a health check endpoint (/health).
Uses dumb-init as the entrypoint for proper signal handling.

Why this matters

By containerizing your app with this Dockerfile, you gain:
✅ Consistency: Same environment across dev, CI/CD, and production.
✅ Security: Runs as non-root with patched Alpine base image.
✅ Reliability: Health checks ensure containers are restarted if unhealthy.
✅ Efficiency: Multi-stage builds keep images lean.

Step 3: Essential Configuration Files

What this step does

Configuration files are the unsung heroes of a DevOps project. They define what to ignore, how tools behave, and what settings your project expects.

In this step, we’ll set up:

.dockerignore – to keep Docker images lean.
.gitignore – to avoid committing unnecessary or sensitive files.
.env.example – a template for environment variables.
.eslintrc.js – to enforce coding standards.

Create `.dockerignore`

This file ensures your Docker builds don’t copy unnecessary files into the image, making builds faster and images smaller

node_modules
npm-debug.log*
.git
.github
.env
.env.local
.env.*.local
logs
*.log
coverage
.nyc_output
.vscode
.idea
*.swp
*.swo
.DS_Store
Thumbs.db
README.md
tests/
jest.config.js
.eslintrc*

Create `.gitignore`

# Dependencies
node_modules/
npm-debug.log*

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# Coverage
coverage/
.nyc_output

# Environment variables
.env
.env.local
.env.*.local

# Logs
logs
*.log

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

# OS
.DS_Store
Thumbs.db

Create `.env.example`

# Server Configuration
PORT=3000
NODE_ENV=production

# Logging
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 4: Docker Compose for Development

What this step does

While a Dockerfile defines how to build your app’s container, Docker Compose makes it easy to run multiple services together (like your app + a database).

With one command, you can spin up your entire development environment.

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

Start your app with:

docker-compose up --build

(First stop the app if started with npm)

Stop it with:

docker-compose down

Step 4: Test Everything Locally

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 (in a new terminal window):

curl http://localhost:3000/         # Homepage
curl http://localhost:3000/health   # Health check JSON
curl http://localhost:3000/info     # System info JSON  
curl http://localhost:3000/metrics  # Prometheus metrics

Results of test:

Docker Commands

Use these to test your image and container directly (great for debugging fundamentals).

# 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

Docker Compose Commands

Use these for day-to-day development or when you have multiple services.

# Start all services defined in docker-compose.yml
docker-compose up -d

# View real-time logs from all services
docker-compose logs -f

# Stop all services and clean up
docker-compose down

Step 5: Deploy to GitHub

What this step does: Commits your code to Git and pushes it to GitHub so the automated CI/CD pipeline can start working.

Initial Commit

# Add all files to Git staging area
git add .

# Create your first commit with a descriptive message
git commit -m "Initial commit: Complete DevOps setup with working CI/CD"

Connect to GitHub

⚠️ Before running these commands:

Go to GitHub.com and create a new repository called my-devops-project.
Do not initialize it with a README, .gitignore, or license (we already created those).
Copy the repository URL from GitHub.
Replace YOUR_GITHUB_USERNAME in the commands below with your actual username.

# Set main as the default branch
git branch -M main

# Connect to your GitHub repository (UPDATE THIS URL!)
git remote add origin https://github.com/YOUR_GITHUB_USERNAME/my-devops-project.git

# Push your code to GitHub for the first time
git push -u origin main

What You’ll See

Your code appears in your new GitHub repository.
The CI/CD pipeline kicks in automatically (thanks to the GitHub Actions workflow you added earlier).

Step 6: Fix CI Security Scan Errors

The Problem:
When the pipeline first runs, the security scanner fails with this error:

failed to parse the image name: could not parse reference: ghcr.io/USERNAME/my-devops-project:latest

This happened because the workflow was hardcoding :latest as the image tag. At the time of the scan, that tag didn’t exist yet in the GitHub Container Registry, so Trivy couldn’t find or parse the image reference.

The Fix:
Instead of scanning :latest, we need to scan the exact image tag that was built and pushed by the build job. GitHub Actions makes this available via the job output needs.build.outputs.image-tag.

Edit .github/workflows/ci.yml and replace the security-scan section with:

    security-scan:
  name: Security Scan
  runs-on: ubuntu-latest
  needs: build
  if: github.event_name == 'push' && github.ref == 'refs/heads/main'

  steps:
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ needs.build.outputs.image-tag }}
        format: 'sarif'
        output: 'trivy-results.sarif'

    - name: Upload Trivy scan results
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: 'trivy-results.sarif'

Create the Staging Environment in GitHub

Go to your repo Settings
Go to Environments, click new environment.
Name it: staging
Save.

In VS Save and Commit Your Code Changes

# Stage changes
git add .github/workflows/ci.yml

# Commit with a clear message
git commit -m "Fixed security scan to use build job image tag"

# Push to GitHub
git push origin main

Once pushed, GitHub Actions will re-run the pipeline and Trivy will correctly scan the newly built image.

Step 7: Kubernetes Deployment Configurations

What this step does: Defines how your application should run in Kubernetes for both staging and production environments, including the number of replicas, resource limits, and health checks.

Create directories

# Create directories for Kubernetes configurations
mkdir -p k8s/staging k8s/production

Create Staging Deployment

Create k8s/staging/deployment.yml:

⚠️ IMPORTANT: Update YOUR_GITHUB_USERNAME and YOUR_REPO_NAME in the image URL.

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/YOUR_REPO_NAME: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

Create Production Deployment

Create k8s/production/deployment.yml:

⚠️ IMPORTANT: Update YOUR_GITHUB_USERNAME and YOUR_REPO_NAME in the image URL.

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/YOUR_REPO_NAME: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

Update the k8s/production/deployment.yml as such

✅ Key Notes:

Namespaces: staging and production isolate environments.
Replicas: Staging uses 2 replicas; production uses 3 for high availability.
Probes: livenessProbe and readinessProbe ensure containers are healthy before traffic is routed.
Resources (Production only): CPU/memory requests and limits prevent resource exhaustion.
Services: Both use LoadBalancer to expose the application externally.

Step 8: Complete Deployment Workflow

What this step does: Demonstrates the full CI/CD process with branch-based deployments to staging and production, along with monitoring.

1. Branch-based Deployment Strategy

Branch	Action
`develop`	Automatically deploys to staging environment
`main`	Automatically deploys to production environment
Pull requests	Run tests only (no deployment)

2. Deploy Changes

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

What happens:

GitHub Actions automatically builds the image.
Runs security scans and tests.
Deploys the app to staging (staging namespace in Kubernetes).

3.Deploy to Production

When you’re ready to release:

# Switch to main branch
git checkout main

# Merge changes from develop
git merge develop

# Push to trigger production deployment
git push origin main

What happens:

GitHub Actions runs the full pipeline.
Deploys the app to production (default namespace in Kubernetes).

🔎 Monitor Deployments

Check GitHub Actions status

👉 https://github.com/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME/actions,
replace YOUR_GITHUB_USERNAME and YOUR_REPO_NAME accordingly

Check your container registry

👉https://github.com/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME/pkgs/container/my-devops-project
replace YOUR_GITHUB_USERNAME and YOUR_REPO_NAME accordingly

Test your deployed applications

# Staging health check
curl https://your-staging-url.com/health

# Production health check
curl https://your-production-url.com/health

🎯 Conclusion

In this second part of DevOps by Doing, we took our project beyond the basics and built out a modern CI/CD pipeline with GitHub Actions, Docker, and Kubernetes.

*We covered how to: *

✅ Automate testing and linting across multiple Node.js versions
✅ Build and publish Docker images to GitHub Container Registry (GHCR)
✅ Deploy automatically to a staging environment from the develop branch
✅ Secure production deployments on the main branch with environment protections

With these steps, you now have a complete DevOps workflow: from writing code, to testing, to building, to deploying in a controlled and repeatable way.

This isn’t just theory—it’s the exact type of pipeline used in modern production teams. By now, you should feel confident that every push to your repo can be tested, built, and deployed automatically. That’s the heart of DevOps by Doing.

DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 1

John Ogbonna — Thu, 04 Sep 2025 06:33:49 +0000

Welcome to DevOps by Doing, a hands-on series where we don’t just talk about DevOps principles — we actually build, maintain and upgrade complete modern DevOps environments step by step. This is the first instalment in the series: Setting Up a Complete Modern DevOps Environment. By the end of this exercise series, you’ll have a working Node.js application running through a full DevOps pipeline: from source control to automated testing, containerization, deployment and more.

Instead of abstract theory, we’ll focus on practical implementation. We’ll start small — setting up our project and tools — and then gradually build out the pipeline into a production-ready workflow. Each article will layer on new pieces of the environment so you can follow along at your own pace.

What We’ll Cover in This Series

Over the course of this episode (likely two to three parts), we’ll walk through the following:
Version Control Setup: Initializing Git, configuring .gitignore, and structuring the project repository.
Node.js Application Setup: Bootstrapping a simple sample app, installing dependencies, and writing tests.
Code Quality & Standards: Setting up ESLint and other linters for clean, consistent code.
Environment Management: Creating .env.example files to handle configuration safely.
Continuous Integration (CI): Configuring GitHub Actions to run builds, linting, and tests automatically.
Containerization: Writing a Dockerfile, setting up .dockerignore, and building images.
Local Development with Docker Compose: Creating a docker-compose.yml to run our app and services locally.
Continuous Deployment (CD): Extending our GitHub Actions pipeline to build, push, and deploy containers.

Part 1: Laying the Foundation

In this first article, we’ll focus on the core project setup:

Initializing Git
Setting up a sample Node.js app
Installing dependencies
Writing and running tests
Creating .gitignore and .env.example
Adding ESLint for code quality
Set up files for GitHub Actions CI/CD
Set up Dockerfile
Essential Configuration Files such as .gitignore and .dockerignore

By the end of this article, you’ll have a clean, version-controlled project with quality checks in place — ready to move on to Docker, GitHub Actions, and deployment in the upcoming parts.

Let’s get started. 🚀

Requirements
Before we dive in, let’s make sure your development environment is ready. To follow along with this series, you’ll need the following tools installed on your machine:

Git – for version control and repository management.
Node.js(LTS recommended) – we’ll use it to build our sample application. Installing Node will also give you npm (Node Package Manager).
Docker to containerize our application and manage images.
Docker Compose to run multi-container environments locally.
A GitHub account – since we’ll be pushing code to GitHub and setting up GitHub Actions for CI/CD.
A code editor (VS Code recommended) – with useful extensions such as:
- ESLint
- Docker

Verify Everything is Installed

Once you’ve installed the required tools, run the following commands in your terminal to make sure everything is set up correctly:

node --version    
# Should show v18.x+ or v20.x+

npm --version     
# Should show 9.x+ or 10.x+

git --version     
# Should show 2.34+ 

docker --version  
# Should show 24.x+

Step 1: Set Up Git for Version Control

What this step does: Configures Git on your machine so it knows who you are when you make commits, and sets up proper project tracking.

Git is the backbone of most modern DevOps workflows. It keeps track of changes to your codebase, allows collaboration, and integrates directly with CI/CD pipelines like GitHub Actions.

1.1 Configure Git (if you haven’t already)

Run the following commands to tell Git who you are:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

You can confirm your settings with:

git config --list

💡 Use the same email that’s linked to your GitHub account — it makes authentication and contribution tracking easier.

1.2 Initialize a Git Repository

Create and navigate to the folder where you’ll be creating the project and run:

mkdir my-devops-project
cd my-devops-project
git init

This creates a new folder called my-devops-project, moves you inside it, and initializes it as a Git repository. The git init command sets up all the hidden files Git needs (.git/), allowing you to start tracking changes to your project.

To confirm that Git has created the repository metadata, list all files (including hidden ones):

ls -a

Expected output (your system may show additional files):

.   ..   .git

1.3 Verify Repository Setup

Check that everything is working by running:

git status

You should see a message saying “On branch main” (or master, depending on your Git version) and that there are no commits yet.

At this point, Git is ready — next we’ll set up our Node.js application inside this repository. 🚀

Step 2: Build a Node.js Web App

What this step does: Creates a web application using Node.js that can serve web pages and API endpoints.

2.1 Initialize a Node.js Project

What this step does: Creates a package.json file that describes your project and manages dependencies.

Run the following command inside your project folder:

npm init -y

This generates a package.json file with default values.

2.2 Update `package.json`

What this step does: Customizes the package.json with proper scripts and metadata for your DevOps project.

Open the file in your editor (VS Code, for example), or recreate it with:

touch package.json

Then copy and replace the contents with the following:

{
  "name": "my-devops-project",
  "version": "1.0.0",
  "description": "DevOps learning project with Node.js",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "test": "jest",
    "dev": "node app.js",
    "lint": "eslint ."
  },
  "keywords": ["devops", "nodejs", "docker"],
  "author": "Your Name",
  "license": "MIT",
  "engines": {
    "node": ">=18.0.0"
  },
  "devDependencies": {
    "jest": "^29.7.0",
    "eslint": "^8.57.0",
    "supertest": "^7.1.4"
  }
}

Step 3: Create the Node.js Web Server

What this step does: Creates an HTTP server that listens on port 3000, serves different endpoints (/, /health, /info, /metrics), includes security headers and error handling, provides graceful shutdown capability, and exports the server for testing.

3.1 Create a file calledapp.js. You can do this in VS code or by typing in the terminal:

touch app.js

Copy the following code into a new file called app.js:

const http = require('http');
const url = require('url');
const port = process.env.PORT || 3000;
const environment = process.env.NODE_ENV || 'development';

let requestCount = 0;
const startTime = Date.now();

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

  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 '/':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/html');
      res.end(`
        <!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>I'm Getting Better at DevOps, Yay!</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':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({
        status: 'healthy',
        timestamp: new Date().toISOString(),
        uptime: process.uptime(),
        environment: environment,
        version: '1.0.0',
        node_version: process.version,
        requests_served: requestCount
      }, null, 2));
      break;

    case '/info':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({
        platform: process.platform,
        architecture: process.arch,
        node_version: process.version,
        memory_usage: process.memoryUsage(),
        environment: environment,
        pid: process.pid,
        uptime: process.uptime()
      }, null, 2));
      break;

    case '/metrics':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/plain');
      res.end(`# 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"} ${process.memoryUsage().rss}
nodejs_memory_usage_bytes{type="heapUsed"} ${process.memoryUsage().heapUsed}
nodejs_memory_usage_bytes{type="heapTotal"} ${process.memoryUsage().heapTotal}
nodejs_memory_usage_bytes{type="external"} ${process.memoryUsage().external}
`);
      break;

    default:
      res.statusCode = 404;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({
        error: 'Not Found',
        message: `Route ${pathname} not found`,
        timestamp: new Date().toISOString()
      }, null, 2));
  }
});

// Graceful shutdown
process.on('SIGTERM', () => {
  console.log('Received SIGTERM, shutting down gracefully');
  server.close(() => {
    console.log('Server closed');
    process.exit(0);
  });
});

process.on('SIGINT', () => {
  console.log('Received SIGINT, shutting down gracefully');
  server.close(() => {
    console.log('Server closed');
    process.exit(0);
  });
});

// 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 server for testing
module.exports = server;

What this code does:

Creates an HTTP server that listens on port 3000
Serves different endpoints (/, /health, /info, /metrics)
Includes security headers and proper error handling
Provides graceful shutdown capability
Exports the server for testing

3.2 Install Dependencies

What this step does: Downloads and installs the necessary packages for testing and code quality.

Run the following commands:

# Install testing and development tools
npm install --save-dev jest eslint supertest

# Install all dependencies (creates node_modules folder)
npm install

What you’ll see:

A new node_modules/ folder containing installed packages
A package-lock.json file that locks dependency versions for consistency across environments

Step 4: Create Proper Tests

🎯 What this step does

This step sets up automated testing for your application using Jest and Supertest. Automated tests help verify that your web app’s endpoints behave correctly and prevent regressions when making changes.

4.1 Create Tests Directory and File

First, create a folder to hold your tests and an initial test file:

#Create a folder for your tests
mkdir tests

# Create the main test file
touch tests/app.test.js

Your project folder should look like this:

my-devops-project/
├── app.js
├── package.json
├── tests/
│   └── app.test.js

4.2 Write Your First Tests

Open tests/app.test.js and add the following code:

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');
  });
});

✅ These tests check:

/ → Welcome page
/health → Health check info
/info → System details
/metrics → Prometheus metrics
/nonexistent → Correct 404 handling

4.3 Configure Jest

Next, set up a Jest configuration file so tests run consistently:

touch jest.config.js

Paste the following into jest.config.js:

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

Config breakdown:

testEnvironment: 'node' → Run in Node.js context
collectCoverage: true → Generate coverage reports
coverageDirectory: 'coverage' → Store reports in /coverage
testMatch → Look for files ending in .test.js inside /tests
verbose: true → Show detailed output

4.4 Run the Tests

Now run the tests with:

npm test

If everything is working, you’ll see output like:

Step 5: Start the App 🚀

🎯 What this step does

This step launches your Node.js web server so you can test it locally in your browser and confirm everything works before moving into Docker, CI/CD, and deployment in Part 2.

5.1 Start the Server

Run the following command in your project root:

npm start

You should see output like:

5.2 Verify Endpoints in Browser or curl

Now, open your browser (or use curl) to test the endpoints:

# Welcome page
curl http://localhost:3000/

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

# Info
curl http://localhost:3000/info

# Metrics
curl http://localhost:3000/metrics

Results:
You will see this page on the browser:

✅ You should see the welcome HTML page at / and JSON responses at /health and /info. The /metrics endpoint will return Prometheus-style metrics.

5.3 Stop the Server

When you’re done testing, stop the server by pressing:

CTRL + C

🎉 Wrapping Up Part 1

In this first part of DevOps by Doing - Setting Up a Complete Modern DevOps Environment, we:

Set up Git for version control
Created a Node.js project with a sample web app
Installed dependencies and dev tools
Wrote and ran automated tests with Jest + Supertest
Started the app locally

You now have the foundation of a modern DevOps-ready application.

Coming Up in Part 2

In Part 2, we’ll take this project to the next level by:

Creating a .gitignore file to keep your repo clean
Adding a .env.example for environment variables
Setting up ESLint for code quality
Writing a Dockerfile and .dockerignore
Running your app with Docker Compose
Preparing for CI/CD with GitHub Actions
Stay tuned — things are about to get even more exciting! 🚀

Getting Started With Kubernetes: A Beginner’s Guide Using Minikube and KubeCTL

John Ogbonna — Sun, 15 Jun 2025 19:10:22 +0000

Kubernetes can feel intimidating at first, but with this step-by-step guide, you’ll be up and running in no time. This article will walk you through the essentials of Kubernetes, introduce you to Minikube and KubeCTL, and help you launch your first local cluster.

🤔 What is Kubernetes?

Kubernetes (sometimes called K8's) is an open-source system for managing containerized applications. It helps you automate deployment, scaling, networking, and health monitoring across clusters of machines. This process is also referred to as container orchestration. Kubernetes was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF)

What is Minikube?

Minikube is a tool that lets you run a local, single-node Kubernetes cluster on your laptop. It's ideal for developers who want to learn and test Kubernetes without using cloud services.

Unlike managed platforms like EKS (AWS), AKS (Azure), or GKE (Google Cloud), which run in the cloud and handle production-scale clusters, Minikube provides a simplified, self-contained local environment for development and experimentation. It supports various virtualization drivers (Docker, VirtualBox, etc.) and includes all the components needed to simulate a real Kubernetes cluster locally.

Installing Minikube:

Navigate here to download Minikube. Select your OS and follow the instructions. Alternatively for quick installations:

macOS (Homebrew)

brew install minikube

Windows (Chocolatey)

choco install minikube

Linux

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

What is Kubectl?

kubectl is the command-line tool used to interact with a Kubernetes cluster. It lets you deploy apps, inspect resources, view logs, and manage your cluster—all by sending commands to the Kubernetes API.

Whether you're using Minikube locally or a cloud service like EKS or AKS, kubectl is the primary way to control and monitor your cluster.

Installing KubeCTL

Navigate here to install KubeCTL
Alternatively, for quick install:

macOS (Homebrew)

brew install kubectl

Windows (Chocolatey)

choco install kubernetes-cli

Linux

curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

Verify Installation:

kubectl version --client

You should get this result:

🚀 Start Your First Local Cluster

With Minikube and kubectl installed, you can now spin up your first Kubernetes cluster:

minikube start

This may take a few minutes. Once it's done, check the node:

kubectl get nodes

You should see a node listed with a Ready status as shown:

🌐 Deploy a Sample App

Let’s test the setup by deploying a basic Nginx web server.

kubectl create deployment hello-nginx --image=nginx
kubectl expose deployment hello-nginx --type=NodePort --port=80

Explanation of These Commands:
-kubectl create deployment hello-nginx --image=nginx: Creates a Deployment named hello-nginx using the official Nginx image. Kubernetes ensures the pod stays running.
kubectl expose deployment hello-nginx --type=NodePort --port=80: Uses kubectl expose to make a deployment accessible externally. This creates a service that routes external traffic on a static port to the hello-nginx pods.

Then open it in your browser:

minikube service hello-nginx

This will open a browser window pointing to the Nginx welcome page served from your local Kubernetes cluster.

🧠 Recap

We just:

Learned about Kubernetes, Minikube and KubeCTL
Installed Minikube and KubeCTL
Launched a local Kubernetes cluster
Deployed and accessed a containerized app

You're now ready to dive deeper into Kubernetes concepts like Pods, Services, ReplicaSets, Deployments, and more — all from your local machine with the help of Minikube.

Azure Applied Skills: Create DNS zones and configure DNS settings

John Ogbonna — Sun, 27 Apr 2025 05:08:54 +0000

This is the last exercise in the Azure Networking series. Here we will:

Create and configure a private DNS zone.
Create and configure DNS records.
Configure DNS settings on a virtual network. We will be building on what we did in this exercise so make sure this exercise is done first

Exercise 05: Create DNS zones and configure DNS settings

Create a private DNS zone

On the Azure portal, search for and select Private dns zones
Select + Create and configure the DNS zone:
- Subscription: Select your subscription
- Resource group: Your RG
- Name: private.contoso.com
- Region: East US
Select Review + create and then select Create.
Wait for the DNS zone to deploy, and then select Go to resource.

Create a virtual network link to your private DNS zone

In order 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.

Working with the private.contoso.com DNS zone, in the DNS Management blade, select Virtual network links.
Select + Add” and enter:
- Link name: app-vnet-link
- Virtual network: app-vnet
- Enable auto registration: Enabled
Click create and wait for it to deploy

Create a DNS record set

DNS records provide information about the DNS zone.
Working on the private.contoso.com DNS zone, in the DNS Management blade, select + Recordsets.
There will be 2 A record sets there by default. Select +Add and configure like this:
- Name: backend
- Type: A
- TTL: 1
- IP address: 10.1.1.5
his record set implies there is a virtual machine in app-vnet with a private IP address of 10.1.1.5.

In this exercise, we created a private DNS zone (private.contoso.com) in Azure, linked it to a virtual network (app-vnet) with auto-registration enabled, and added a DNS A record for a backend server (10.1.1.5). This setup allows private name resolution within the virtual network, supporting internal communication without exposing resources to the public internet.

Azure Applied Skills: Configure network routing

John Ogbonna — Fri, 25 Apr 2025 23:15:44 +0000

In this article series, I will be walking though the process of configuring secure access to workloads using Azure virtual networking. In this exercise, we will:

Create and configure a route table.
Link a route table to a subnet.

We will be building on what was done in this exercise so make sure you have it done before attempting this one

Exercise 04: Configure network routing

In the search box at the top of the portal, search for and select Firewalls.
Select app-vnet-firewall (created in previous exercise)
Select Overview and record the Private IP address.
Search for and select Route tables
Click create route table
Enter these properties:
Subscription: Select your subscription
Resource group: Your resource group
Region: East US
Name: app-vnet-firewall-rt
Select Review + create and then select Create.
Wait for the route table to deploy, then select Go to resource.
In the portal, continue working with the route table, select app-vnet-firewall-rt.
Select Subnets and then + Associate.
Select this configuration:
- Virtual network: app-vnet
- Subnet: frontend
Again select + associate and add this configuration:
Select this configuration:
- Virtual network: app-vnet
- Subnet: backend
Select app-vnet-firewall-rt. in route tables
In Settings, select Routes and then + Add.
Configure:
- 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

You’ve now set up a route table and linked it to your subnets to direct all outbound traffic through the Azure Firewall. This ensures centralized control and enhanced security for your network traffic—an essential step in building a secure and well-managed Azure environment.

Azure Applied Skills: Creating and configuring Azure Firewall

John Ogbonna — Fri, 25 Apr 2025 04:06:08 +0000

In this article series, I will be walking though the process of configuring secure access to workloads using Azure virtual networking. In this exercise, we will:

Create an Azure Firewall.
Create and configure a firewall policy
Create an application rule collection.
Create a network rule collection.

We will be building on what was done in this exercise so make sure you have it done

Exercise 03: Create and configure Azure Firewall

Create Azure Firewall subnet in our existing virtual network

Search for and select Virtual networks in the Azure portal
Select app-vnet.
Select Subnets.
Select + Subnet.
Enter these settings
- Subnet purpose: Azure Firewall
- Name: AzureFirewallSubnet
- Starting address: 10.1.63.0
Click add after entering these settings
Search for and select Firewall
Select + create and enter these settings:
- Name: app-vnet-firewall
- Resource group: your resource group
- Firewall SKU: Standard
- Firewall management: Use a Firewall Policy to manage this firewall
- Firewall policy: Add new
- Policy name: fw-policy
- Region: East US
- Policy Tier: Standard
- Choose a virtual network: Use existing
- Virtual network: app-vnet
- Public IP address Add new: fwpip
Click Review + create when configured
Click create
Search for and select Firewall Policies
Select fw-policy
Under Rules, select Application rules and then Add a rule collection.
Configure the application rule and select add
- 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

![fw-policy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zvbjp86hf1ml1ump1zzo.png
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.

In Rules, select Network rules and then Add a rule collection.
Select this configuration:
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
Click add when configured

Verify the firewall and firewall policy status

Search for and select firewall
View the app-vnet-firewall and ensure the Provisioning state is Succeeded
In the portal serach for and select Firewall policies.
View the fw-policy and ensure the Provisioning state is Succeeded.

🔐 Azure Applied Skills: Exercise 03 – Azure Firewall Setup
This exercise builds on previous work by adding an Azure Firewall to control outbound traffic in your virtual network.

Key Steps:
Create AzureFirewallSubnet in app-vnet.

Deploy Azure Firewall with a new policy (fw-policy) and public IP (fwpip).

Add Application Rule: Allow HTTPS access from 10.1.0.0/23 to dev.azure.com and azure.microsoft.com.

Add Network Rule: Allow DNS (UDP port 53) to 1.1.1.1 and 1.0.0.1.

Verify both firewall and policy show Provisioning state: Succeeded.

✅ Result:
A centralized firewall is now in place, enabling secure, policy-driven control of traffic in Azure.

Azure Applied Skills: Creating and configuring network security groups

John Ogbonna — Tue, 22 Apr 2025 19:28:55 +0000

In this article series, I will be walking though the process of configuring secure access to workloads using Azure virtual networking. In this exercise, we will put in place the virtual networks and subnets. This exercise builds on top of what we did previously here

We will be walking through this exercise

We require the network traffic in the app-vnet to be tightly controlled with these requirements:

Frontend Subnet: Hosts internet-facing web servers. Assign them to an Application Security Group (ASG) for simplified management via their network interfaces.
Backend Subnet: Contains database servers accessed by the frontend. Attach a Network Security Group (NSG) to control access from the web servers.
Testing Setup: Deploy VM1 in the frontend and VM2 in the backend using the provided ARM template for Ubuntu servers.

Tasks:

Create a network security group.
Create network security group rules.
Associate a network security group to a subnet.
Create and use application security groups in network security group rules.

Exercise 02: Create and configure network security groups

This exercise requires the previous one to be done
Open the azure portal and click the button on the top right to launch the CLI. It will ask you to choose between bash or Powershell. select Powershell.
Select no storage, your subscription, then apply

Enter this command:

   $RGName = "your-rg"

   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

This will start up two virtual machines; vm1 and vm2 . Verify both are running in the virtual machines portal
In the portal, search for and select Application Security groups
Select create and configure the security group as follows:
- subscription: Select your subscription
- Resource Group: Your resource group (same as the ones the vms)
- name: app-frontend-asg
- Region: East US
Select review + create then create
When the deployment is done, Search for and select VM1
In the Networking blade, select Application security groups and then select Add application security groups. Then select
Select app-frontend-asg and select Add application security groups
Select app-frontend-asg then select Add

Create and Associate the Network Security Group

The purpose of Network security groups (NSGs) is to secure network traffic in a virtual network.

In the portal, search for and select Network security group Select+Create`
Enter these configurations:
- Subscription: your subscription
- Resource group: your resource group
- Name: app-vnet-nsg
- Region: East US
Select Review + create and then select Create.

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

Navigate to the app-vnet-nsg resource.
In the Settings blade select Subnets.
Select + Associate
Select app-vnet and then the Backend subnet. Select OK.

Create Network Security Group rules

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

In the app-vnet-nsg resource, In the Settings blade, select Inbound security rules.
Select + Add
Select this configuration:
- Source: Any
- Source port ranges: *
- Destination: Application Security group
- Destination application security group: app-frontend-asg
- Service: SSH
- Action: Allow
- Priority: 100
- Name: AllowSSH

Click add

### Conclusion
By completing this exercise, you've successfully configured secure access between frontend and backend workloads in Azure using Network Security Groups (NSGs) and Application Security Groups (ASGs). You’ve:

Deployed virtual machines across separate subnets for frontend and backend workloads.
Created and assigned an ASG to the frontend VM to simplify rule management.
Created an NSG, associated it with the backend subnet, and defined custom security rules to control access.
Allowed SSH access from the frontend ASG to the backend subnet—enabling controlled, secure communication between tiers.

This setup ensures that only explicitly defined network traffic—such as SSH from the frontend—is permitted, creating a strong security boundary within your virtual network. In the next exercise, you'll build on this foundation by implementing more advanced network features and controls.

Azure Applied Skills: Create and configure virtual networks

John Ogbonna — Mon, 21 Apr 2025 23:33:11 +0000

Requirements:

To do this exercise you will need:

An Azure subscription with Contributor RBAC role assigned. In this lab, when you are asked to create a resource, for any properties that are not specified, use the default value.

Exercise 01 - Create and configure virtual networks

In this section, we will be walking through the steps detailed here

This exercise will emulate the steps to migrate a web-based application to Azure. The first task is to put in place the virtual networks and subnets. Then we need to securely peer the virtual networks.

Tasks:
- Create a virtual network.
- Create a subnet.
- Configure vnet peering.

Steps:

Sign into the Azure portal
Search for and select Virtual Networks.
Click + Create
Enter these values:
- Subscription and Resource group: Your valid subscription and chosen resource group
- Virtual network name: app-vnet
- Region: (US) East US
Click IP addresses, then add IPV4 address space
Ensure that the new space starts at 10.1.0.0 and the size is /16
Delete the default address space
Click add a subnet
Call it frontend, make sure the starting address is 10.1.0.0 and the size is 24
Click add when settings are configured
Click Add subnet again in the same address space. Name it backend also a size of 24. Make sure that the starting address is 10.1.1.0. Click add
Final setup
Click review + create. Then create again and wait for deployment
Search for and select virtual networks again. Click + create, like in the other steps.
Use these settings for the configuration:
- Subscription and Resource Group: Same as previous virtual network
- Name: Virtual Network Name: hub-vnet
Click IP addresses
Click add subnet
Click add subnet. Choose Azure Firewall as the subnet purpose, leave the default settings, and click Add.
Remove the default space, click review + create

In the virtual networks portal, click app-vnet
Under peerings, select settings
Click add
Use these settings:
- Peering link name: app-vnet-to-hub
- Subscription: same subscription used earlier
- Virtual network: hub-vnet
- Local virtual network peering link name: hub-to-app-vnet
- Leave the rest on defaults and click "Add"
Once the deployment completes, verify the Peering status is Connected (in the peering menu of app-vnet)

At this point, you’ve successfully created and peered two virtual networks: app-vnet and hub-vnet. In the next exercise, we’ll start configuring security rules and deploying workloads within these networks.

Docker Applied Skills: Containerize a Node.js application

John Ogbonna — Thu, 20 Mar 2025 22:40:00 +0000

Docker Applied Skills: Containerize a Node.js Application

Introduction

Docker is a powerful tool for containerizing applications, allowing developers to package their code and dependencies into lightweight, portable containers. In this guide, we’ll walk through the process of containerizing a Node.js application using Docker. We will be following the steps outlined here

By the end of this tutorial, you will:

Set up a simple Node.js application.
Write a Dockerfile to containerize the application.
Build and run a Docker container.
Manage the container lifecycle using Docker commands.

Why containerize apps?

Containerizing apps offers several advantages:

Consistency: Ensures apps run the same across all environments (dev, test, prod).
Portability: Easily deployable across different platforms and cloud services.
Isolation: Prevents conflicts between app dependencies.
Scalability: Easily scale applications based on demand.
Faster Deployment: Containers are lightweight and start quickly.
Version Control: Manage and roll back app versions easily.
Resource Efficiency: Containers use fewer resources than VMs.
Security: Isolates apps for better security and risk management. Containerization streamlines development, deployment, and scalability, improving consistency, efficiency, and security.

Prerequisites

Before you begin, ensure you have the following installed on your system:

Node.js (LTS version)
Docker Desktop
A git client. The examples in this section use a command-line based git client, but you can use any client.

Let’s get started!

Getting the Sample Application

In your terminal/powershell, navigate to a folder where you'd like to store this sample application. To get the sample app, enter:

git clone https://github.com/docker/docker-nodejs-sample && cd docker-nodejs-sample

Then enter:

ls

To confirm that the files were brought in from git

Initialize Docker assets

To create the Docker assets necessary to containerize the application, we can use Docker's built in Docker init feature to streamline the process. Conversely, we can also create these assets manually. In this example, we will use Docker init
In the terminal enter:

docker init

Answer these prompts accordingly:

What application platform does your project use? Node
What version of Node do you want to use? (ensure latest version ex. 21.5.0)
Which package manager do you want to use? npm
What command do you want to use to start the app: node src/index.js
What port does your server listen on? 3000

Enter ls in the terminal. You should see these files:

Inside the docker-nodejs-sample directory, run the following command in a terminal to build the app:

docker compose up --build

If you get an error similar to this, refer to the next step:
To bypass file errors, modify the Dockerfile. Locate the CMD line and ensure that is says

CMD ["node", "src/index.js"]

Like this:
Run

docker compose up --build

again and it should work. You should see a message in the terminal like this:

Open your browser and navigate to http://localhost:3000/. You should see something like:

Summary:

This guide walks through the process of containerizing a Node.js application using Docker. The steps include setting up a Node.js app, writing a Dockerfile to containerize it, building and running the Docker container, and managing the container lifecycle with Docker commands.

Key steps include:

Containerization benefits: Docker ensures consistency, portability, isolation, scalability, faster deployment, and better security.
Getting the Sample App: Clone the sample node.js app from GitHub.
Initialize Docker Assets: Use Docker’s docker init to streamline the process of creating necessary Docker files for the project.
Build and Run the App: Use docker compose up --build to build the containerized app and fix any errors that might arise during the process.
The node.js application will be successfully containerized and running locally using Docker.

Getting Started with C# and .NET Core: Build a Web and Console App Using VS Code

John Ogbonna — Thu, 20 Mar 2025 04:39:55 +0000

Introduction:

C# is a powerful, modern programming language developed by Microsoft, widely used for building web applications, desktop software, cloud services, and more. In this guide, we will walk through creating both a console application and a web application using .NET Core and Visual Studio Code.

By the end of this tutorial, you will:

Set up your development environment with .NET Core and VS Code
Begin the setup of a web application using ASP.NET Core
Create a simple C# console application using AI generated code

Prerequisites:

Install .NET SDK from here or through VS code using this extension
Download and install Visual Studio Code from code.visualstudio.com
Let's dive in!
In your local machine, create a folder where we will make these apps. Open the terminal, VS code terminal or powershell and navigate to this folder
In the command line, enter:

dotnet --version

You should get a response similar to below. If get an error, you need to verify that .NET is properly installed and set up on your local machine

Creating and Running the Web App

Open the folder in VS code. Navigate to the terminal. Enter:

dotnet new web -n MyWebApp

Breakdown:
- dotnet new → Creates a new .NET project.
- web → Uses the ASP.NET Core minimal web app template.
- n MyWebApp → Names the project MyWebApp and creates a folder for it.
Open Program.cs and look at the code inside.
In the terminal navigate to the MyWebApp folder, enter

dontnet run

Look in the terminal. Hold control (or command for Mac) and click where it gives the localhost link. This will open the app in your web browser
In the browser you will see this:
Go back to VS code and press Control + c to stop the server. Look at the code in Program.cs. Notice this part in the code:
app.MapGet("/", () => "Hello World!");
This controls what is displayed. Try changing the displayed message. Example:

app.MapGet("/", () => "I'm learning C#!");

In the terminal, enter

dotnet build
dotnet run

Explanation:
- dotnet build: Compiles the C# code and checks for errors. Then generates an optimized binary (DLL file) inside the bin/ folder.
- dotnet run: Runs the compiled application on a web server that listens for requests.
Open the new localhost
You should see the new message

Creating and Running the Console App

Enter control + c in the terminal to stop the web app server.
Navigate out of the web app folder in the terminal using the command cd ..
To set up the files needed for a console app, enter the comand:

dotnet new console -n MyConsoleApp

This will create a folder called My console app with the necessary files to run a console app. Open the folder and navigate to Program.cs
In the terminal, navigate to the console app folder then enter

dotnet run

This will build and run the app. Note the output in the terminal:

As you can see, console apps primarily run in the terminal.

Generating and running sample code in the console

Open a generative AI of your choice. Enter a prompt similar to this: create a snake game that runs in c sharp console
Replace the contents of Program.cs with the generated code and save the file
In the terminal enter :

dotnet build
dotnet run

You can now use the app in the console

Summary

This article introduces C# development with .NET Core using Visual Studio Code. We explore the basics of creating and running both console and web applications using .NET.

Key Takeaways:
✅ Setting up the environment – using .NET SDK and VS Code
✅ Setting up a C# web application – Creating a minimal ASP.NET web app
✅ Setting up a C# console app – Generating and running a Snake game that runs in the terminal
✅ Modifying and running the app – Editing Program.cs and using dotnet build & dotnet run

This hands-on approach demonstrates how C# and .NET Core can be used to create both interactive console and web applications, making it a powerful tool for development. 🚀

Git Applied Skills: Using My Portfolio Template to Launch Your Own Portfolio Site

John Ogbonna — Tue, 18 Mar 2025 21:21:45 +0000

Creating a personal portfolio can be overwhelming, but with GitHub templates, you can set up your own site in minutes! In this guide, we'll use my GitHub portfolio template made for Software and Cloud developers to create a new repository, clone it, and customize it to fit your style.

By the end of this tutorial, you'll have:

A GitHub repository based on my template
A cloned version on your local machine
A ready-to-customize portfolio site

Let's get started!

🛠️ What You Need

Before we begin, make sure you have the following:

Git Command Line (CLI) You'll need Git installed to clone and manage your repository. If you don’t have Git yet, download and install it from: 🔗 Git Download Page

To check if Git is installed, run:

git --version

A text editor (VS Code highly recommended) A code editor is essential for modifying your portfolio. I recommend VS Code, which you can download here: 🔗 VS Code Download

Once you have these set up, you're ready to create your portfolio repository!

Making a Repository From the Template

In your browser, go to my portfolio template repository
Click on Use this template and then Create a new repository
- Give the repo a name
- Give the repo a description
- Select public or private
- Click create repository
Open your terminal and navigate to a suitable environment to download the template. Then enter this command:

git clone https://github.com/JohnOgbonna/my_dev_portfolio.git

Open the cloned folder in VS code

Editing Your site locally

Open the README.md to view the instructions on how to edit the site.
Edit the data.json file accordingly. Install VS Code live server. Open index.html in the editor, On the bottom right, click go live to view the site locally]
The site will open in the browser. As you make changes in data.json, you will see them in the browser
A mentioned in the README.md, To change the content displayed, simply edit the data.json. Add a profile picture to the root directory and call it profilepic.png. Remove the default one (unless you'd like an AI generated image of me as your portfolio profile picture). here is an example of the "skills" object I modified:

"skills": [
        {
            "platform": "AWS",
            "list": [
                "EC2",
                "S3",
                "Lambda",
                "DynamoDB",
                "Amplify",
                "Api Gateway",
                "SES"
            ]
        },
        {
            "platform": "Azure",
            "list": [
                "Azure Functions",
                "Blob Storage",
                "App Service",
                "Azure DevOps",
                "Azure Virtual Machines"
            ]
        },
        {
            "platform": "Google Cloud",
            "list": [
                "Cloud Functions",
                "Cloud Storage",
                "Firebase"
            ]
        }
    ]

Adjust the information for yourself accordingly. Follow the instructions and make sure your information follows the same pattern in order to avoid compilation errors when building the site.
Store article photos and project photos in the correct folder and reference them accordingly in data.json. Notice that these can also be web URLs
I changed my theme to light-red with the option to toggle dark mode. See a list of allowed theme setups in the README.md. Adjust these settings as you wish
My modified site:
If you are experienced in web development, feel free to modify ay of the other files and customize fully to get your desired look and feel.

Committing and pushing to Github

Once you are satisfied with your modifications, it's time to commit and push the changes. In the terminal enter:

git status

This will list all the changes you made to the base template
Then enter

git add .

This will add mark changes made to be committed
Then enter the following command, replacing "Commit message" with a meaningful description of your update::

git commit -m "Commit message"

This will now stage the changes to be pushed to the repository on git hub, then:

git push origin main

Your changes are now live in your GitHub repository in the main branch.

DEV Community: John Ogbonna

DevOps by Doing: Deploying NGINX on Azure Kubernetes Service (AKS) with Terraform

Why Use Terraform with AKS?

Prerequisites

Step 1: Create the Terraform Configuration

Step 2: Initialize and Apply Terraform

Step 3: Connect to Your AKS Cluster

Step 4: Deploy NGINX

Step 5: Verify Deployment

Step 6: Clean Up

DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 2

What this part covers

Step 1: GitHub Actions CI/CD Pipeline

Step 2: Dockerfile

Create Dockerfile

Dockerfile Explained

Dependencies Stage:

Production Stage

Step 3: Essential Configuration Files

Create .dockerignore

Create .gitignore

Create .env.example

Create ESLint configuration:

Step 4: Docker Compose for Development

Step 4: Test Everything Locally

Step 5: Deploy to GitHub

Step 6: Fix CI Security Scan Errors

Step 7: Kubernetes Deployment Configurations

Step 8: Complete Deployment Workflow

1. Branch-based Deployment Strategy

2. Deploy Changes

Deploy to Staging

3.Deploy to Production

🔎 Monitor Deployments

Check GitHub Actions status

Check your container registry

Test your deployed applications

🎯 Conclusion

DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 1

What We’ll Cover in This Series

Part 1: Laying the Foundation

In this first article, we’ll focus on the core project setup:

Step 1: Set Up Git for Version Control

1.1 Configure Git (if you haven’t already)

1.2 Initialize a Git Repository

1.3 Verify Repository Setup

Step 2: Build a Node.js Web App

2.1 Initialize a Node.js Project

2.2 Update package.json

Step 3: Create the Node.js Web Server

3.2 Install Dependencies

Step 4: Create Proper Tests

4.1 Create Tests Directory and File

4.2 Write Your First Tests

4.3 Configure Jest

4.4 Run the Tests

Step 5: Start the App 🚀

5.1 Start the Server

5.2 Verify Endpoints in Browser or curl

5.3 Stop the Server

🎉 Wrapping Up Part 1

Getting Started With Kubernetes: A Beginner’s Guide Using Minikube and KubeCTL

🤔 What is Kubernetes?

What is Minikube?

Installing Minikube:

What is Kubectl?

Installing KubeCTL

Verify Installation:

🚀 Start Your First Local Cluster

🌐 Deploy a Sample App

🧠 Recap

Azure Applied Skills: Create DNS zones and configure DNS settings

Exercise 05: Create DNS zones and configure DNS settings

Create a private DNS zone

Create a virtual network link to your private DNS zone

Create a DNS record set

Azure Applied Skills: Configure network routing

Exercise 04: Configure network routing

Azure Applied Skills: Creating and configuring Azure Firewall

Exercise 03: Create and configure Azure Firewall

Create `.dockerignore`

Create `.gitignore`

Create `.env.example`

2.2 Update `package.json`