DEV Community: Kosisochukwu Ugochukwu

Deploy a .NET 8 App to Azure Kubernetes Service (AKS) – Tutorial Guide

Kosisochukwu Ugochukwu — Fri, 19 Sep 2025 09:15:34 +0000

A beginner-friendly guide to deploying a .NET app to the cloud using Docker and Kubernetes.

Deploying applications to the cloud can seem daunting, especially if you are new to containers and Kubernetes. This guide is designed for beginners and walks you step by step through building a simple .NET 8 Web API, packaging it in a Docker container, and deploying it to Azure Kubernetes Service (AKS). By the end, you will also have automated deployments via GitHub Actions, so any code push instantly updates your app in the cloud.

Think of it as a hands-on way to learn modern cloud deployment, without getting lost in complex setups. By the time you finish, you will not only understand the tools but also gain confidence in deploying real-world apps to the cloud.

What You will Learn

By the end of this tutorial, you will know how to:

Build a .NET 8 Web API
Containerize your app with Docker
Deploy containers to Kubernetes in the cloud
Set up automated deployments with GitHub Actions

What You will be able Build :

Simple Weather API – Returns fake weather data (just like a real weather app)
Containerized App – Runs in Docker containers
Cloud Deployment – Hosted on Azure Kubernetes Service (AKS)
Automatic Updates – Push code to GitHub → auto-deploys to Azure

Required Tools to Set Up Your Computer

Install the following:

Visual Studio Code – code.visualstudio.com

.NET 9 SDK – dotnet.microsoft.com

Docker Desktop – docker.com/products/docker-desktop

Start Docker Desktop after installing

Azure CLI – docs.microsoft.com/cli/azure/install-azure-cli

kubectl (Kubernetes CLI) – kubernetes.io/docs/tasks/tools/

GitHub CLI – cli.github.com

Git – git-scm.com

Required Accounts

GitHub Account – github.com

Azure Account – azure.microsoft.com/free

Test Your Setup

Run these commands in your terminal (Command Prompt on Windows, Terminal on Mac/Linux) to verify:

dotnet --version
docker --version
az --version
kubectl version --client
gh --version
git --version

You should see version numbers for all tools. If anything fails, reinstall that tool.

Step 1: Create the .NET Application

Let’s start by building a simple .NET 8 Web API that we will later containerize and deploy to Azure.

1.1 Set Up Project Structure

Create a new folder for your app:

mkdir weather-app-demo
cd weather-app-demo
mkdir WeatherApp
cd WeatherApp

1.2 Initialize a .NET Project

Generate a minimal Web API template:

dotnet new webapi -minimal

1.3 Add Dependencies

Install the required packages:

dotnet add package Microsoft.Extensions.Diagnostics.HealthChecks
dotnet add package Swashbuckle.AspNetCore

HealthChecks – adds a /health endpoint (important for Kubernetes).
Swashbuckle – provides Swagger UI for API docs.

1.4 Write the Application Code

Replace the contents of Program.cs with the following:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container
builder.Services.AddHealthChecks();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Configure Kestrel to listen on port 8080 (required for containers)
builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenAnyIP(8080);
});

var app = builder.Build();

// Configure the HTTP request pipeline
if (app.Environment.IsDevelopment() || app.Environment.IsProduction())
{
    app.UseSwagger();
    app.UseSwaggerUI(c => 
    {
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "Weather API v1");
        c.RoutePrefix = "swagger";
    });
}

// Define API endpoints
app.MapGet("/", () => new
{
    Message = "Welcome to the Weather App!",
    Version = "1.0.0",
    Environment = app.Environment.EnvironmentName,
    Timestamp = DateTime.UtcNow
})
.WithName("GetWelcome")
.WithTags("General");

app.MapGet("/weather", () =>
{
    var summaries = new[] { 
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", 
        "Warm", "Balmy", "Hot", "Sweltering", "Scorching" 
    };

    var forecast = Enumerable.Range(1, 5).Select(index => new
    {
        Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
        TemperatureC = Random.Shared.Next(-20, 55),
        TemperatureF = 0,
        Summary = summaries[Random.Shared.Next(summaries.Length)]
    })
    .Select(temp => new
    {
        temp.Date,
        temp.TemperatureC,
        TemperatureF = 32 + (int)(temp.TemperatureC / 0.5556),
        temp.Summary
    });

    return forecast;
})
.WithName("GetWeatherForecast")
.WithTags("Weather");

// Health check endpoint (required for Kubernetes)
app.MapHealthChecks("/health")
.WithTags("Health");

app.Run();

1.5 Run and Test Locally

Start the application:

dotnet run

Now, test the endpoints in your browser:

http://localhost:8080/ → Welcome message

http://localhost:8080/weather → Weather forecast

http://localhost:8080/swagger → API docs

http://localhost:8080/health → Health check endpoint

Press Ctrl + C to stop the app.

At this point, you have a working .NET API that’s container-ready. Next, we willl Dockerize the app so it can run inside a container.

Step 2: Containerize Your Application

Now that the app runs locally, let’s package it into a Docker container so it can run consistently anywhere.

2.1 Create a Dockerfile

Inside the WeatherApp folder, create a file named Dockerfile (no extension) and add the following:

# Multi-stage build for optimized image size

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
WORKDIR /app
EXPOSE 8080
ENV ASPNETCORE_URLS=http://+:8080
ENV ASPNETCORE_ENVIRONMENT=Production

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src

# Copy project file and restore dependencies
COPY ["WeatherApp/WeatherApp.csproj", "."]
RUN dotnet restore "WeatherApp.csproj"

# Copy source code and build
COPY . .
WORKDIR /src
COPY WeatherApp/ ./WeatherApp/
WORKDIR /src/WeatherApp
RUN dotnet restore "WeatherApp.csproj"
RUN dotnet build "WeatherApp.csproj" -c $BUILD_CONFIGURATION -o /app/build

# Publish stage
FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "WeatherApp.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

# Final stage
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WeatherApp.dll"]

This uses a multi-stage build to keep the final image lightweight:

Build stage compiles your app.
Publish stage outputs optimized binaries.
Final stage only contains what’s needed to run.

2.2 Create a .dockerignore File

Create a .dockerignore file in the root of your project to prevent unnecessary files from being copied into the Docker image:

# Build outputs
bin/
obj/
out/

# IDE files
.vs/
.vscode/
*.user
*.suo

# OS files
.DS_Store
Thumbs.db

# Git
.git/
.gitignore

# Documentation
README.md
*.md

# Docker
Dockerfile*
.dockerignore

# Logs
*.log
logs/

This keeps your Docker image clean and small.

2.3 Build and Test the Container

Build the Docker Image
docker build -t weather-app:local .

Run the Container
docker run -d -p 8080:8080 --name weather-test weather-app:local

Test the App Inside Docker
curl http://localhost:8080/
curl http://localhost:8080/weather

Or just visit in your browser:

http://localhost:8080/

http://localhost:8080/weather

Stop & Remove the Container
docker stop weather-test
docker rm weather-test

At this point, your app is running inside a container. Next, we’ll push the container to a registry and deploy it to Azure Kubernetes Service (AKS).

Step 3: Set Up Azure Infrastructure

Now that your app runs inside a container, it’s time to deploy it to the cloud. We will use Azure Kubernetes Service (AKS), along with Azure Container Registry (ACR) to store and distribute your Docker images.

3.1 Authenticate with Azure

Log in to your Azure account:

az login

This opens your browser for sign-in.

3.2 Select Your Subscription

List your available subscriptions:

az account list --output table

Set the subscription you want to use:

az account set --subscription "Your-Subscription-Name"

3.3 Create a Resource Group

A resource group is a logical container for all your Azure resources:

az group create --name student-demo --location eastus

3.4 Create a Container Registry (ACR)

We will use ACR to store our Docker images. Make sure the name is unique (append initials/year if needed):

az acr create \ --resource-group student-demo \ --name studentdemo3121acr \ --sku Basic

Note if you have an error while creating RG for your container registry, use this code below to register namespace on your container registry: az provider register --namespace Microsoft.ContainerRegistry

3.5 Build & Push the Image to ACR

Instead of building locally and pushing manually, we will let Azure build and push the image for us using az acr build.

From the folder containing your Dockerfile:

az acr build \ --registry studentdemo3121acr \ --image weather-app:latest \ .

Note: Below is what the code means:

registry studentdemo3121acr → Your ACR name
image weather-app:latest → Tags the image inside ACR
Uses the Dockerfile in the current directory

Note: This avoids compatibility issues since the build runs directly in Azure.

3.6 Create an AKS Cluster with ACR Integration

Now let’s create the Kubernetes cluster where our app will run:

az aks create \
  --resource-group student-demo \
  --name student-aks-cluster \
  --node-count 1 \
  --node-vm-size Standard_B2s \
  --attach-acr studentdemo2024acr \
  --enable-managed-identity \
  --generate-ssh-keys

What this does:

Creates a managed AKS cluster
Adds 1 VM node (2 vCPUs, 4 GB RAM)
Integrates ACR automatically (avoids ImagePullBackOff errors)
Generates SSH keys for secure access

Now wait 5–10 minutes for Azure to provision everything (coffee break time ☕).

3.7 Connect to Your AKS Cluster

Once the cluster is ready, configure kubectl to connect:

az aks get-credentials \ --resource-group student-demo \ --name student-aks-cluster

Verify the connection:

kubectl get nodes

You should see your Kubernetes node(s) listed.

3.8 Verify ACR Integration (Optional)

Check that your AKS cluster can pull images from ACR:

CLIENT_ID=$(az aks show \
  --resource-group student-demo \
  --name student-aks-cluster \
  --query "identityProfile.kubeletidentity.clientId" \
  --output tsv)

echo "Kubelet Client ID: $CLIENT_ID"

Now confirm the role assignment:

az role assignment list \ --assignee $CLIENT_ID \ --scope $(az acr show --name studentdemo3121acr --query id --output tsv) \ --output table

You should see an AcrPull role. If not, create it manually:

az role assignment create \ --assignee $CLIENT_ID \ --role AcrPull \ --scope $(az acr show --name studentdemo3121acr --query id --output tsv)

At this point, you have a fully provisioned Azure Kubernetes cluster and a container image stored in ACR. Next, we will deploy the app into Kubernetes.

Step 4: Create Kubernetes Configuration

Now that we have our AKS cluster and image in ACR, it’s time to define the Kubernetes manifests that describe how our app should run in the cluster.

4.1 Set Up a Manifests Directory

Organize your Kubernetes YAML files inside a k8s folder:

cd .. to Go back to weather-app-demo root
mkdir k8s
cd k8s

4.2 Create the Deployment

A Deployment ensures your app runs in Kubernetes with the desired number of replicas, health checks, and resource limits.

Create a file called deployment.yaml:

touch .deployment.yaml - This creates a file
Now copy and paste the code below into the deployment.yaml file created

apiVersion: apps/v1
kind: Deployment
metadata:
  name: weather-app
  labels:
    app: weather-app
    version: v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: weather-app
  template:
    metadata:
      labels:
        app: weather-app
        version: v1
    spec:
      containers:
      - name: weather-app
        image: studentdemo2024acr.azurecr.io/weather-app:latest
        imagePullPolicy: Always
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        env:
        - name: ASPNETCORE_ENVIRONMENT
          value: "Production"
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: http
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /health
            port: http
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /health
            port: http
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 30

Notes:

Uses 2 replicas for high availability.

Includes liveness, readiness, and startup probes to let Kubernetes know when the app is healthy.

No imagePullSecrets needed because AKS was created with --attach-acr to handle authentication automatically!

4.3 Create the Service

A Service exposes your app to the internet through a cloud load balancer.

Create a file called service.yaml:
Same process we used in 4.2

apiVersion: v1
kind: Service
metadata:
  name: weather-app-service
  labels:
    app: weather-app
spec:
  type: LoadBalancer
  selector:
    app: weather-app
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP

4.4 Deploy to Kubernetes

Apply both manifests to your cluster:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Check status:

kubectl get deployments
kubectl get pods
kubectl get services

Watch pods come online:

kubectl get pods --watch

Once ready, your service will show an external IP, use that to access the app in your browser.

4.5 Troubleshooting Tips

If you see ImagePullBackOff, debug like this:

Describe pod to see error details

kubectl describe pod $(kubectl get pods -l app=weather-app -o jsonpath='{.items[0].metadata.name}')

Verify the image exists in ACR

az acr repository show-tags --name studentdemo2024acr --repository weather-app --output table

Restart deployment (forces a new image pull)

kubectl rollout restart deployment/weather-app

At this point, your app should be running on AKS and accessible from the public LoadBalancer IP.

Step 5: Set Up GitHub Actions CI/CD

With our app running in AKS, the final step is to automate deployment using GitHub Actions.
This way, every time you push changes to your repo, GitHub will:

Build the .NET app.
Build and push a Docker image to Azure Container Registry (ACR).
Update the Kubernetes deployment in AKS.

5.1 Initialize Git Repository

If you haven’t already:

cd .. ### Back to weather-app-demo folder

git init
git add .
git commit -m "Initial commit: Weather App with Docker and Kubernetes"

5.2 Create Azure Service Principal

GitHub Actions needs credentials to interact with Azure. For that, we will create a Service Principal (SP).

Get your subscription ID:

SUBSCRIPTION_ID=$(az account show --query id --output tsv) echo "Subscription ID: $SUBSCRIPTION_ID"

Create the service principal:

az ad sp create-for-rbac \ --name "weather-app-github-sp" \ --role contributor \ --scopes /subscriptions/$SUBSCRIPTION_ID/resourceGroups/student-demo \ --sdk-auth

Important: Copy the full JSON output. You will paste it into GitHub Secrets in a moment.

5.3 Create GitHub Repository

You can create a repo either via GitHub CLI:

gh auth login ### Follow the prompts
gh repo create weather-app-demo --public --source=. --push

Or manually on GitHub.com → then push your local repo.

5.4 Configure GitHub Secrets

In your repo, go to:

Settings → Secrets and variables → Actions → New repository secret

Add the following secrets:

Secret Name Value AZURE_CREDENTIALS The full JSON output from Step 5.2 ACR_NAME studentdemo3121acr (your ACR name) RESOURCE_GROUP student-demo CLUSTER_NAME student-aks-cluster

OR configure in gh CLI

Set AZURE_CREDENTIALS (the JSON from step 5.2): gh secret set AZURE_CREDENTIALS

This will open an interactive prompt where you can paste your JSON credentials from step 5.2

Set the other secrets:

gh secret set ACR_NAME --body "studentdemo3121acr"
gh secret set RESOURCE_GROUP --body "student-demo"
gh secret set CLUSTER_NAME --body "student-aks-cluster"

5.5 Create GitHub Workflow

Now add the GitHub Actions workflow.

mkdir -p .github/workflows
touch .github/workflows/deploy.yml

Paste the code below into .github/workflows/deploy.yml:

name: Build and Deploy to AKS
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

env:
  IMAGE_NAME: weather-app

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '9.0.x'

      - name: Restore dependencies
        run: dotnet restore WeatherApp/WeatherAPP.csproj

      - name: Build application
        run: dotnet build WeatherApp/WeatherAPP.csproj --configuration Release --no-restore

      - name: Run tests
        run: dotnet test WeatherApp/WeatherAPP.csproj --no-build --verbosity normal || true

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Setup Azure CLI
        uses: azure/cli@v2
        with:
          inlineScript: echo "Azure CLI setup complete"

      - name: Build and push Docker image to ACR
        run: |
          IMAGE_TAG=${{ secrets.ACR_NAME }}.azurecr.io/${{ env.IMAGE_NAME }}:${{ github.sha }}
          az acr build \
            --registry ${{ secrets.ACR_NAME }} \
            --image ${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --file WeatherApp/Dockerfile \
            .
          echo "IMAGE_TAG=$IMAGE_TAG" >> $GITHUB_ENV

      - name: Deploy to AKS
        if: github.ref == 'refs/heads/main'
        run: |
          echo "Checking if AKS cluster exists..."
          if ! az aks show --resource-group "${{ secrets.RESOURCE_GROUP }}" --name "${{ secrets.CLUSTER_NAME }}" --output table; then
            echo "ERROR: AKS cluster '${{ secrets.CLUSTER_NAME }}' not found in resource group '${{ secrets.RESOURCE_GROUP }}'"
            exit 1
          fi

          echo "Getting AKS credentials..."
          az aks get-credentials \
            --resource-group ${{ secrets.RESOURCE_GROUP }} \
            --name ${{ secrets.CLUSTER_NAME }} \
            --overwrite-existing

          echo "Testing kubectl connection..."
          kubectl cluster-info

          echo "Updating deployment with image: ${{ env.IMAGE_TAG }}"
          kubectl set image deployment/weather-app \
            weather-app=${{ env.IMAGE_TAG }}

          echo "Waiting for rollout to complete..."
          kubectl rollout status deployment/weather-app --timeout=600s

          echo "Deployment status:"
          kubectl get pods -l app=weather-app
          kubectl get service weather-app-service

5.6 Deploy Your Application

Commit and push:

git add .
git commit -m "Add GitHub Actions CI/CD pipeline"
git push origin main

Now open your GitHub repo → Actions tab.
You will see the workflow running, building your Docker image, pushing to ACR, and updating your AKS cluster.

And just like that, we have built a full CI/CD pipeline for your .NET 8 app on Azure Kubernetes Service.

Step 6: Access Your Deployed Application

Your app is now deployed on Azure Kubernetes Service. Let’s get the public URL so you can test it live.

6.1 Get the External IP Address

Check the status of your Kubernetes service:

kubectl get service weather-app-service

You will see output like this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
weather-app-service LoadBalancer 10.0.123.45 20.85.102.11 80:31000/TCP 2m

👉 The EXTERNAL-IP column is what you will use.
It may take 2–5 minutes to show up. Watch until it’s assigned:

kubectl get service weather-app-service --watch

6.2 Test Your Live Application

Once you have the external IP, test the endpoints:

For the Welcome message:

curl http://YOUR-EXTERNAL-IP/

Weather forecast:
curl http://YOUR-EXTERNAL-IP/weather

Health check:
curl http://YOUR-EXTERNAL-IP/health

Or just open it in your browser:

Swagger UI (API docs):

open http://YOUR-EXTERNAL-IP/swagger ### macOS
start http://YOUR-EXTERNAL-IP/swagger ### Windows

In macOS

✅ Congratulations! Your .NET 8 Weather API is now fully containerized, deployed on Kubernetes, and publicly accessible through Azure AKS.

Step 7: Test Continuous Deployment

Now let’s see GitHub Actions automatically deploy changes to AKS with no manual intervention required.

7.1 Make a Code Change

Edit WeatherApp/Program.cs to update the welcome message, for example:

app.MapGet("/", () => new
{
    Message = "Welcome to the Updated Weather App! 🌤️",
    Version = "1.1.0",
    Environment = app.Environment.EnvironmentName,
    Timestamp = DateTime.UtcNow,
    DeployedBy = "GitHub Actions"
});

This small change is perfect to test the pipeline.

7.2 Push the Changes

git add .
git commit -m "Update welcome message and version"
git push origin main

Pushing to the main branch triggers your GitHub Actions workflow automatically.

7.3 Verify Auto-Deployment

Open your GitHub repository → Actions tab.
Watch the workflow run:

Builds the .NET app
Builds & pushes the Docker image to ACR
Updates the Kubernetes deployment in AKS

Once completed, test your updated app:

curl http://YOUR-EXTERNAL-IP/

You should see the new welcome message and updated version, confirming that CI/CD is working flawlessly as confirmed below.

✅ Congratulations! we have now have a fully functional CI/CD pipeline:

Push code → automatically builds, pushes, and deploys
Changes reflected live in your AKS cluster
All without manually logging into Azure

Troubleshooting Guide

Even with the best setup, things can go wrong. Here are some common issues you might face and how to fix them.

Pods stuck in ImagePullBackOff or ErrImagePull

Symptoms:
Your pods won’t start and show ImagePullBackOff.

Fixes:

# Check pod details
kubectl describe pod $(kubectl get pods -l app=weather-app -o jsonpath='{.items[0].metadata.name}')

# Verify AKS can access your ACR
az aks check-acr \
  --resource-group student-demo \
  --name student-aks-cluster \
  --acr studentdemo2024acr.azurecr.io

# Re-attach ACR if needed
az aks update \
  --resource-group student-demo \
  --name student-aks-cluster \
  --attach-acr studentdemo2024acr

# Force pod recreation
kubectl delete pods -l app=weather-app

2. kubectl: command not found

Symptoms:
kubectl isn’t recognized.

Fixes:

# Check if installed
kubectl version --client

If not installed, follow the official guide:
👉 Install kubectl

3. Docker daemon not running

Symptoms:
Docker commands fail with “Cannot connect to the Docker daemon.”

Fixes:

Start Docker Desktop
Wait until the green status indicator shows
Restart your terminal

4. Access denied to Azure resources

Symptoms:
Azure CLI commands fail with “unauthorized” errors.

Fixes:

az logout
az login
az account show

Verify you are using the correct subscription.

5. GitHub Actions pipeline failing

Check these first:

All GitHub secrets are correctly set (AZURE_CREDENTIALS, ACR_NAME, etc.)
The Azure service principal has Contributor access to your resource group
Inspect the GitHub Actions logs for detailed error messages

6. Application not accessible via External IP

Fixes:

# Check pods
kubectl get pods

# Check service
kubectl get services

# Inspect pod logs
kubectl logs deployment/weather-app

# Describe the service
kubectl describe service weather-app-service

**Debugging Commands**

These are useful one-liners when things don’t go as planned:

# Cluster info
kubectl cluster-info

# All resources in the namespace
kubectl get all

# Pod logs
kubectl logs -l app=weather-app

# Deployment details
kubectl describe deployment weather-app

# Node status
kubectl get nodes -o wide

# Monitor pods in real-time
kubectl get pods --watch

# ACR repositories
az acr repository list --name studentdemo2024acr --output table

# ACR image tags
az acr repository show-tags \
  --name studentdemo2024acr \
  --repository weather-app \
  --output table

✅ With these troubleshooting steps, you should be able to resolve most common deployment issues quickly.

Clean Up Resources

Once you are done experimenting, don’t forget to clean up your Azure resources otherwise, you may keep paying for unused services.

You have two options:

Option 1: Delete Individual Resources

If you want to keep the resource group but remove specific resources:

Delete Kubernetes resources (Deployment + Service)

kubectl delete -f k8s/

Delete AKS cluster

az aks delete \ --resource-group student-demo \ --name student-aks-cluster \ --yes

Delete Azure Container Registry (ACR)

az acr delete \ --name studentdemo3121acr \ --yes

Option 2: Delete Everything (Recommended)

If this was just a demo project, the easiest and safest way is to delete the entire resource group:

Delete the entire resource group (removes AKS, ACR, etc.)

az group delete \ --name student-demo \ --yes \ --no-wait

⚠️ Note: Your GitHub repository and workflow remain intact — only Azure resources will be deleted.

What we have Accomplished

By following along, we have gone from zero to cloud-native hero. Here’s what we have built:

A Production-Ready .NET 8 Web API

RESTful endpoints with proper HTTP responses
Health checks for monitoring
Swagger documentation for easy API testing

Mastered Docker Containerization

Multi-stage Docker builds for optimization
Container security best practices
Local testing and validation

Deployed to Azure Kubernetes Service (AKS)

Infrastructure as Code with Azure CLI
Kubernetes manifests with proper resource requests/limits
LoadBalancer service for external access

Implemented CI/CD with GitHub Actions

Automated build and test pipeline
Container registry integration (ACR)
Zero-downtime deployments with rolling updates

Applied Cloud-Native Best Practices

Health, readiness, and startup probes for reliability
Resource limits for efficiency
Environment-specific configurations

📚 Next Steps

Now that you have got the foundation, here’s how you can level up:

Beginner Level

Add a Database: Integrate Azure SQL or PostgreSQL, use EF Core for persistence
Enhance Monitoring: Add Application Insights, set up log aggregation, track custom metrics
Implement Security: Add authentication with Azure AD, enable API versioning, and secure with HTTPS

Intermediate Level

Advanced Kubernetes Features: ConfigMaps & Secrets, Horizontal Pod Autoscaling, Ingress controllers with custom domains
Infrastructure as Code: Learn Azure Bicep or Terraform, adopt GitOps with ArgoCD, manage multiple environments
Observability Stack: Prometheus & Grafana for metrics, Jaeger for distributed tracing, ELK stack for centralized logging

You now have the skills to build, ship, and run modern .NET apps on the cloud like a pro. From here, the sky’s the limit, scale it, secure it, and make it production-grade!

Azure Kubernetes Service (AKS) Deployment - Complete Guide Sheet

Whether you are deploying your first .NET app to Kubernetes or need a quick refresher, this cheat sheet gives you everything you need from Docker to AKS to GitHub Actions.

Core Concepts Explained
⚡ Kubernetes

Container Orchestrator: Manages your containers like a traffic controller
Scaling: Add/remove pods based on load
Self-Healing: Restarts crashed pods automatically
Load Balancing: Routes traffic evenly across replicas

🐳 Docker

Containerization: Package app + dependencies
Consistency: "Works on my machine" → "Works everywhere"
Isolation: Each container runs independently

📦 Azure Container Registry (ACR)

Private Docker Hub: Secure container storage
Version Control: Track different image versions
Integration: Works seamlessly with AKS

🛠️ Prerequisites
Tool Purpose Why You Need It
VS Code Code Editor Write and edit code
.NET 8 SDK Build Tool Compile your C# app
Docker Desktop Containers Build & test locally
Azure CLI Cloud Management Create/manage Azure resources
kubectl Kubernetes Client Deploy & manage apps on AKS
GitHub CLI Repo Management Create and push repos
Git Version Control Track code changes

Accounts Needed

GitHub → Free for repos & CI/CD
Azure → $200 free credit to host apps

Azure Infrastructure
📂 Resource Group

az group create --name student-demo --location eastus`

Resource group: Think of it as a project folder for all Azure resources

Container Registry (ACR)

az acr create --resource-group student-demo --name studentdemo2024acr --sku Basic

Container registry is like an app store, where things can be stored, share, and download ready-to-run software packages called containers.
Think of it like your private Docker Hub

AKS Cluster

az aks create --resource-group student-demo --name student-aks-cluster --node-count 1

This is like a managed Kubernetes cluster with auto-scaling & healing

.NET App Breakdown
🔑 Program.cs

Health Checks → app.MapHealthChecks("/health");
Swagger → API testing UI
Endpoints → /, /weather, /health

Kestrel Config

builder.WebHost.ConfigureKestrel(options => {
    options.ListenAnyIP(8080);
});

Runs on port 8080 inside container

Docker Setup
📜 Dockerfile (multi-stage build)

Base → runtime image
Build → SDK to restore & publish
Final → small, production-ready image

.dockerignore

Ignore bin/, obj/, .git/ → smaller, faster, more secure builds

Kubernetes Manifests
📦 deployment.yaml

replicas: 2 → high availability
resources.requests/limits → efficient pod usage
health probes → auto-healing + traffic control

service.yaml

type: LoadBalancer
ports:
  - port: 80
    targetPort: 8080

This exposes app with an external IP

GitHub Actions Workflow
🔄 CI/CD Pipeline Highlights

Checkout Code → actions/checkout@v4
Setup .NET → build/test app
Azure Login → via service principal
Build & Push Image → to ACR
Deploy to AKS → update deployment, restart rollout

Secrets Required

AZURE_CREDENTIALS → Service principal JSON

ACR_NAME → Your ACR name

RESOURCE_GROUP → Azure resource group

CLUSTER_NAME → AKS cluster name

Monitoring & Observability

Health Checks → HTTP 200 = healthy

Probes:

Liveness → restart if dead
Readiness → remove from traffic if unready
Startup → delay checks until app boots

Troubleshooting Essentials

Check Deployment → kubectl rollout status deployment/weather-app
Pod Logs → kubectl logs <pod-name>
Service Info → kubectl describe service weather-app-service
Image Issues → az acr repository show-tags --name studentdemo2024acr --repository weather-app

Quick Reference Commands
Docker

docker build -t app:tag .
docker run -p 8080:8080 app:tag
docker logs container-name

Kubernetes

kubectl apply -f k8s/
kubectl get pods
kubectl logs -f <pod-name>
kubectl scale deployment weather-app --replicas=3

Azure CLI

az aks get-credentials --resource-group student-demo --name student-aks-cluster
az acr login --name studentdemo2024acr
az group delete --name student-demo --yes

🔥 With this guide sheet which i call cheat sheet, you have all the key commands, configs, and concepts at your fingertips for deploying .NET apps on AKS with GitHub Actions.

🛠️ The Full Stack DevOps Workshop

Kosisochukwu Ugochukwu — Tue, 09 Sep 2025 11:24:52 +0000

Understanding DevOps: Bridging Development and Operations

If you have ever built an app and thought:

How do I make sure it runs the same everywhere?
How can I test changes automatically?
How do I go from my laptop to production safely? …then this guide is for you.

In this hands-on tutorial, we will walk step-by-step through setting up a complete DevOps pipeline, from writing simple Node.js code, all the way to automated CI/CD deployments with Docker and Kubernetes.

By the end, you will know how to:

Set up Git, Docker, and GitHub Actions
Write and run automated tests
Build lightweight, secure Docker images
Use CI/CD pipelines to test, build, and deploy automatically
Deploy to staging (for testing) and production (for real users) with confidence

Note: No prior DevOps experience required, just a willingness to code, learn, and experiment.

Hands-On Practice: Preparing Your DevOps Workspace

🔧 Before You Begin: Install Required Tools

Before starting, let’s prepare your machine with the right tools:

Node.js (v18 or higher, LTS v20 recommended in 2025)
- Download: nodejs.org
- Choose the LTS version (20.x)
- Verify installation:
```
 node --version
 npm --version
```
Git (latest stable version)
- Download: git-scm.com/downloads
- Pick your operating system
- Verify installation:
```
 git --version
```
Docker Desktop (latest version)
- Download: docker.com/products/docker-desktop
- Install and start Docker Desktop
- Verify installation:
```
 docker --version
 docker-compose --version
```
GitHub Account
- Sign up: github.com
- Needed for hosting your code and setting up CI/CD pipelines
Code Editor (optional but recommended)
- Suggested: Visual Studio Code
- Or use any editor you prefer (Sublime Text, Atom, etc.)

Final Check: Make Sure Everything Works

Run these commands in your terminal:

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:

This tells Git who you are (your name and email) so it can label your changes. It also creates a folder for your project and starts tracking it with Git.

One-time Git Setup

Run these commands (replace with your name and email):

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

Create and Initialize Your Project

Now, let’s create a new folder and start Git inside it by running the following command:

mkdir devops-project
cd devops-project
git init

Step 2: Build a Node.js Web App

What this step does:

We will create a simple Node.js app that serves web pages and API endpoints. This will be the foundation for our DevOps journey.

1. Initialize Node.js Project

What it does:

Creates a package.json file that describes your project and manages dependencies.

# Create package.json with default settings
`npm init -y`

After running this, you will see a new package.json file in your project folder.

Update package.json

What it does:
Adds scripts, metadata, and development tools to your project setup.

Open the file in your editor, or create one with:

touch package.json

Note: Since we are using a vscode in linux npm init -y has done the opening for us but had it been we are using ubuntu or a linux server we must use touch package.json to open the file in the editor.

So copy and paste this content in the open file editor:

{
  "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"
  }
}

3. Create the Main Application File
What it does:
Creates the main web server (app.js) that:

Listens on port 3000
Serves routes: /, /health, /info, /metrics
Adds security headers
Supports graceful shutdown
Exports the server for testing

Create a the main application file using the code below:

touch app.js

Copy this into 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();

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

  switch (pathname) {
    case '/':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/html');
      res.end(`<h1>I'm Getting Better at DevOps, Yay!</h1>`);
      break;

    case '/health':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({ status: 'healthy', uptime: process.uptime() }, null, 2));
      break;

    case '/info':
      res.statusCode = 200;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({ platform: process.platform, pid: process.pid }, 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}`);
      break;

    default:
      res.statusCode = 404;
      res.setHeader('Content-Type', 'application/json');
      res.end(JSON.stringify({ error: 'Not Found' }, null, 2));
  }
});

process.on('SIGTERM', () => server.close(() => process.exit(0)));
process.on('SIGINT', () => server.close(() => process.exit(0)));

server.listen(port, () => {
  console.log(`🚀 Server running at http://localhost:${port}/`);
});

module.exports = server;

Install Dependencies

What it does:
Installs the testing and linting tools your app will use.

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

### Install all dependencies
npm install

You wll now see:

A node_modules/ folder with installed packages

A package-lock.json file locking dependency versions

Step 3: Create Proper Tests

Now that your Node.js app is ready, it’s important to make sure it works every time you make changes. Automated testing lets you check your app’s endpoints without doing it manually.

Create a tests folder → Store all your test files in one place.
Write test cases → Each test checks if a specific route (/, /health, /info, /metrics) works as expected.
Configure Jest → Tell Jest how to run your tests and where to store coverage reports.

By the end of this step, you will have an automated system that validates your app every time you make a change.

Creating Proper Tests

What this step does:
Sets up automated testing so your application is checked every time you make changes.

1. Create Tests Directory and File

### Create a folder for your tests
mkdir tests

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

2. Write Test Cases

What it does:
Checks if your web server endpoints are working correctly.

Copy this code into tests/app.test.js:

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

Configure Jest

What it does:
Tells Jest how to run your tests and generate coverage reports.

# Create Jest configuration file
touch jest.config.js

Copy this into jest.config.js:

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

Step 4: Add GitHub Actions for CI/CD

Instead of manually running tests and building Docker images, you can set up GitHub Actions. This creates a pipeline that automatically runs every time you push code to GitHub.

Here’s what happens:

Tests run automatically → Your app is linted, tested, and security-checked.
Docker image builds automatically → When changes are pushed to main, GitHub builds and pushes your Docker image to GitHub’s container registry (GHCR).

This ensures your app is always tested and ready to deploy without extra manual steps.

Fixed GitHub Actions CI/CD

What this step does:

Sets up an automated workflow that runs tests and builds Docker images every time you push to GitHub.

1. Create Workflow Directory

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

2. Create CI/CD Pipeline File

# Create the workflow file
touch .github/workflows/ci.yml

Copy this into .github/workflows/ci.yml:

name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

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

jobs:
  test:
    name: Run Tests
    runs-on: ubuntu-latest

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

    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: npx eslint . --ext .js --ignore-pattern node_modules/
        continue-on-error: true

      - name: Run tests
        run: npm test

      - name: Run security audit
        run: npm audit --audit-level=moderate || true

  build:
    name: Build Docker Image
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

    permissions:
      contents: read
      packages: write

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

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - 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=sha,prefix={{branch}}-
            type=raw,value=latest,enable={{is_default_branch}}

      - name: Build and push Docker image
        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

Step 5: Create a Dockerfile

A Dockerfile is like a recipe that tells Docker how to build a container image for your app. With this, you can run your app anywhere on your laptop, a server, or in the cloud.

Here’s what this Dockerfile does:

Uses a multi-stage build so the final image is small and efficient
Installs curl for health checks
Runs the app as a non-root user for better security
Configures health checks to make sure the app is running
Ensures proper file permissions and clean setup

Creating a Dockerfile

What this step does:

Defines instructions for Docker to build a portable container image of your Node.js application.

1. Create Dockerfile

# Create the Dockerfile (no extension needed)
touch Dockerfile

2. Add Dockerfile Content

Copy the code below into your Dockerfile:

# Fixed and Verified 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"]

Step 6: Essential Configuration Files

Configuration files are like “rules” for your project. They tell tools what to ignore, how to check your code, and what settings to use. Adding these makes your project easier to maintain and safer to share with others.

Here’s what we will add:

.dockerignore → tells Docker which files to skip when building the container.
.gitignore → tells Git which files not to track.
.env.example → shows what environment variables the project needs (without secrets).
.eslintrc.js → sets up ESLint to keep your code clean and consistent.

Essential Configuration Files

What this step does:

Adds important project config files to ignore unnecessary stuff, define environment settings, and enforce clean coding standards.

1. Create `.dockerignore`

Tells Docker which files/folders to ignore when building images.

touch .dockerignore

Copy this inside .dockerignore:

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*

2. Create `.gitignore`

Tells Git which files not to track in version control, by running the code below:

touch .gitignore

Copy the code inside .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

3. Create .env.example

Shows other developers what environment variables your application needs, without exposing actual secrets.

touch .env.example

Copy this inside:

# Server Configuration
PORT=3000
NODE_ENV=production

# Logging
LOG_LEVEL=info

4. Create .eslintrc.js

Configures ESLint to check code quality and style.

touch .eslintrc.js

Copy the code inside:

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

Docker Compose is like a shortcut remote control for your app. Instead of typing long docker commands, you define everything in one file, and then just run:

docker-compose up

This makes development faster and keeps things consistent for every developer on the project.

Docker Compose for Development

What this step does:

Creates a docker-compose.yml file that makes it easy to run your app (and later, databases) with just one command.

1. Create Docker Compose file

touch docker-compose.yml

2. Copy and paste the following code:

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

What this does:

Defines your app as a service
Maps port 3000 → so you can visit http://localhost:3000 in your browser
Sets environment variables → tells the app to run in development mode
Adds a health check → ensures the app is running properly
Auto restarts → if the app crashes, Docker brings it back up

Step 8: Commands to Run Everything

Now that your app, tests, Dockerfile, and CI/CD are ready, it’s time to run it locally and make sure everything works:

Install and test with npm → Installs dependencies, runs your automated tests, and starts the app.
Run with Docker → Build a Docker image and run it in an isolated container.
Run with Docker Compose → Start the app (and other services) together easily.

After this step, your app should be fully functional at http://localhost:3000.

Commands to Run Everything

What this step does:

Shows how to run and test your Node.js application locally before deploying it.

1. Install and Test Locally

Install dependencies

npm install

Run tests

npm test

Start application

npm start

### In a new terminal, test endpoints
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

Expected results:

Tests pass (green checkmarks)
Server logs: 🚀 Server running at http://localhost:3000/
Health endpoint returns JSON: {"status":"healthy","timestamp":"...","uptime":...}

2. Docker Commands

What these commands do: Build your application into a Docker container and run it in an isolated environment.

How to run Docker commands:

Build Docker 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 and remove container
docker stop my-devops-container

docker rm my-devops-container

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

View logs from all services
docker-compose logs -f

Stop all services and clean up
docker-compose down

Expected results:

Containers build and start automatically
Logs show your application initializing
Application accessible at http://localhost:3000

Step 9: CI/CD with Deployment

What this step does:
Pushes your local project to GitHub so the CI/CD pipeline (from Step 4) can automatically run tests, build Docker images, and deploy.

1. Initial Commit

Take a snapshot of your full project and save it in Git history:

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"

What this does: Takes a snapshot of all your files and saves it in Git history and gets your project ready to push.

2. Connect to GitHub

First, create a new repository on GitHub.com
.
Then link your local repo to GitHub:

Set main as the default branch

git branch -M main

Connect to your GitHub repository (replace yourusername with your actual GitHub username)

git remote add origin https://github.com/yourusername/my-devops-project.git

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

Things to know before this step

Create a new repo on GitHub before running these commands
Copy the repo URL from GitHub (HTTPS or SSH)
Replace yourusername with your actual GitHub username

What You will See:

Your project files appear in your GitHub repository
GitHub Actions automatically triggers the CI/CD pipeline you configured earlier
Tests, linting, security checks, and Docker builds all run in the cloud 🚀

This is where everything comes alive:
👉 Code → GitHub → Automated CI/CD → Ready for deployment

10. Step 10: Continuous Deployment (CD) Setup

What this step does:
Extends your CI pipeline to automatically deploy your application to staging and production environments when code is pushed.

⚡ Enhanced CI/CD Pipeline with Deployment
This enhanced pipeline will:

✅ Run tests on multiple Node.js versions
🐳 Build Docker images for multiple platforms (AMD64 + ARM64)
🚀 Deploy to staging when pushing to develop branch
🎯 Deploy to production when pushing to main branch
🔒 Run security scans on production deployments

🛠 Update Your GitHub Actions Workflow

Open .github/workflows/ci.yml and replace it with this:

name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

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

jobs:
  test:
    name: Run Tests
    runs-on: ubuntu-latest

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

    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: npx eslint . --ext .js --ignore-pattern node_modules/
        continue-on-error: true

      - name: Run tests
        run: npm test

      - name: Run security audit
        run: npm audit --audit-level=moderate || true

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

    permissions:
      contents: read
      packages: write

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

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

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - 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=sha,prefix={{branch}}-
            type=raw,value=latest,enable={{is_default_branch}}

      - 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

  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 "Would deploy to staging server here"
          # In real scenario, you'd use:
          # - kubectl apply -f k8s/staging/
          # - docker-compose -f docker-compose.staging.yml up -d
          # - ssh staging-server "docker pull $IMAGE && docker-compose up -d"

  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 "Image digest: ${{ needs.build.outputs.image-digest }}"
          echo "Would deploy to production server here"
          # In real scenario, you'd use:
          # - kubectl apply -f k8s/production/
          # - terraform apply
          # - ansible-playbook deploy.yml

  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: 'ghcr.io/kosinachi/getting-started-with-devops:latest'
          format: 'sarif'
          output: 'trivy-results.sarif'

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

    env:
      TRIVY_USERNAME: ${{ github.actor }}
      TRIVY_PASSWORD: ${{ secrets.GITHUB_TOKEN }}

Commit and push your workflow:

`git add .github/workflows/ci.yml`
`git commit -m "Enhance CI/CD pipeline with staging and production deployment"`
`git push origin main`

☸️ Kubernetes Deployment Configurations

We will now define how the app should run in staging and production.
📦 Staging Deployment

mkdir -p k8s/staging

touch k8s/staging/deployment.yml

Copy this content into k8s/staging/deployment.yml:

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/yourusername/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

🏭 Production Deployment

mkdir -p k8s/production
touch k8s/production/deployment.yml

Copy this content into k8s/production/deployment.yml:

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/yourusername/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

What You will Get

Push to develop → Staging deployed
Push to main → Production deployed
Automated Docker builds, tests, and security scans
Kubernetes-powered scalability with replicas, probes, and resource limits

👉 At this point, ywe have got a full DevOps pipeline from code → CI → Docker → Kubernetes → CD.

Step 11: Complete Deployment Workflow

What this step does:
Shows you how to use the full CI/CD pipeline with a proper branching strategy for staging and production deployments.

Branch-based Deployment Strategy

Here’s how the flow works:

develop branch → 🚀 Automatically deploys to staging
main branch → 🎯 Automatically deploys to production
Pull Requests → ✅ Run tests only (no deployment)

This ensures safe testing in staging before releasing to production.

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 runs tests ✅
If successful, your app is deployed to staging automatically

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 tests + build + security scan
If successful, your app is deployed to production

📊 Monitor Deployments

Check whether everything is working as expected:

🟢 GitHub Actions status: 👉 Your Actions page or:

### Check GitHub Actions status
### Visit: https://github.com/yourusername/my-devops-project/actions

📦 Container registry: 👉 Your Docker images or:

### Check your container registry
### Visit: `https://github.com/yourusername/my-devops project/pkgs/container/my-devops-project`

🧪 Test live endpoints:

Staging health check

curl https://your-staging-url.com/health

Production health check

curl https://your-production-url.com/health

✅ Expected response:

{ "status": "healthy", "timestamp": "...", "uptime": ... }

🎉 At this point.

We have set up a complete DevOps environment:

Local development 🖥
Containerization 🐳
CI/CD pipelines ⚙️
Branch-based deployments 🌿
Kubernetes for staging & production ☸️
This is a production-grade workflow you can scale for real projects.

Conclusion & Best Practices

Congratulations! we have just built a complete DevOps pipeline, from coding locally all the way to automated staging and production deployments.

This setup covers:

Local development with Node.js + Docker
Automated testing (Jest + Supertest)
GitHub Actions CI/CD pipeline
Secure Dockerfile and configs
Kubernetes staging & production deployments
Branch-based workflow (develop → staging, main → production)

Best Practices to Keep in Mind

1. Keep CI/CD Fast

Cache dependencies
Run tests in parallel
Fail fast on errors

2. Automate Security

Use npm audit, Trivy, or Dependabot
Regularly update dependencies

3. Protect Secrets

Store secrets in GitHub Actions Secrets 🔑
Never commit .env files to Git

4. Monitor Everything

Use /health and /metrics endpoints
Connect to monitoring tools (Prometheus, Grafana, etc.)

5. Use Branching Wisely

develop → Safe place for testing
main → Only stable, production-ready code

Final Thoughts

This workflow gives you a real-world DevOps setup that’s:

Scalable – ready for growth
Secure – avoids common pitfalls
Automated – less manual work, more focus on coding

From here, you can expand further by:

Adding Terraform for infrastructure-as-code
Integrating Helm charts for Kubernetes
Setting up CDNs & load balancers for global scalability

You now have all the building blocks to manage modern applications like a DevOps pro!

Exercise 4 – Configure Security Settings in Active Directory

Kosisochukwu Ugochukwu — Sun, 24 Aug 2025 00:45:16 +0000

INTRODUCTION

In this exercise, you will configure security settings in Active Directory that help protect your organization from outdated authentication methods, unauthorized changes, and improper account usage.

Imagine you are the IT administrator responsible for keeping your company’s network safe. Just like you wouldn’t give everyone a master key to the office or allow old locks to stay on the doors, you need to make sure your digital environment is secure.

Here’s what you will do in this exercise:

Restrict NTLM authentication for the domain: NTLM is an older authentication method that is less secure and more vulnerable to attacks. By blocking it, you ensure that only stronger authentication methods (like Kerberos) are used in your domain.
Enable auditing of user account management in the Sydney OU: This allows you to track when user accounts are created, modified, or deleted in the Sydney office. It’s like having a security camera that records who made changes, helping you detect mistakes or suspicious activity.
Deny log on as a service to members of a security group: Some accounts should never be used to run background services, because if they are compromised, attackers could gain persistent access. By denying this right to certain groups, you reduce risk and enforce proper security practices.

By the end of this exercise, you will understand how to apply practical security policies that help protect user accounts, monitor administrative activity, and prevent risky account usage. These are common tasks IT administrators perform to keep systems compliant and safe from threats.

Part 1 – Restrict NTLM Authentication

Here you will block NTLM authentication across the domain.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Group Policy Management.

In Group Policy Management:

Expand forest: tailwindtraders.internal → Domains → tailwindtraders.internal → Group Policy Objects.

Right-click Default Domain Controller Policy → choose Edit.

In the Group Policy Management Editor:

Go to:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.

Find and double-click:
Network security: Restrict NTLM: NTLM authentication in this domain.

Check Define this policy setting.

Select Deny all → click OK.

When prompted, click Yes to confirm the change.

Close the Group Policy Management Editor.

Part 2 – Audit User Account Management in the Sydney OU

This sets up auditing so you can track changes made to accounts in the Sydney OU.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Group Policy Management.

In Group Policy Management:

Expand tailwindtraders.internal.

Right-click the Sydney OU → select Create a GPO in this domain, and Link it here….

Name the new policy SydneyOUPolicy → click OK.

Right-click SydneyOUPolicy → select Edit.

In the Group Policy Management Editor:

Go to:
Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Account Management.

Double-click Audit User account management.

Check Configure the following audit events.

Select both Success and Failure → click OK.

Close the Group Policy Management Editor.

Part 3 – Deny Log On As a Service

Here you will prevent members of the Sydney Administrators group from logging on as a service.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Group Policy Management.

Expand the tailwindtraders.internal domain.

Right-click SydneyOUPolicy (created earlier) → select Edit.

In the Group Policy Management Editor:

Go to:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment.

Double-click Deny log on as a service.

Check Define this policy setting.

Click Add User or Group.

In the Select Users or Groups window:

Click Browse → Advanced → Find Now.

Select the Sydney Administrators group.

Click OK repeatedly until all windows close (about 4–5 confirmations).

Conclusion

In this exercise, you learned how to configure security settings to protect systems and user accounts from potential threats. By applying these configurations, you strengthened overall system security and ensured that users operate within a safe and controlled environment.

Exercise 3 – Configure Group Policy for Password Policies

Kosisochukwu Ugochukwu — Sun, 24 Aug 2025 00:38:25 +0000

INTRODUCTION

In this exercise, you will practice configuring important security and recovery features in Active Directory. These settings make sure that your organization’s accounts are protected and that administrators can recover objects if they’re deleted by mistake.

Here’s the scenario: You are the IT administrator of a company that uses Active Directory to manage all its users and computers. To keep the company secure, you need to ensure that:

All users follow a standard password policy (for example, requiring a minimum length and complexity). This helps protect against simple or weak passwords that hackers could guess.
Domain Administrators, who have the highest level of access, must follow an even stricter password policy because if their accounts are compromised, the entire company is at risk.
If someone accidentally deletes an important account, group, or even a whole Organizational Unit (OU), you can use the Active Directory Recycle Bin to quickly restore it without starting from scratch.

By completing this exercise, you will learn how to:

Apply a domain-wide password policy that affects every account in the system.
Create a fine-grained password policy that gives tighter security rules just to sensitive groups (like Domain Admins).
Enable the Recycle Bin, a critical safety net that protects against accidental deletions and makes recovery much easier.

These are common tasks that IT administrators perform to balance security and usability, while also preparing for mistakes that happen in real-world environments.

Part 1 – Configure Domain Password Policy

This sets the basic password rules for the entire domain.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Group Policy Management.

In the Group Policy Management console:

Expand forest: tailwindtraders.internal → Domains → tailwindtraders.internal.

Right-click Default Domain Policy → choose Edit.

In the Group Policy Management Editor:

Go to:
Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy.

Double-click Minimum password length.

Change the value to 14 characters and click OK.

Close the Group Policy Management Editor and then close Group Policy Management.

Part 2 – Configure Fine-Grained Password Policy

This creates a stricter password rule for the Domain Admins group only.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Active Directory Administrative Center.

In the left pane, click Tailwindtraders (local).

In the middle pane, open the System container.

Inside System, open the Password Settings Container.

Right-click Password Settings Container → choose New → Password Settings.

In the new settings window:

Name: Domain Admin Password Policy

Precedence: 1

Minimum password length: 16 characters

Click OK.

Open the newly created policy (Domain Admin Password Policy).

In the Directly Applies To section: Click Add.

Type Domain Admins.

Click Check Names → OK → OK.

Part 3 – Enable Active Directory Recycle Bin

This allows you to recover accidentally deleted AD objects (like users or OUs).

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Active Directory Administrative Center.

In the left pane, click Tailwindtraders (local).

In the right pane, select Enable Recycle Bin.

When a warning appears → click OK.

Another warning will appear about replication latency → click OK again.

Conclusion

In this exercise, we successfully configured Group Policy for password policies, ensuring stronger protection of user accounts by enforcing rules such as password length, complexity, and expiration. These settings help maintain security across the system by reducing the risk of weak or compromised passwords.

In the next exercise, we will build on this foundation by learning how to configure security settings, which will allow us to further strengthen and customize the overall security of the system environment.

Exercise 2 – User Management in Active Directory

Kosisochukwu Ugochukwu — Sun, 24 Aug 2025 00:32:58 +0000

INTRODUCTION

In this exercise, you will practice user management tasks in Active Directory. Think of Active Directory as a big digital phone book and security system for a company. It helps organize people, computers, and resources like printers into one central place, making it easier for administrators to manage everything.

Imagine you are the IT administrator for a company with offices in Sydney, Melbourne, and Brisbane. Each office has its own staff, and you want to make sure that:

Users are placed into the right Organizational Units (OUs) so they are grouped by location.
Contractors and employees have their own user accounts with the right passwords and expiration dates.
Special teams like Sydney Administrators have extra permissions to help manage accounts without giving them full control of everything.
You can add users into groups so permissions can be given to a whole team at once rather than one person at a time.
You can apply security features like Protected Users, which add extra protection to sensitive accounts.
If something goes wrong, you can still audit, disable, or reset accounts when needed.

By the end of this exercise, you will be simulating what an IT admin would actually do in a real company:

Setting up OUs for different branches of the business.
Creating user accounts for contractors and assigning them to the right office.
Creating a group for administrators in Sydney and giving them delegated permissions.
Securing accounts by applying restrictions and ensuring compliance with company security policies.
Performing everyday tasks like disabling an account when a contractor leaves or resetting a forgotten password.
This hands-on scenario will help you understand not just how to do these steps in Active Directory, but also why they are important in managing users and keeping an organization secure and well-organized.

Part 1 – Create Organizational Units (OUs)

Here we create three new OUs: Sydney, Melbourne, and Brisbane.

Steps:

On TAILWIND-DC1, open Server Manager.
From the Tools menu, select Active Directory Users and Computers.

In the left panel, right-click on the tailwindtraders.internal domain.

Select New → Organizational Unit.

In the dialog box, type Sydney as the name and click OK.

Repeat the same steps to create two more OUs: Melbourne and Brisbane.

Part 2 – Create Users

You will now create three contractor accounts (one for each city) and set properties for them.

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

Right-click the Sydney OU → select New → User.

Fill in:

Full Name: SydneyContractor

User Logon Name: SydneyContractor

Click Next.

Set the password: Pa55w.rdPa55w and confirm it.

Click Next → Finish.

Open the Sydney OU, double-click SydneyContractor.

On the Account tab → under Account expires, select End of: and set the date to Jan 1, 2030 → click OK.

Now, copy the SydneyContractor account:

Right-click SydneyContractor → select Copy.

Type:

Full Name: MelbourneContractor

User Logon Name: MelbourneContractor

Click Next.

Use the password: Pa55w.rdPa55w.rd.

Click Next → Finish.

Repeat the copy process again to create:

Full Name: BrisbaneContractor

User Logon Name: BrisbaneContractor

Password: Pa55w.rdPa55w.rd.

Move users to their correct OUs:

Drag MelbourneContractor into the Melbourne OU.

If a warning pops up → click Yes.

Drag BrisbaneContractor into the Brisbane OU.

If a warning pops up → click Yes.

Part 3 – Create the Sydney Admins Group

You will now create a security group and add a user to it.

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

Right-click the Sydney OU → select New → Group.

Type Sydney Administrators as the group name.

Set Group scope to Universal.

Click OK.

In the Sydney OU, double-click SydneyContractor.

Go to the Member Of tab → click Add.

Type Sydney Administrators.

Click Check Names → OK → OK.

Part 4 – Configure a User as a Protected User

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

In the Sydney OU, double-click SydneyContractor.

Go to the Member Of tab → click Add.

Type Protected Users.

Click Check Names → OK → OK.

Part 5 – Delegate Security Permissions to an OU

You will allow the Sydney Administrators group to reset passwords for accounts in the Sydney OU.

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

Right-click the Sydney OU → select Delegate Control.

In the wizard:

On the Welcome page → click Next.

Click Add, type Sydney Administrators, then click Check Names → OK → Next.

On the Tasks to Delegate page → select Reset user passwords and force password change at next logon.

Click Next → Finish.

Part 6 – Configure City Attribute for a User

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

In the Sydney OU, right-click SydneyContractor → select Properties.

In the Address tab, set City to Sydney → click OK.

To confirm:

Right-click the tailwindtraders.internal domain → select Find.

In the Advanced tab, select:

Field → User → City

Condition: Is (exactly)

Value: Sydney

Click Find Now.

Click Yes when asked about searching the directory.

Make sure SydneyContractor shows up in the results.

Close the window.

Part 7 – Disable the Melbourne Contractor User

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

Open the Melbourne OU.

Right-click MelbourneContractor → select Disable Account.

Click OK.

Part 8 – Reset the Password of the Brisbane Contractor User

Steps:

On TAILWIND-DC1, open Active Directory Users and Computers.

Open the Brisbane OU.

Right-click BrisbaneContractor → select Reset Password.

Enter the new password: Pa66w.rdPa66w
twice.

Click OK → then OK again on the confirmation dialog.

Conclusion
In this exercise, you explored how to manage users within Active Directory, including creating, modifying, and organizing user accounts. These skills are essential for ensuring proper access control and maintaining an organized directory structure in a networked environment.

Now, we will move forward to the next Exercise – Configure Security Settings, where we will focus on strengthening system protection through security configurations. Following that, we will continue with Exercise – Manage Password Policies, which will further enhance account security by enforcing strong authentication practices.

Exercise 1 – Configure Domain Controller Operations

Kosisochukwu Ugochukwu — Sun, 24 Aug 2025 00:16:54 +0000

INTRODUCTION

In this exercise, you will practice some of the core administrative tasks in Active Directory related to setting up and organizing a company’s domain environment.

Imagine you are the IT administrator for a growing business that is expanding into new locations. To support this growth, you need to ensure that your Active Directory environment is structured, reliable, and ready to handle users and resources across multiple offices.

Here’s what you will do in this exercise:

Turn a regular server into a Domain Controller: A Domain Controller (DC) is the “brain” of Active Directory, it stores the user accounts, manages authentication, and applies security rules across the network. Promoting a server to a DC makes it part of this central system.
Move a special control role (FSMO role) to the new Domain Controller: Flexible Single Master Operations (FSMO) roles are like “special duties” in the domain that only one DC can handle at a time. You will transfer one of these roles to the new DC to balance the workload and improve reliability.
Create a new site: Sites in Active Directory represent physical locations, such as different office branches. By creating a site, you help AD understand the company’s network structure, which improves performance and replication efficiency.
Add a subnet to the site: Subnets tell Active Directory which IP address ranges belong to which physical location. By linking a subnet to a site, you ensure that users in that office connect to the right Domain Controller.

By completing this exercise, you will learn how IT administrators prepare an Active Directory environment for growth, distribute responsibilities across servers, and organize the network to reflect the company’s real-world locations.

Part 1 – Install Active Directory Domain Services (AD DS) and Promote to Domain Controller

In this part, you will make the server TAILWIND-MBR1 a Domain Controller for the TAILWINDTRADERS domain.

Steps:

Sign in to TAILWIND-MBR1 as:
Username: TAILWINDTRADERS\Administrator
Password: Pa55w.rdPa55w or password of your choice you used

In Server Manager, click Manage in the top-right menu and choose Add Roles and Features.

In the Add Roles and Features wizard:

On the Before you begin page → click Next.

On Select installation type → choose Role-based or feature-based installation → click Next.

On Select destination server → make sure TAILWIND-MBR1 is selected → click Next.

On Select server roles → tick Active Directory Domain Services.

A box pops up → click Add Features.

Click Next.

On Select features → click Next.

On Active Directory Domain Services info page → click Next.

On Confirm installation selections → click Install.

This may take a few minutes.

When done → click Close.

In Server Manager, click the notification flag icon in the top-right corner.
From the notification menu, click Promote this server to a domain controller.
This opens the Active Directory Domain Services Configuration Wizard.

In the wizard:

On Deployment Configuration → choose Add a domain controller to an existing domain. Make sure the domain is tailwindtraders.internal.

You will need to log in again:

Click Change.
Username: Administrator

Password: Pa55w.rdPa55w.rd

Click OK → Next.

On Domain Controller options:

Keep the defaults.

For the Directory Services Restore Mode (DSRM) password, type Pa55w.rdPa55w.rd twice.

Click Next.

On DNS Options → click Next.

On Additional Options → click Next.

On Paths → click Next.

On Review Options → click Next.

On Prerequisites Check → click Install.

This can take a few minutes, and the server will restart automatically.

When it restarts, log back in as:
Username: tailwindtraders\administrator
Password: Pa55w.rdPa55w.

Part 2 – Transfer Flexible Single Master Operations (FSMO) Role

Here you will move the RID Master role from the old Domain Controller (TAILWIND-DC1) to the new one (TAILWIND-MBR1).

Steps:

On TAILWIND-MBR1, open Server Manager.
Go to Tools → Active Directory Users and Computers.

In the left panel, right-click "Active Directory Users and Computers".
Go to All Tasks → Operations Masters.

In the Operations Masters window, on the RID tab:

Click Change.

When asked, click Yes.

Click OK.

Click Close to exit the Operations Masters window.

Part 3 – Create an Active Directory Site and Configure a Subnet

In this part, you will create a new site called Sydney in Active Directory and then set up a subnet for it.

Steps:

On TAILWIND-DC1, sign in as:
Username: tailwindtraders\administrator
Password: Pa55w.rdPa55w.rd

Open Server Manager, go to Tools, and select Active Directory Sites and Services.

In the left panel, right-click Sites → choose New Site.

Type Sydney as the site name.For the Link Name, choose DEFAULTIPSITELINK.

Click OK twice.

Expand the Sites folder, Right-click Subnets → choose New Subnet.

For Prefix, type: 172.16.1.0/24

For the Site name, select Sydney.

Click OK.

Close Active Directory Sites and Services.

Conclusion

In this exercise, you successfully promoted a server to a Domain Controller, transferred a FSMO role, and set up a new site with its subnet. These steps are essential for building a strong and organized Active Directory foundation that supports growth and reliability across different locations.

Now that the domain structure is in place, let’s move on to the next exercise: Configure User Management Operations, where you will learn how to create Organizational Units, users, and groups to start managing people within the domain.

From Setup to Management: Administering Active Directory Domain Services Like a Pro

Kosisochukwu Ugochukwu — Sun, 24 Aug 2025 00:00:28 +0000

Introduction

In this guided project, you will learn how to set up and manage Active Directory Domain Services, which is one of the most important parts of a Windows Server environment.

What is Active Directory?

Think of it as a big phonebook for your company’s computers and users. It helps you control who can access what, keeps your systems organized, and makes it easier to manage everything from one place.

If you have ever worked in a company where you log into a computer with your work email or user ID, chances are you were using Active Directory behind the scenes.

In this step-by-step guide, we will walk through the basics of:

Preparing the environment and installing Install Hyper-V
Setting up a domain
Configure domain controller operations
Configure user management operations
Manage password policies
Configure security settings

You don’t need to be an expert, just follow along, and by the end of this project, you will have your own mini Active Directory environment up and running.

Let’s get started!

Getting Set Up for the Project

This project is hands-on and guided — meaning you'll follow step-by-step tasks to build and manage a domain controller. Each step builds on the previous one, so it’s important to complete them in order.

What’s This Project About?

You will go through the full process of:

Creating a domain controller
Configuring its settings
Keeping it up and running
Promoting it (giving it the authority to manage users and security)

All without needing a paid Microsoft Azure account or dedicated server hardware.

What You will Need

To keep things budget-friendly and simple, everything runs virtually on your existing Windows 10 or 11 machine, but it must be the Pro or Enterprise edition, because only those support virtualization with Hyper-V.

Here’s the basic setup:

Use Hyper-V (a built-in virtualization feature in Windows Pro/Enterprise)
Create two virtual machines running Windows Server 2022 Evaluation Edition
Your PC should have at least 16 GB RAM,but 8GB is still welcomed
Optionally, you can use Windows Server with Hyper-V, or even a third-party virtualization tool if you prefer

Note: This guide uses Windows 10 pro in its examples.

You will be doing three key things in the setup phase:

Install Hyper-V
Create a virtual machine for the Domain Controller
Create a second VM as a Member Server

Once you're done with setup, return here to continue the rest of the project. Let's get building!

Install Hyper-V

In this task, you install Hyper-V and configure a NAT switch. You configure Hyper-V to use a different set of default directories to store virtual machine files and hard disks. You can use the options presented in these instructions or choose your own location.

Sign in to the Windows computer with an account that has local Administrator privileges.
On the Windows Computer click on search box, then search for Turn ON and OFF manage feature.
On the System page of Settings, scroll down until you locate Turn windows Features off and On.
On the Optional Features page, scroll down until you locate More Windows Features under Related Settings.
On the Windows Feature page, select the checkbox next to Hyper-V and click OK as shown in the exhibit.

Finalize Hyper-V Setup & Customize Storage Paths
Once Hyper-V is installed, you will need to restart your computer and finish the setup by adjusting where your virtual machines and virtual hard disks (VHDs) are stored.

After Installation
After the Hyper-V installation completes, click Restart Now when prompted

Once your PC restarts, sign back in with your Administrator account

Set Up Hyper-V Manager
Click Start and search for Hyper-V Manager

When it appears, right-click it and pin it to your Taskbar for easy access

Open Hyper-V Manager

In the left pane, right-click your computer name and select Hyper-V Settings

Customize Virtual Machine Storage
Inside the Hyper-V Settings window:

Under the Server section, click on Virtual Machines
Change the default location to: C:\VirtualMachines

Next, click on Virtual Hard Disks
Change the location to: C:\VirtualMachines\VHDs
Click OK to save your settings and close the window.

This custom setup helps you stay organized and makes it easier to clean up or move your VMs later on.

Set Up a NAT Network for Your Virtual Machines

Now that Hyper-V is ready, it’s time to create a NAT (Network Address Translation) network.

What this does?

This lets your virtual machines connect to the internet through your host machine, just like how your home Wi-Fi router works.

Using PowerShell

Open PowerShell as an Administrator:

Click Start, search for PowerShell

Right-click it and choose Run as administrator

Run the following commands to create a NAT network (copy and paste each line one at a time):
First command Run: New-VMSwitch -SwitchName “NATSwitch” -SwitchType Internal

Second command Run: New-NetIPAddress -IPAddress 10.10.10.1 -PrefixLength 24 -InterfaceAlias “vEthernet (NATSwitch)”

Third command Run: New-NetNat -Name “NATNetwork” –InternalIPInterfaceAddressPrefix “10.10.10.0/24”

Create Windows Server Domain Controller Virtual Machine

Next up, is deploying a Windows Server 2022 Domain Controller we will set up the heart of your lab: a Windows Server 2022 Domain Controller. This is the server that will manage your domain like user logins, security settings, and more.

Download the ISO File
To get started, download the Windows Server 2022 Evaluation Edition ISO from Microsoft:

Download from Microsoft 👉 https://www.microsoft.com/en-us/evalcenter/download-windows-server-2022
After download save the file in a folder called C:\ISOs on your machine

This ISO gives you access to the full version of Windows Server 2022 free to use for 180 days

Why use the Evaluation Edition? It’s perfect for learning, testing, and lab environments like this one — no license required upfront.

Create the Domain Controller Virtual Machine (TAILWIND-DC1)

Now it's time to spin up your first virtual machine: This one will act as your Domain Controller, the central brain of your lab environment.

Here’s how to do it using Hyper-V Manager:

Step-by-Step: Create the VM

Open Hyper-V Manager
In the Actions panel (on the right), click New > Virtual Machine

In the wizard that opens:
Click Next on the Before You Begin page

On the Name and Location page:
Set the name to TAILWIND-DC1
Click Next

On the Generation page, select Generation 2, then Next

On the Memory page:
Set Startup Memory to according to memory availiable for you to assign but not less than 2000 mb
Keep "Use Dynamic Memory" checked
Click Next

On the Networking page:
Choose NATSwitch from the dropdown menu
Click Next

On the Virtual Hard Disk page:
Accept the default settings and click Next

On the Installation Options page:
Select "Install an operating system from a bootable image file"
Click Browse and choose the Windows Server 2022 Evaluation ISO located in C:\ISOs (usually named SERVER_EVAL_x64FRE_en-us.iso)
Click Next

On the Summary page, click Finish

Disable Automatic Checkpoints
Once the VM is created:

In Hyper-V Manager, right-click TAILWIND-DC1 and choose Settings

Under Management, select Checkpoints

Make sure "Use automatic checkpoints" is unchecked

Click OK to save

🔒 Why disable automatic checkpoints? It keeps things cleaner and prevents Hyper-V from creating snapshot-style backups that could eat up disk space during testing.

Boot Up and Begin Installing Windows Server 2022
Now that your virtual machine (TAILWIND-DC1) is created, it’s time to install Windows Server 2022 from the ISO file you attached earlier.

Start the VM and Begin Installation

In Hyper-V Manager, double-click TAILWIND-DC1 to open the Virtual Machine Connection window

Click Start (the green button on the toolbar) to power on the VM

Quickly watch for the message:
"Press any key to boot from CD or DVD..."

When you see it, click inside the VM window to focus, then press the tab key to highlight Restart Now and make it clickable

This tells the VM to boot from the ISO file you selected earlier

Begin Windows Server Setup
On the Microsoft Server Operating System Setup screen:

Leave all default settings as-is and click Next

On the next screen, click Install now

When asked to choose an edition: Select Windows Server 2022 Standard Evaluation (Desktop Experience) and Click Next

🪟 "Desktop Experience" gives you the full Windows GUI, ideal for hands-on learning and managing the server more easily.

Install Windows Server 2022 and Promote It to a Domain Controller

Now that your VM is ready and the ISO is mounted, it’s time to install Windows Server 2022 and turn it into a fully functional Domain Controller.

Finish Installing Windows Server
On the license terms screen, check “I Accept” and click Next

When asked about the type of installation, choose Custom

On the disk selection screen, pick Drive 0 and click Next

The OS will install and reboot, this may take several minutes

Then click on connect

When prompted to set the Administrator password, enter:Password1
(Use your own if you prefer, but this demo password works for the lab.)

After setup completes, log in with the Administrator account using the password above.

Set Static IP for the VM

On the VM, right-click the network icon (a globe) in the taskbar → choose Open Network & Internet Settings

Click Change adapter options

Right-click Ethernet → select Properties

Double-click Internet Protocol Version 4 (TCP/IPv4)

Enter the following static IP settings:

IP Address: 10.10.10.10 Subnet Mask: 255.255.255.0 Default Gateway: 10.10.10.1 DNS (Preferred): 1.1.1.1 DNS (Alternate): 8.8.8.8

Click OK, then Close. When prompted to allow network discovery, choose Yes

Rename the Server
Open Server Manager → click Local Server

Next to Computer Name, click the name to open System Properties

Click Change, then set the name to:

TAILWIND-DC1
Click OK and Restart Now when prompted

Log back in as Administrator

Install Active Directory Domain Services (AD DS)

In Server Manager, go to Manage → Add Roles and Features

Click Next through the following screens:

Before you begin

Select installation type → choose Role-based or feature-based

Select destination server → ensure TAILWIND-DC1 is selected

On Select server roles:

Check Active Directory Domain Services

Click Add Features when prompted

Click Next until you reach the Confirmation page

Click Install

This may take a few minutes.

To promote the Server to a Domain Controller:
In Server Manager, click the flag icon in the top-right corner

Click Promote this server to a domain controller

In the wizard:

On Deployment Configuration, choose Add a new forest

Set the root domain name to: tailwindtraders.internal

On Domain Controller Options, leave defaults, but enter this DSRM password twice:Password1

Click Next through the DNS, Additional Options, and Paths screens

On Review Options, click Next

On Prerequisites Check, click Install

The server will restart automatically when done.

Final Login
After the restart, log in using your new domain credentials:

Username: tailwindtraders\administrator

Password: Password1

You now have a working Active Directory Domain Controller running in a virtual environment, all from a Windows 11 machine.

Create Windows Server Domain Member Server

Create Virtual Machine (TAILWIND-MBR1) in Hyper-V Open Hyper-V Manager > Actions > New > Virtual Machine

On before you begin page click next

Name: TAILWIND-MBR1 click next

Generation: 2 click next

Memory: 4096 MB (Dynamic Memory enabled) choose any memory of your choice and click next

Networking: NATSwitch and click next

Virtual Hard Disk: Accept defaults

Install an OS from a bootable image file click on browse look for*ISO*:File: C:\ISOs\SERVER_EVAL_x64FRE_en-us.iso

Click on finish

2. Configure VM Settings

Right-click VM > Settings > Management > Checkpoints

Uncheck: Use automatic checkpoints

3. Install Windows Server

Double tap on TAILWIND-MBR1 → Start VM → Press any key to boot from ISO

Accept default language/keyboard settings > Next > Install now

Select version: Windows Server 2022 Standard Evaluation (Desktop Experience)

Accept license terms

Choose: Custom installation and Select Drive 0 > Click Next

Wait for OS installation to complete

4. Set Administrator Password

Use password: Pa55w.rdPa55w.rd or choose any password of your choice

Configure Network Settings

Right-click network icon > Open Network & Internet Settings

Click Change adapter options > Right-click Ethernet > Properties

Select Internet Protocol Version 4 (TCP/IPv4) > Properties

Set the following manually:

IP Address: 10.10.10.20

Subnet Mask: 255.255.255.0

Default Gateway: 10.10.10.1

DNS: 10.10.10.10 (Preferred), 8.8.8.8 (Alternate)

Click OK > Close > Select "Yes" when prompted to allow discovery

6. Rename Computer

Open Server Manager > Local Server > Computer Name

Click Change > Rename to: TAILWIND-MBR1

Restart the computer

7. Join Domain

After reboot, log in as Administrator using the password you created

Go to Server Manager > Local Server > Computer Name > Change

Under Member of, choose Domain: TAILWINDTRADERS

Credentials:

Username: TAILWINDTRADERS\Administrator

Password: Pa55w.rdPa55w.rd

Click OK > Confirm domain join > Restart VM

You have now successfully created and configured a Windows Server 2022 domain member server named TAILWIND-MBR1 and joined it to the TAILWINDTRADERS domain.

Getting Started with Kubernetes on Minikube: Deploy, Explore, Expose, Scale, and Update Your App

Kosisochukwu Ugochukwu — Thu, 17 Jul 2025 21:03:38 +0000

INTRODUCTION

What is Kubernetes?
In simple terms Kubernetes is like a traffic controller for your apps.
For example imagine you have a bunch of shipping containers, each with part of your app inside (like a website, a database, an API, etc.). These containers need to run on servers. But managing all of them manually, starting them, stopping them, moving them if something breaks is a pain. So Kubernetes is the system that takes care of all that automatically.

What it does for you:

Starts your app for you.
Keeps it running if something crashes.
Puts it on the best available server.
Then create more copies of it if needed.

Why Use Kubernetes?
Think of Kubernetes like the manager of a busy restaurant kitchen:

You (the app owner) give the manager a recipe (your deployment file).
The manager (Kubernetes) decides how many cooks (containers) to assign.
If one cook burns out (a pod crashes), the manager replaces them automatically.
If a lot of customers show up (high traffic), the manager brings in more cooks (auto-scaling).
If you want to change the recipe (new app version), the manager makes the switch smoothly so customers don’t even notice (rolling updates).

Benefit:
Using Kubernetes means you can spend less time fixing broken stuff and more time building your app. It handles the boring, repetitive parts of running apps in production.

Things you need to get you started is:
Docker installed, basic CLI knowledge, Minikube or similar kind setup, etc.

Module 1 - Create a Kubernetes Cluster

In this module, we will set up a local Kubernetes cluster for development purposes using Minikube. This allows you to run and test Kubernetes workloads on your own machine without needing a cloud provider.

Step 1 – Start Your Local Kubernetes Cluster

We will begin by launching a local Kubernetes cluster using Minikube. This creates a single node cluster on your machine, which acts like a small, self-contained version of a full Kubernetes setup. It gives you a safe environment to experiment, deploy apps, and learn how Kubernetes works all without needing internet access or a cloud account.

If you haven’t installed Minikube yet, go ahead and install it first at https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Fx86-64%2Fstable%2Fbinary+download#Service. Once that’s done, you can confirm it was installed correctly by running the following command in your terminal: minikube version

Once Minikube is installed, you can start your local Kubernetes cluster by running the following command: minikube start
This command sets up a single-node cluster on your machine, which will act as your personal Kubernetes environment for development and testing.

Good! we now have a running Kubernetes cluster on our machine.
Minikube has created a virtual environment for us and launched a single-node Kubernetes cluster inside it. This environment behaves just like a real Kubernetes setup, letting you deploy and manage applications locally.

Step 2 – Check the Cluster Version

To interact with your Kubernetes cluster, we will use the command-line tool called kubectl. It’s the main way we will manage and communicate with our cluster.

Do not worry we will go deeper into how kubectl works later, but for now, let’s use it to view some basic information about the cluster.

First, check that kubectl is installed and working by running: kubectl version
This command will show the version details for both the client (our machine) and the server (the Kubernetes cluster running in Minikube).

As you can see kubectl is now configured correctly!
When you run kubectl version, you will see two main pieces of information:

Client Version: This is the version of the kubectl tool installed on your machine.
Server Version: This is the version of Kubernetes running on your Minikube cluster (specifically on the master node).

Step 3 – View Cluster Details

Now that our cluster is up and running, let’s take a look at some basic information about it.

You can do this by running the following command: kubectl cluster-info
This command shows important details about your Kubernetes cluster, such as the URL of the Kubernetes control plane (also known as the API server) and other key components running inside the cluster.

It’s a quick way to confirm that your cluster is active and responding to commands.

Throughout this tutorial, we will mainly use the command line to deploy and explore our application.

To see the nodes available in your Kubernetes cluster, run:
kubectl get nodes

This command lists all the nodes that your cluster can use to run applications.
Since we are using Minikube, you’ll see just one node, the local virtual machine Minikube started for us.

As you can see the node's status says Ready, that means it’s healthy and available to run our apps.

Module 2 – Deploying Your First App

In this section, you'll learn how to deploy your first application on Kubernetes using the kubectl command-line tool.

The goal is to get hands-on experience with the basic kubectl commands and understand how to interact with your app once it’s running in the cluster. You will see how easy it is to launch, inspect, and manage applications with just a few commands.

Step 1 – Getting Started with kubectl

To begin working with Kubernetes from the command line, we will use a tool called kubectl.

You can type the following in your terminal to see a list of available commands: kubectl

The typical format of a kubectl command looks like this: kubectl <action> <resource>

action: What you want to do (e.g., create, get, describe)
resource: What you are acting on (e.g., pods, nodes, deployments)

To get more details about any command, you can add the --help flag. For example: kubectl get nodes --help

Check Your Setup
To make sure kubectl is properly set up to talk to your Kubernetes cluster, run: kubectl version

This should show both:

Client Version – the version of kubectl on your machine
Server Version – the version of Kubernetes running in your Minikube cluster

View Your Nodes
Now let’s check the node(s) in the cluster:kubectl get nodes

This command lists the available nodes. Since we are using Minikube, you will only see one node. Kubernetes will use this node to schedule and run your application based on the resources it has available (like CPU and memory).

Step 2 – Deploying Your App

Let’s go ahead and deploy your first application on Kubernetes using the kubectl create deployment command.

This command needs two things:

A name for your deployment.
The image you want to deploy (this is the container that runs your app, include the full repository url for images hosted outside Docker Hub).

Here’s the command: kubectl create deployment kubernetes-bootcamp --image=gcr.io/k8s-minikube/kubernetes-bootcamp:v1

What just happened?

By running that single command, Kubernetes did a lot behind the scenes:

Found a suitable node to run your app (we only have one, so it chose that one).
Started the app inside a container on that node.
Set things up so that if the container crashes or the node fails, Kubernetes will automatically restart or reschedule it.

View Your Deployment
To see the list of active deployments, run: kubectl get deployments

You will see one deployment running, this is your app, and it’s running inside a Docker container managed by Kubernetes.

Step 3 – Viewing Your App Inside the Cluster

By default, applications (called Pods) running in Kubernetes are on a private network. This means:

They can talk to each other inside the cluster.
But they are not accessible from the outside, including your browser or host machine.

When we use kubectl, we are talking to the Kubernetes API server, which acts as a bridge between us and the cluster.

Creating a Temporary Connection (Using a Proxy)
We will explore how to make your app publicly accessible in Module 4, but for now, we can use kubectl proxy to temporarily connect to your app from your local machine.

This proxy:

Lets your terminal access the cluster’s internal API endpoints.
Doesn’t show output while running.
Can be stopped anytime with Control + C.

To keep things organized, it’s best to open a second terminal window or tab, and run: echo -e "Starting Proxy. After starting it will not output a response. Please return to your original terminal window\n"; kubectl proxy

This sets up a connection from your local terminal to the Kubernetes cluster via port 8001

Testing the Proxy with curl
Now that the proxy is running, you can test it by accessing the Kubernetes API.
In your original terminal, run: curl http://localhost:8001/version

Note: The proxy was run in a new tab, and the recent commands were executed in the original tab. The proxy still runs in the second tab, and this allowed our curl command to work using localhost:8001.

⚠️ If this doesn’t work, make sure kubectl proxy is still running in your second terminal tab.

Accessing Your Pod Through the API
Kubernetes gives every Pod a unique endpoint through the API.
To access it, you first need to get your Pod’s name and we will store in the environment variable POD_NAME:

Run this in your original terminal:export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') echo Name of the Pod: $POD_NAME

You can access the Pod through the API by running: curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME

Note on Public Access
Right now, this setup only works through the proxy (on localhost:8001).
If you want your app to be accessible without using a proxy, for example, from a browser or external system then you will need to create a Service, which we will cover in the next module.

Module 3 – Exploring Your App

In this module, you will learn how to inspect and troubleshoot applications running in Kubernetes using a few key kubectl commands:

kubectl get – List resources like pods, services, deployments.
kubectl describe – Show detailed information about a specific resource.
kubectl logs – View the output (logs) from inside a container.
kubectl exec – Run commands inside a running container, like you’re SSH-ing into it.

These tools are essential for debugging and understanding what’s going on inside your cluster when something doesn’t seem right, or when you just want to confirm everything is working correctly.

Step 1 – Check if Your App is Running

To verify that your application is up and running, we will use the kubectl get command to check for existing Pods.

In your terminal, run: kubectl get pods

This command lists all the Pods currently running in your cluster. You should see one Pod, the one created by your deployment in the previous module.

Also you can see a status like saying Running in the output. That means the application is successfully running inside the Pod.

To get a deeper look into what's happening inside your Pod, like what containers it's running, what image it's using, and its configuration you can use the kubectl describe command: kubectl describe pods

This command shows detailed information about your Pod, including:

The container image being used
The Pod's internal IP address
Ports that are exposed
Events related to the Pod’s lifecycle (like when it started or if there were any errors)

The output can be a bit long and may include concepts we haven’t covered yet but don’t worry. As you move through this article, everything will start to make more sense.

Tip: kubectl describe works with many types of Kubernetes resources (like nodes, pods, and deployments) and is meant to be human readable, not used for scripting.

Step 2 – View Your App in the Terminal

As a reminder, Pods in Kubernetes run inside a private network, they are isolated from the outside world. To interact with a Pod directly (for debugging or testing), we need a way to access that internal network.

We will do this by using kubectl proxy, which creates a temporary connection between your local machine and the Kubernetes cluster.

Start the Proxy
Open a second terminal window and run this command: echo -e "Starting Proxy. After starting it will not output a response. Please return to your original terminal window\n"; kubectl proxy

What this command does?

It starts a local proxy server on port 8001.
It runs silently (no output) and stays active until you press Control + C to stop it.

Get the Pod Name
Back in your original terminal, run the following to get the name of your Pod and store it in an environment variable: export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') echo Name of the Pod: $POD_NAME

This sets a variable called POD_NAME with the name of the Pod that’s running your app.

Query the Pod Using curl
Now that the proxy is running and we have the Pod name, we can make a direct request to the Pod’s API using: curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME

This command above:

Sends a request through the proxy
Reaches into the Kubernetes cluster
Returns details about your running Pod

This is a great way to see your application’s internal state directly from the terminal.

Step 3 – View the Logs from Your Container

In Kubernetes, any output your application sends to standard output (STDOUT) becomes part of the container logs. This is useful for checking what your app is doing, debugging issues, or just seeing printed messages (like logs or errors).

To view the logs from your running container, use this command: kubectl logs $POD_NAME

Since there’s only one container inside the Pod, you don’t need to specify the container name, Kubernetes knows which one to fetch logs from.

This command will show you everything the app has printed since it started, just like console.log, print(), or System.out.println() in a normal app.

Step 4 – Running Commands Inside the Container

Once your Pod is up and running, you can interact directly inside the container, that is almost like SSH-ing into a running app. This is helpful for debugging, inspecting files, or running manual tests.
Check Environment Variables
Let’s start by running a simple command to list all environment variables inside the container: kubectl exec $POD_NAME -- env

This uses kubectl exec to execute the env command inside your Pod.

Since our Pod only has one container, we don’t need to specify its name, because kubernetes knows which one to target.

Start a Shell Session (Bash)
To open a live terminal inside the container, run: kubectl exec -ti $POD_NAME -- bash

-ti allows you to run in interactive mode (just like SSH).
You are now inside the container’s shell and can run commands as if you were on a Linux server.

View the App Source Code
Your app is a simple Node.js app. You can check the source code by running: cat server.js

As you can see it printed the contents of the server.js file that’s running in the container.

Test the Running App
While still inside the container, test that the app is responding by curling localhost: curl localhost:8080

You should get a response from the app, as seen above usually the same one you'd see if it were exposed in a browser.

Note: We use localhost here because you're inside the Pod’s network. If this doesn’t work, doublecheck that you're running the command inside the container shell.

Exit the Container
When you’re done, type:exit

This will close the shell and return you to your local terminal.

Module 4 – Expose Your App to the Outside World 🌍

In this module, we will learn how to make your application accessible outside the Kubernetes cluster, so it’s no longer limited to just internal access.

Here’s what we’ll cover:

How to expose your app using the kubectl expose command
How to label Kubernetes resources using the kubectl label command (labels help group and organize your resources) By the end of this module, you’ll have your Node.js app reachable via a public URL and you’ll understand how to apply custom tags (labels) to your deployments and Pods.

Step 1 – Expose Your App by Creating a Service

Until now, your application has only been running inside the Kubernetes cluster, which means it’s not accessible from the outside world.

In this step, we’ll expose the app publicly using a Service of type NodePort, which opens a port on the cluster’s Node and allows external traffic to reach your app.

Check if Your App is Still Running
Run this command to make sure the Pod is active: kubectl get pods

List Current Services
Kubernetes might already have some default Services (like one for DNS). Run: kubectl get services

You’ll probably see a kubernetes service created automatically by Minikube.

Expose Your App with a New Service
Now let’s create a new Service that exposes our app externally on port 8080: kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

This creates a new service and maps it to the deployment we created earlier.

Check That the New Service Was Created
Run: kubectl get services

You should now see a new service called kubernetes-bootcamp.

It has a Cluster IP (internal network address).
It also has a NodePort, which makes it accessible from outside the cluster.

For Docker Desktop Users (Important Note)
If you're using Docker Desktop instead of Minikube, accessing NodePorts directly may not work due to networking restrictions.

Instead, run this command: minikube service kubernetes-bootcamp

As you can see this command will:

Open a browser window with your app
Create an SSH tunnel from the Node to your host
Allow access to your app externally

To close the tunnel, just hit Control + C.

Get the External Port (NodePort)
Let’s find out the actual port Kubernetes opened to the outside:
kubectl describe services/kubernetes-bootcamp

Create an environment variable called NODE_PORT that has the value of the Node port assigned: export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}') echo NODE_PORT=$NODE_PORT

Access the App from Your Host Machine
Now test your app using curl, combining Minikube’s IP address with the external port: curl $(minikube ip):$NODE_PORT

If everything is set up correctly, you should see a response from your Node.js app!

Congratulations!!!! our app is now publicly accessible!

Step 2 – Using Labels in Kubernetes

When we created our app using a Deployment, Kubernetes automatically added a label to the Pod. Labels are like name tags, they help us group, filter, and organize resources inside the cluster.

Check the Pod label:
We can look at the deployment details to see which labels were added: kubectl describe deployment

You'll see something like app=kubernetes-bootcamp listed under Labels.

Use the label to find the Pod:

Now that we know the label, we can use it to search for our Pod:
kubectl get pods -l app=kubernetes-bootcamp

The command above tells Kubernetes:

“Show me all the Pods that have the label app=kubernetes-bootcamp.”

You can do the same thing for services: kubectl get services -l app=kubernetes-bootcamp

Store the Pod name:

Let’s grab the Pod’s name and store it in a variable so we can use it easily in the next commands: export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') echo Name of the Pod: $POD_NAME

Add a new label to the Pod:
We can attach a custom label to the Pod. In this case, we’re labeling the version of the app: kubectl label pods $POD_NAME version=v1

This adds a label version=v1 to the Pod — super useful for organizing and managing deployments.

Check if the new label was applied:

Let’s confirm the label is attached: kubectl describe pods $POD_NAME

You’ll now see the new label listed under the Pod’s metadata.

Filter using the new label:
Now that we added the version=v1 label, We see here that the label is attached new to our Pod. Now we can use it to filter the Pod list: kubectl get pods -l version=v1

This is helpful when you have lots of Pods and want to target only specific ones, for example, by version, environment (dev, prod), or anything else you define with labels.

Step 3 – Deleting a Kubernetes Service

Now that we have exposed our app using a Service, let’s learn how to delete that Service when we no longer need it.

Delete the service:
We can remove the Service using the following command. It uses the same label we applied earlier: kubectl delete service -l app=kubernetes-bootcamp

This tells Kubernetes: Delete any Service that has the label app=kubernetes-bootcamp.

Make sure the Service is gone:

After deletion, confirm it with: kubectl get services

You should see that the custom Service is no longer listed, just the default Kubernetes service remains.

Test if the app is still exposed:
Try accessing the app from outside the cluster using the IP and NodePort you used earlier: curl $(minikube ip):$NODE_PORT

You’ll get an error now and that’s expected!

This shows that the app is no longer exposed to the outside world and that the route is closed.

Check if the app is still running inside the cluster:

Even though the service is gone, the app is still running internally. We can confirm that by sending a request from inside the Pod: kubectl exec -ti $POD_NAME -- curl localhost:8080

And wow, you should see the app respond.

This is because your Deployment is still running and managing the app inside Kubernetes. The Pod exists, but without a Service, it’s not reachable from outside.

Optional: Want to completely stop the app?

To shut it all down not just make it private you’d need to delete the Deployment too. That would stop the app entirely.

Module 5 – Scale Up Your App

In this module, we will learn how to increase the number of running copies (called replicas) of our app using Kubernetes. This is known as scaling.

Why scale?
Let’s say your app starts getting more traffic. One Pod (a running instance of your app) might not be enough to handle all the requests. So, we tell Kubernetes to run more Pods like hiring extra workers for a busy day.

When you scale up, Kubernetes automatically:

Creates more Pods from your Deployment
Spreads the traffic across all Pods (this is called load balancing)

Step 1 – Scaling a Deployment (Making More Copies of Your App)

Let’s now learn how to increase the number of app instances (called replicas) running in your cluster.

First, check how many app instances (replicas) you currently have:
kubectl get deployments
You should see something like this:

Here’s what those columns in the screenshot above mean:

NAME: Name of your deployment.
READY: How many Pods are currently running out of how many you want (e.g., 1/1).
UP-TO-DATE: How many of those Pods are using the most recent version of your app.
AVAILABLE: How many Pods are ready and available to users.
AGE: How long the deployment has been running.

Want to see the ReplicaSet (the part of Kubernetes that manages Pods)? run: kubectl get rs

Notice that the name of the ReplicaSet is always formatted as [DEPLOYMENT-NAME]-[RANDOM-STRING]. The random string is randomly generated and uses the pod-template-hash as a seed. As shown above kubernetes-bootcamp-579cb4f987
This shows:

DESIRED: How many Pods you want.
CURRENT: How many are actually running now.

Let’s scale up to 4 instances of the app.
let’s scale the Deployment to 4 replicas. We will use the kubectl scale command, following by the deployment type, name and desired number of instances: kubectl scale deployments/kubernetes-bootcamp --replicas=4
Note: This command tells Kubernetes:
"Run 4 copies of this app instead of just 1."

Confirm it worked:
Run this again: kubectl get deployments
You’ll now see:

The change was applied, and we have 4 instances of the application available. Next, let’s check if the number of Pods changed: kubectl get pods -o wide

Above yuou should see 4 different Pods, each with its own IP address.

Want details about what happened behind the scenes?
You can inspect the deployment: kubectl describe deployments/kubernetes-bootcamp

This shows events and confirms that the system added the new Pods successfully.

Step 2 – Load Balancing (Distributing Traffic Between Pods)

Now let’s check if our Service is properly sharing traffic across all the app replicas (Pods).

Step 1: Get the Service details
Run this to see the exposed IP and port of your app’s service: kubectl describe services/kubernetes-bootcamp

Note for Docker Desktop users on macOS:
Because of network restrictions, your host can’t directly talk to the Pods.
Run this instead to open a tunnel and launch your app in a browser: minikube service kubernetes-bootcamp

This opens a window in your browser. Keep refreshing the page, each refresh will be served by a different Pod!
You can stop the tunnel by pressing control + C in the terminal.

Step 2: Get the port that’s been exposed by the Service

Let’s create an environment variable so we don’t need to type the port each time: export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}') echo NODE_PORT=$NODE_PORT

Step 3: Test the load balancer

Now run this command several times: curl $(minikube ip):$NODE_PORT

Each time you run it, you should see a response from a different Pod.
That means Kubernetes is distributing (load-balancing) your requests across all running Pods.

Step 3 - Scale Down
To scale down the Service to 2 replicas, run again the scale command: kubectl scale deployments/kubernetes-bootcamp --replicas=2

List the Deployments to check if the change was applied with the get deployments command: kubectl get deployments

The number of replicas decreased to 2. List the number of Pods, with get pods: kubectl get pods -o wide

Shown above confirms that 2 Pods were terminated.

Module 6 – Updating Your Application

In this section, you'll learn how to update an application that's already been deployed in Kubernetes. You'll use the kubectl set image command to apply the update and kubectl rollout undo to revert changes if necessary.

Step 1 – Upgrading the Application Version

Begin by checking the current deployments: kubectl get deployments

Then, verify which Pods are currently running: kubectl get pods

To confirm the image version currently in use by the application, inspect the Pod details: kubectl describe pods

To update the image of the application to version 2, use the set image command, followed by the deployment name and the new image version: kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/k8s-minikube/kubernetes-bootcamp:v2

This will trigger a rolling update, replacing the old Pods with new ones that use the new image. You can track the update by listing the Pods again: kubectl get pods

You’ll see the new Pods being created while the previous ones terminate.

Step 2 – Confirm the Application Has Been Updated

To begin, ensure the application is still running correctly. First, determine the exposed IP and port by describing the service:
kubectl describe services/kubernetes-bootcamp

Note for Docker Desktop users: Since direct Pod access from the host is restricted, use this command to open a tunnel and access the app in your browser: minikube service kubernetes-bootcamp

You can close the tunnel by pressing Control+C. Once done, proceed with the curl command shown below.

Next, Create an environment variable called NODE_PORT that has the value of the Node port assigned:: export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}') echo NODE_PORT=$NODE_PORT

Next, do a curl to the exposed IP and port, Now send a request to the application using the IP and Node port:
curl $(minikube ip):$NODE_PORT

Each time you run the command, you’ll likely hit a different Pod. Notice that all Pods are running the latest version (v2).

You can also confirm the update by running the rollout status command: kubectl rollout status deployments/kubernetes-bootcamp

Finally, confirm the image version by inspecting the Pod details:
kubectl describe pods

Check the Image field to ensure and notice it reflects version v2.

Step 3 - Rollback an update (Revert to a Previous AppVersion)

Let’s simulate a failed deployment by attempting to update the app with a non-existent image version (v10): kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/k8s-minikube/kubernetes-bootcamp:v10

Check the deployment status: kubectl get deloyments

Notice that the output doesn’t list the desired number of available Pods. Run the get pods command to list all Pods: kubectl get pods

Notice some Pods are showing a status like ImagePullBackOff, indicating that Kubernetes is unable to fetch the specified image.

To understand what went wrong, use the following command to view Pod details: kubectl describe pods

In the Events section, you’ll see errors confirming that the image tagged v10 couldn’t be found in the registry.

To recover from this failed rollout, you can revert to the last stable version (v2) using: kubectl rollout undo deployments/kubernetes-bootcamp

This command tells Kubernetes to roll the Deployment back to the most recent successful configuration.

Now, verify that the Pods are back to normal: kubectl get pods

You should see the healthy Pods again. To confirm they’re using the correct image, run: kubectl describe pods

The deployment is once again using a stable version of the app (v2). Showing that the rollback was successful.

Conclusion

Kubernetes can seem complex at first, but starting with Minikube makes it much easier to learn and experiment. In this guide, we walked through how to deploy a simple application, explore how it runs in a pod, expose it to the outside world, scale it to handle more traffic, and update or roll back versions, all using real commands and step-by-step explanations.

By the end of this article, you have built a solid foundation in how Kubernetes works behind the scenes. These are the same concepts used in real-world production environments just scaled up. The more you practice, the more confident you will become.

Keep exploring, break things, fix them, and don’t be afraid to try more advanced features as you grow. Kubernetes is a powerful tool, and you’ve just taken the first important step.

Docker Made Simple: A Beginner’s Guide

Kosisochukwu Ugochukwu — Fri, 04 Jul 2025 13:41:43 +0000

INTRODUCTION

Docker is like a magic box that lets you run apps the same way everywhere whether on your Mac, a friend’s PC, or even in the cloud. No more "But it works on my machine!" problems.

In this guide, we will cover eight parts in docker workshop which is
PART 1: Containerize an application
PART 2: Update the application
PART 3: Share the application
PART 4: Persist the DB
PART 5: Use bind mounts
PART 6: Multi container apps
PART 7: Use Docker Compose
PART 8: Image-building best practices

So we will start from zero-no prior Docker knowledge! so at the end, you will know how to:
✅ Package an app in a container (like a lunchbox).
✅ Update it easily.
✅ Share it with others.
✅ Store data safely.
✅ Run multiple apps together (like a mini internet café).
✅ And much more show all with simple steps and Mac screenshots!

Let’s dive in!

PART 1: CONTAINERIZE AN APPLICATION (Put Your App in a Box)

What’s a Container?
Think of a container like a lunchbox:

Your app is the sandwich.

The Docker container is the lunchbox keeping it fresh.

No matter where you open it (Mac, Windows, Linux), it works the same way!

Before you begin you need to have make all this availiable in your PC

You have installed the latest version of Docker Desktop.
You have installed a Git client.
You have an IDE or a text editor to edit files. Docker recommends using Visual Studio Code.

Steps

Create a Simple App (Let’s use Python)

Click on Terminal on the dropdwon click on new terminal

and then create a directory and open the directory by runinig the command:

mkdir DevOpsstarter
cd DevOpsstarter

Get the app

a. Before you can run the application, you need to get the application source code onto your machine.

Run the command: git clone https://github.com/docker/getting-started-app.git

b. View the contents of the cloned repository. You should see the following files and sub-directories.

getting-started-app/
.dockerignore
package.json
README.md
spec/
src/
yarn.lock

Build the app's image To create the image, you’ll need something called a Dockerfile. This is just a plain text file (it doesn’t even need a file extension) that lists step-by-step instructions. Docker reads these instructions to build a special kind of package called a container image, which is like a ready-to-use setup of your app or service.

a. In the "getting-started-app" folder, the same place where the package.json file is create a new file called Dockerfile

Then add the following content to it:

# syntax=docker/dockerfile:1 FROM node:lts-alpine WORKDIR /app COPY . . RUN yarn install --production CMD ["node", "src/index.js"] EXPOSE 3000

Notice that this Dockerfile starts off with a node: lts-alpine base image, a small and efficient version of Linux that already has Node.js and Yarn (tools used to run and manage JavaScript apps) built in. Then, it copies your app’s files into this setup, installs everything the app needs, and starts it up.

b. Build the image using the following commands:

In the terminal, make sure you're in the getting-started-app directory. Replace /path/to/getting-started-app with the path to your getting-started-app directory.

cd /path/to/getting-started-app

Build the image.

Run the command: docker build -t getting-started .

The docker build command uses your Dockerfile to create a new image of your app. You should have noticed that Docker downloaded a bunch of things, these things are called "layers." That happened because you told Docker to start with a base image called node:lts-alpine, but since it wasn’t already on your computer, Docker had to download it first.

Once that was done, Docker followed the steps in your Dockerfile: it copied your app’s files into the image and used Yarn to install everything your app needs to run.

The CMD part in the Dockerfile sets the default command that will run when you start a container using this image, so basically, it tells Docker how to launch your app.

The -t flag in the command gives your image a name. In this case, you called it getting-started, so it’s easier to refer to later when you want to run it.

Finally, the . (dot) at the end of the command just means: “look for the Dockerfile in this current folder.”

Start an app container

Now that your image is ready, you can use the docker run command to start your app inside a container. Think of it like launching your app in its own little box.

a. To run your app, use the docker run command and tell it which image to use, so in this case, the one you just created (called getting-started). This starts your app inside a container.

docker run -d -p 127.0.0.1:3000:3000 getting-started

The -d flag (short for detach) tells Docker to run your app in the background. That means your app keeps running, but you get your terminal back and won’t see the app’s output (logs) unless you check them separately.

The -p flag (short for publish) connects your app running inside Docker to your computer, so you can access it. It works like this:
-p 127.0.0.1:3000:3000

This means: take port 3000 from inside the container (where the app is running), and make it available on your computer at localhost:3000. Without this, you wouldn’t be able to open the app in your web browser.

b. After waiting a few seconds, open your web browser and go to http://localhost:3000. You should see your app up and running!

Add one or two items to your list and check that everything works like it should. You can mark items as done and also delete them. This means your front end (what you see) is successfully saving data to the back end (the storage part).

Now, you have a working to-do list app with some items in it.

If you want to see your running containers, you should notice at least one container using the getting-started image and running on port 3000. You can check this either by using commands in the terminal or by opening Docker Desktop, which has a user-friendly interface for managing containers.

In CLI

Run the docker ps command in a terminal to list your containers.

In Docker Desktop
select the Containers tab to see a list of your containers.

Summary

In this section, you learned how to create a Dockerfile to build an image. After building the image, you started a container and saw your app running.

PART 2: UPDATE THE APPLICATION (Change the Sandwich)

Why Update?
You wouldn’t eat the same sandwich forever. Apps need updates too!

In Part 1, you put a todo app into a Docker container (a process called containerizing). In this next part, you’ll learn how to update the app and its image. You’ll also see how to stop and delete a running container when you no longer need it.

Update the source code
In the following steps, you'll change the "empty text" when you don't have any todo list items to "You have no todo items yet! Add one above!"

a. In the src/static/js/app.js file, update line 56 to use the new empty text.

No items yet! Add one above!

You have no todo items yet! Add one above!
`

b. Build your updated version of the image, using the docker build command.

docker build -t getting-started .

c. Start a new container using the updated code.

docker run -dp 127.0.0.1:3000:3000 getting-started

You will saw an error like this:

docker: Error response from daemon: driver failed programming external connectivity on endpoint laughing_burnell (bb242b2ca4d67eba76e79474fb36bb5125708ebdabd7f45c8eaf16caaabde9dd): Bind for 127.0.0.1:3000 failed: port is already allocated.

The error occurred because you aren't able to start the new container while your old container is still running. The reason is that the old container is already using the host's port 3000 and only one process on the machine (containers included) can listen to a specific port. To fix this, you need to remove the old container.

Remove the old container

To delete a container, you need to stop it first. Once it’s no longer running, you can go ahead and remove it completely.
You can do this using terminal commands or by using Docker Desktop’s easy-to-use interface, just pick whichever method you’re more comfortable with. But in this article we are using CLI command

Remove a container using the CLI

Get the ID of the container by using the docker ps command.

Use the docker stop command to stop the container. Replace with the ID from docker ps.

docker stop <the-container-id>

Once the container has stopped, you can remove it by using the docker rm command.

Note
You can stop and remove a container in a single command by adding the force flag to the docker rm command. For example: docker rm -f <the-container-id>

Start the updated app container

Now, start your updated app using the docker run command.

docker run -dp 127.0.0.1:3000:3000 getting-started

Refresh your browser on http://localhost:3000 and you should see your updated help text.

Summary

In this section, you learned how to make changes to your app, rebuild the container to apply those updates, and how to stop and delete a container when you're done with it.

Part 3 SHARE THE APPLICATION

Once you have created a Docker image, you can share it with others. To do that, you need to upload it to a place called a Docker registry. The main one people use is called Docker Hub, it's where the images you've been using came from.

Docker ID

A Docker ID lets you use Docker Hub, which is the biggest place to find and share container images. If you don’t have a Docker ID yet, you can create one for free via https://app.docker.com/signup?

Note, to push an image, you first have to create a respository on Docker Hub.

a. Sign up or Sign in to Docker Hub via https://hub.docker.com/

b. Click the "Create Repository" button to start making a new space where you can store and share your Docker image.

c. For the repository name, type getting-started.
Also, make sure the Visibility is set to Public, so others can find and use your image. Then select create.

Let's try to push an image to Docker Hub.

In the command line, run the following commmand:

docker push docker/getting-started

From the above image you will see an error like this:

docker push docker/getting-started
The push refers to repository [docker.io/docker/getting-started]
An image does not exist locally with the tag: docker/getting-started

This error is normal because the image doesn’t have the right name yet. Docker is trying to find an image called docker/getting-started, but the one you created is just named getting-started on your computer.

You can confirm this by running the command:

docker image ls

To fix the issue, start by signing in to Docker Hub with your Docker ID. Use this command in your terminal: docker login YOUR-USER-NAME (replace YOUR-USER-NAME with your actual Docker username):

Use the docker tag command to rename your getting-started image so it matches what Docker Hub expects. Replace YOUR-USER-NAME with your actual Docker ID:

docker tag getting-started YOUR-USER-NAME/getting-started

Now run the docker push command again. If you're copying the value from Docker Hub, you can drop the tagname part, as you didn't add a tag to the image name. If you don't specify a tag, Docker uses a tag called latest.

docker push YOUR-USER-NAME/getting-started

Run the image on a new instance

Now that your image is built and uploaded to a registry, you can test it on a fresh system that hasn’t used this image before.
To do that, use Play with Docker, a free online tool that lets you run Docker containers in a clean environment.

NOTE
Play with Docker runs on the amd64 platform. If you're using an ARM-based Mac with Apple silicon, your image may not work there unless it's rebuilt for amd64.

To fix this, rebuild your Docker image using the --platform flag like this: docker build --platform linux/amd64 -t YOUR-USER-NAME/getting-started .

Open your browser to Play with Docker via https://labs.play-with-docker.com/

Click Login, then choose docker from the drop-down list to sign in with your Docker Hub account.

Select the ADD NEW INSTANCE option on the left side bar. If you don't see it, make your browser a little wider. After a few seconds, a terminal window opens in your browser.

In the terminal, run the following command to start your newly pushed app: docker run -dp 0.0.0.0:3000:3000 YOUR-USER-NAME/getting-started

You should see Docker download (or "pull") the image from Docker Hub, and then start running it. After a few moments, your app should be up and ready to use.

Tip:
You might have noticed that this time, the port is bound to 0.0.0.0 instead of 127.0.0.1 like before.

Here's the difference:

127.0.0.1: Only allows access from the same machine (localhost). The app is not reachable from outside.
0.0.0.0: Makes the app available on all network interfaces, so it can be accessed from other machines too.

By using 0.0.0.0, you're allowing the container's port to be open to the outside world which is why it works in environments like Play with Docker.

Summary
In this section, you learned how to share your Docker images by pushing them to a registry like Docker Hub. Then, you tested it by running the image on a completely new instance just like in real-world scenarios.

This is a common setup in CI (Continuous Integration) pipelines:

The pipeline builds and pushes a new image to a registry.
Then, a production server or another environment pulls that image and runs it by always using the latest version.

PART 4

PERSIST THE DB

If you noticed that your todo list is always empty every time you start the container that’s expected. But why?

This happens because containers don’t keep data by default. When a container stops or is deleted, any data it stored is lost too. Each time you restart it, it's like a fresh install with no memory of the past.

In the next part, you’ll explore how containers handle data and how to persist it across restarts using things like volumes.

The container's filesystem

When a container runs, it builds its filesystem from the layers in the image it was created from. On top of that, Docker gives each container its own "scratch space" — a writable layer where it can create, modify, or delete files.

Here’s the key point:
This scratch space is private to that container. So:

Any changes made (like adding a todo item) stay inside that container.
Other containers using the same image won’t see those changes, because they get their own fresh scratch space.
Once the container is deleted, its scratch space and all your data is gone too.

To share or persist data, you need a solution outside of the container’s temporary filesystem such as Docker volumes.

Lets try It Out

Let’s walk through an example to see how this actually works.

To try this out, you'll run two separate containers. In the first one, you’ll create a file, and in the second one, you’ll check to see if that file is there.

Start an Alpine container and create a new file in it.

docker run --rm alpine touch greeting.txt

Tip:
Any command you add after the image name (like alpine) runs inside the container. For example, the command touch greeting.txt creates a file named greeting.txt in the container’s filesystem.

Run a new Alpine container and use the stat command to see if the file is there:

docker run --rm alpine stat greeting.txt

You should see a message like this, showing that the file isn’t there in the new container:

The greeting.txt file made in the first container wasn’t found in the second one. That’s because each container has its own separate writable layer. While both containers use the same base image layers, any changes (like new files) are stored in a layer that’s unique to each container and can’t be seen by others.

Container volumes

Earlier, you saw that every time you run a container, it starts fresh based on the image. Any files the container creates or changes are lost when the container is deleted, and those changes are kept separate from everything else.

Volumes help fix this.

They let you connect a folder inside the container to your own computer. So if the container changes something in that folder, it also shows up on your machine — and it won’t be lost when the container stops or restarts.

There are two main kinds of volumes. You’ll learn about both, but you’ll begin with something called a volume mount.

Persist the todo data

By default, the todo app saves its data in a file called todo.db, which is stored at /etc/todos/todo.db inside the container. This file uses something called SQLite, which is just a lightweight way to store data in one file. It’s great for small projects like this, even if it’s not ideal for big apps. Later on, you’ll learn how to use a more advanced database.

Because all the data is in a single file, you can keep your data safe by saving that file outside the container — on your computer. That way, if the container stops or is deleted, the data stays.

To do this, you will use something called a volume, which is like a storage box managed by Docker. You “attach” (or mount) it to the folder where the app saves its data. Then, even if the container goes away, the data in todo.db is saved and can be used again.

You’re going to use a volume mount, which you can think of as a simple storage bucket. Docker takes care of where it’s stored you just need to know its name.

Create a volume and start the container
You can set up the volume and run the container either using the command line or Docker Desktop's visual interface. In this guide, we’ll use Docker Desktop’s graphical interface to keep things simple and easy to follow.

To create a volume

Select Volumes in Docker Desktop

In Volumes, select Create.

Specify todo-db as the volume name, and then select Create.

To stop and remove the app container:

Select Containers in Docker Desktop.
Select Delete in the Actions column for the container.

To start the todo app container with the volume mounted:

Click on the search bar at the top of the Docker Desktop window.
In the search window, select the Images tab.

In the search box, specify the image name, getting-started
Select your image and then select Run.

Select Optional settings.
In Host port, specify the port, for example, 3000.
In Host path, specify the name of the volume, todo-db.
In Container path, specify /etc/todos.
Select Run.

Check to make sure the data is still there.

Shut down and delete the todo app container. You can do this using Docker Desktop or by running docker ps to find the container ID, then removing it with: docker rm -f <id>

Launch a new container by repeating the steps you used earlier.
Once you’re done reviewing your list, feel free to delete the container.

You’ve just learned how to save data so it’s not lost when the container stops.

Explore what's inside the volume
Many people often wonder, “Where does Docker keep my data when I use a volume?” If you’re curious, you can find out by running the docker volume inspect command.

docker volume inspect todo-db

You should see output like the following:

The Mountpoint shows the exact place on your computer where the data is stored. Keep in mind that on most systems, you'll need admin or root access to open this folder from your machine.

Summary
In this part, you discovered how to save container data so it remains available even after the container is stopped or removed.

PART 5
USE BIND MOUNTS

In Part 4, you used something called a volume mount to save your app’s data, so it doesn’t get lost when the container stops. Volume mounts are great when you need a safe place to store your app’s files.

Now you’ll learn about another type called a bind mount. This lets you share a folder from your computer directly with the container. So, if you're working on your app’s code and save a change, the container sees that change right away.

This is super helpful while developing, because tools like nodemon (which we will use in this chapter) can watch your files and automatically restart the app whenever you make edits. Most programming languages have tools like this, and it makes testing and building apps much easier.

Quick volume type comparisons
The following are examples of a named volume and a bind mount using --mount:

Named volume: type=volume,src=my-volume,target=/usr/local/data

Bind mount: type=bind,src=/path/to/data,target=/usr/local/data

The following table outlines the main differences between volume mounts and bind mounts.

Feature	Volume Mount	Bind Mount
Managed by	Docker	You (host OS)
Location	Inside Docker's storage	Anywhere on your file system
Use case	Production data, persistent storage	Development, local file access
Portability	High (works across systems)	Low (host-specific paths)
Docker backup tools	Supported	Not supported
Performance	Generally better	Can be slower (especially on macOS)

If you're developing an app, use bind mounts.
If you're running production containers or need reliable data storage, use volumes.

Trying out bind mounts
Before we dive into using bind mounts for app development, let’s do a quick hands-on test. This simple experiment will help you see how bind mounts actually work in a real situation.

Make sure your getting-started-app folder is located in a part of your computer that Docker Desktop is allowed to access. Docker has a setting that controls which folders on your machine can be shared with containers. If your folder isn’t in one of those approved locations, Docker won’t be able to use it.

To find or change this setting, check Docker Desktop’s file sharing options.

The File Sharing tab only shows up when Docker is running in Hyper-V mode. That’s because in WSL 2 mode and Windows container mode, file sharing is handled automatically, so you don’t need to set it up manually.

Open a terminal and change directory to the getting-started-app directory.
Run this command to start a terminal session inside an Ubuntu container, while also linking a folder from your computer (on Mac/Linux): docker run -it --mount type=bind,src="$(pwd)",target=/src ubuntu bash

The --mount type=bind option tells Docker to link a folder from your computer (in this case, your current working directory, like getting-started-app) into the container. The src is the folder on your computer, and the target is the location inside the container where that folder will show up (here, /src).

Once you run the command, Docker opens a bash terminal where you can type commands, starting in the main (root) folder of the container’s file system. Then Run the command: pwd (This command displays the full path of the current working directory (the directory you're currently in).

Run the command ls (used to display the contents of a directory, including files and subdirectories)

Change directory to the src directory. This is the folder you linked (mounted) when you started the container. If you list the files here, you will see the exact same files that are in your getting-started-app folder on your computer.

Run the command: cd src

Run this command ls to list the item in that folder

Create a new file named myfile.txt. To create a new file myfile.txt, run the command: touch myfile.txt

Run the command ls to list the item in the file

Open the getting-started-app folder on your computer and you will see that the file myfile.txt is inside it.

On your computer, go to the getting-started-app folder and delete the myfile.txt file.

In the container, list the contents of the app directory once more. Observe that the file is now gone.

Exit the interactive container session by pressing Ctrl + D on your keyboard.

That’s a quick overview of bind mounts! This showed how files can be shared between your computer and the container, and how any changes you make appear right away in both places. Now you’re ready to use bind mounts to help build and test your software.

Development containers
Using bind mounts is a popular way to develop locally because you don’t have to install all the build tools and software on your own computer. Instead, with just one docker run command, Docker downloads everything your app needs, making it easier and faster to get started.

Run your app in a development container
Here’s how to run a development container with a bind mount that will:

Mount your source code into the container
Install all dependencies
Start nodemon to watch for filesystem changes

Using Mac/linux

From inside the getting-started-app folder on your computer, run this command: docker run -dp 127.0.0.1:3000:3000 \ -w /app --mount type=bind,src="$(pwd)",target=/app \ node:18-alpine \ sh -c "yarn install && yarn run dev"

Here’s what each part of the command means:

-d -p 127.0.0.1:3000:3000 — Run the container in the background (detached mode) and connect port 3000 on your computer to port 3000 inside the container, but only accessible from your machine (localhost).
-w /app — Set the working directory inside the container to /app, so commands run from there.
--mount type=bind,src="$(pwd)",target=/app — Link (bind mount) your current folder on your computer ($(pwd)) into the container’s /app folder.
node:18-alpine — Use this lightweight Node.js image as the base for your container. This matches what your app uses in its Dockerfile.
sh -c "yarn install && yarn run dev" — Run a shell command: first install the app’s dependencies with yarn install, then start the development server with yarn run dev. The dev script uses nodemon, which watches for file changes and restarts the app automatically.

Basically, this command sets up your app inside the container, installs what it needs, and runs it so you can develop with live updates.

You can check what’s happening by running docker logs <container-id>. When you see this message, it means your app is up and running and ready to use:

When you’re finished checking the logs, press Ctrl + C to stop and exit the log view.

Develop your app with the development container

Make changes to your app files on your computer, and you will see those updates happen instantly inside the running container.

In the src/static/js/app.js file, on line 109, change the "Add Item" button to simply say "Add":

_- {submitting ? 'Adding...' : 'Add Item'}

{submitting ? 'Adding...' : 'Add'}_

Save the file.

Refresh your web browser, and you should see the update show up almost right away thanks to the bind mount. Nodemon notices the change and restarts the server automatically. It might take a few seconds for the server to restart, so if you see an error, just wait a moment and refresh again.

Go ahead and make any other changes you want. Every time you save a file, those updates will instantly show up inside the container thanks to the bind mount. Nodemon will spot the changes and automatically restart the app for you. When you’re finished, stop the container and create a new image by running:

docker build -t getting-started .

Summary

Now you can keep your database data saved and watch your app update live while you develop without having to rebuild the image every time.

Besides volume mounts and bind mounts, Docker also offers other ways to connect storage and manage data for more advanced needs.

PART 6
MULTI CONTAINER APPS

So far, we have been working with apps that run inside a single container. Now, we are going to add MySQL to your setup. A common question is: “Where should MySQL run? Should it be installed inside the same container, or run separately?”

Usually, it’s best to have each container handle one job and do it well. Here are a few reasons why running MySQL in its own separate container is a good idea:
Here’s a simpler way to explain those points:

There is possibility that we need to scale APIs and front-end separately from your database.
Running MySQL in its own container lets you update or change its version without affecting the rest of your app.
When working on your computer, you might run the database in a container, but in real production, you might use a managed database service instead — so you don’t want to include the database inside your app container.
Containers are designed to run one main process. Running multiple processes (like your app and database together) means you’d need extra tools to manage them, which makes things more complicated when starting or stopping the container.

Container networking

By default, containers run in their own isolated environments and don’t automatically know about other containers on the same machine.

So, how can one container (like your app) talk to another (like a MySQL database)?

The answer is: networking.

When you put both containers on the same Docker network, they can find and talk to each other just like they're on the same private network.

Start MySQL

You can connect containers to a network in two ways:

Assign the network when you start the container – This is the most common method. You specify the network as part of the docker run command.
Connect an already running container to a network – If the container is already running, you can use docker network connect to link it to a network afterward.

In the next steps, we will first create a Docker network. Then, when we start the MySQL container, we will then attach it to that network right from the beginning so it can communicate with other containers.

Create the network

Run the following command to create a new Docker network named todo-app:

Start a MySQL container and connect it to the same network as your app. You’ll also set a few basic settings (like password and database name) so MySQL knows how to set itself up when it starts.

Run this command on MAC/LINUX/GITBASH

docker run -d \ --network todo-app --network-alias mysql \ -v todo-mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=secret \ -e MYSQL_DATABASE=todos \ mysql:8.0

In the command you just saw, there’s a part called --network-alias. Don’t worry about it for now — you’ll learn what it means and how it works a bit later.

Tip: In the command above, you might see a volume called todo-mysql-data connected to /var/lib/mysql, which is where MySQL saves its data. You didn’t manually create this volume with a command, Docker saw that you needed it and automatically made it for you.

To make sure your database is working, try connecting to it and check if the connection is successful.

docker exec -it <mysql-container-id> mysql -u root -p

When asked for the password, type secret. Once inside the MySQL command line, list the databases to make sure you see the one called todos.
mysql> SHOW DATABASES;

Leave the MySQL command line by typing exit so you go back to your regular terminal on your computer.

You now have a todos database set up and ready to be used in your app.

Connect to MySQL
Now that MySQL is running, you might wonder how to connect to it from another container. Since each container has its own IP address, how do they find each other?

To help answer this and learn more about how containers talk to each other, you’ll use a special container called nicolaka/netshoot. It comes with handy tools to help you check and fix network problems between containers.

Start a new container using the nicolaka/netshoot image and connect it to the same network as your other containers so it can communicate with them. Run this command: docker run -it --network todo-app nicolaka/netshoot

Inside the container, we will run the dig command, which helps look up addresses. So we will use it to find the IP address of the container named mysql. dig mysql You should get output like the following below.

In the “ANSWER SECTION,” you’ll see that the name mysql points to an IP address (like 172.20.0.2, though yours will probably be different). Normally, “mysql” isn’t a real website or address, but Docker knows how to match that name to the right container because of the network alias you set earlier.

This means your app can just use the name mysql to connect to the database, it doesn’t need to know the actual IP address.

Run your app with MySQL
The todo app lets you set a few simple settings to connect to MySQL by using environment variables. These are:

MYSQL_HOST: the name of the MySQL server to connect to
MYSQL_USER: the username for logging in
MYSQL_PASSWORD: the password for that user
MYSQL_DB: the specific database to use after connecting

Note:

Using environment variables to set connection details is okay for testing and development, but it’s not recommended for apps running in real, live environments (production).

A more secure way is to use secrets, which many container tools support. These secrets are usually stored as files inside the container instead of just environment variables.

Many apps, like MySQL and the todo app, let you use special environment variables ending with _FILE. For example, if you set MYSQL_PASSWORD_FILE, the app will read the password from a file instead of from a plain environment variable.

Docker itself doesn’t manage this automatically — your app has to be programmed to check for these _FILE variables and read the secret from the file.

we’re now ready to start a container that’s set up for development.

Set up your container by providing all the environment variables from before (like MYSQL_HOST, MYSQL_USER, etc.) and connect it to your app’s network. Before running the command, make sure you’re inside the getting-started-app folder on your computer. Using MAC/LINUX

docker run -dp 127.0.0.1:3000:3000 \ -w /app -v "$(pwd):/app" \ --network todo-app \ -e MYSQL_HOST=mysql \ -e MYSQL_USER=root \ -e MYSQL_PASSWORD=secret \ -e MYSQL_DB=todos \ node:18-alpine \ sh -c "yarn install && yarn run dev"

If you check the container’s logs using docker logs -f <container-id>, you should see a message that shows it’s connected to and using the MySQL database. The message is seen below

Open the app in your web browser and add some tasks to your todo list.

Connect to the MySQL database and check to make sure the items you added are saved there. Don’t forget, the password to log in is secret. docker exec -it <mysql-container-id> mysql -p todos

Once you’re in the MySQL command line, run this command:
select * from todo_items;

Now confirm the items we added earlier, so your table might look different because it has your own todo items, but you’ll be able to see that your tasks are saved there.

Summary

Now you have an app that saves its data in a separate database running in another container. You also learned how containers connect with each other over a network using DNS to find services.

PART 7
USE DOCKER COMPOSE
Docker Compose is a tool that makes it easy to set up and manage multiple containers for your app. You write a simple file (called a YAML file) that lists all the parts of your app, and then with just one command, you can start everything or stop it all.

The best part is that this file lives in your project folder and gets saved with your code. This means anyone who wants to work on your project can just download it and start the app quickly using Compose. Lots of projects on places like GitHub or GitLab use this method now.

CREATE THE COMPOSE FILE

Inside the getting-started-app folder, create a new file and name it compose.yaml.

!compose yaml](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/igxbgz07ua2vmqhzbyq0.png)

DEFINE THE APP SERVICE
In part 6, you used the following command below to start the application service:
docker run -dp 127.0.0.1:3000:3000 \ -w /app -v "$(pwd):/app" \ --network todo-app \ -e MYSQL_HOST=mysql \ -e MYSQL_USER=root \ -e MYSQL_PASSWORD=secret \ -e MYSQL_DB=todos \ node:18-alpine \ sh -c "yarn install && yarn run dev"

Now we are going to write the same setup inside the compose.yaml file so Docker can use it automatically.

Open compose.yaml in a text or code editor, and start by defining the name and image of the first service (or container) you want to run as part of your application. The name will automatically become a network alias, which will be useful when defining your MySQL service. services: app: image: node:18-alpine

Usually, you'll find the command line placed near the image line in the compose.yaml file, but it doesn't have to be in a specific order. Now, go ahead and add the command section to your compose.yaml file. This tells Docker what the container should do when it starts.

services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev"

Now take the part of the command that says -p 127.0.0.1:3000:3000 (which maps your computer’s port to the container’s port) and add it under the ports section of the service in your compose.yaml file. This lets you open the app in your browser at localhost:3000 just like before. `services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" ports:
- 127.0.0.1:3000:3000`

This tells Docker to make the app available on your computer at port 3000.

Now move the part of the command that sets the working directory (-w /app) and the part that connects your folder to the container (-v "$(pwd):/app"). In the compose.yaml file, this is done using working_dir and volumes.

You don’t need to type the full path — Docker Compose lets you use relative paths (like .:/app, where . means “this folder”).

Here’s how that looks in simple terms:
services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" ports: - 127.0.0.1:3000:3000 working_dir: /app volumes: - ./:/app

Lastly, move the environment variables (the ones you previously set with -e) into your compose.yaml file by using the environment section.

In simple terms, environment variables are like settings your app needs to connect to things like the database.

Here’s how you add them:
services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" ports: - 127.0.0.1:3000:3000 working_dir: /app volumes: - ./:/app environment: MYSQL_HOST: mysql MYSQL_USER: root MYSQL_PASSWORD: secret MYSQL_DB: todos

This setup tells the app how to connect to the database — using the host name mysql, a username, a password, and the database name. Now everything your app needs is inside the compose.yaml file.

DEFINE THE MySQL SERVICE
Now let’s set up the MySQL part of the app inside the compose.yaml file.

Earlier, we started MySQL using a command like this below in the terminal:
docker run -d \ --network todo-app --network-alias mysql \ -v todo-mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=secret \ -e MYSQL_DATABASE=todos \ mysql:8.0

Start by creating a new service in your compose.yaml file called mysql. This name will automatically act like a nickname (network alias) so other parts of your app can find it easily. Also, tell Docker which image to use for this service (in this case, the MySQL database image).

services: app: # The app service definition mysql: image: mysql:8.0

Next, set up the volume for the MySQL service. When you used docker run, Docker made the volume for you automatically, but with Compose, you have to create it yourself. To do this, first list the volume at the top of your compose.yaml file under a section called volumes:. Then, in the MySQL service settings, tell it to use that volume by its name. Just giving the volume name is enough—Docker will use the usual settings.

services: app: # The app service definition mysql: image: mysql:8.0 volumes: - todo-mysql-data:/var/lib/mysql volumes: todo-mysql-data:

Lastly, you need to add the environment variables. These are simple settings that tell the MySQL service important details like the username, password, and database name it should use. `services: app: # The app service definition mysql: image: mysql:8.0 volumes:
- todo-mysql-data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: secret MYSQL_DATABASE: todos volumes: todo-mysql-data:`

Now, your full compose.yaml file should look something like this:

`services:
app:
image: node:18-alpine
command: sh -c "yarn install && yarn run dev"
ports:
- 127.0.0.1:3000:3000
working_dir: /app
volumes:
- ./:/app
environment:
MYSQL_HOST: mysql
MYSQL_USER: root
MYSQL_PASSWORD: secret
MYSQL_DB: todos

mysql:
image: mysql:8.0
volumes:
- todo-mysql-data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: secret
MYSQL_DATABASE: todos

volumes:
todo-mysql-data:`

Run the application stack
With our compose.yaml file ready, we can now start your app easily.

Before starting, double-check that no other copies of the containers are running. You can use docker ps to see running containers, and if you find any, use docker rm -f <container-ids> to stop and remove them. As you can see below how we stop and removed two active containers that was running

Run the command docker compose up -d to start all parts of your app at once. The -d flag makes everything run in the background so you can keep using your terminal. When you run the command you will see something like this below

You’ll see that Docker Compose made a special storage space (called a volume) and a network for your app. It does this automatically to help the different parts of your app talk to each other, so you didn’t have to set it up yourself in the file.

Check the logs by running docker compose logs -f. This shows messages from all the parts of your app mixed together in one place. It’s really handy to see how things are working at the same time. The -f means the logs keep updating live as new messages come in.

If you already ran this command, you’ll see something like this:

At the start of each line in the logs, you’ll see the name of the service that created that message (it’s usually in color to make it easier to tell them apart).

If you only want to see messages from one specific part of your app, just add the service name to the end of the command. For example:
'docker compose logs -f app'
This will only show logs from the app service.

Now, you can open your web browser and go to http://localhost:3000. Your app should be up and running there.

See the app stack in Docker Desktop Dashboard

If you open Docker Desktop, you’ll see a section called getting-started-app. That’s just the name of your project, and it comes from the name of the folder where your compose.yaml file is saved.

When you click to expand it, you’ll see the two containers you set up — one for your app and one for MySQL. Their names are easy to understand because they follow a pattern like:
[service-name]-[number]
For example, app-1 or mysql-1. This helps you quickly know which one is which.

TEAR IT ALL DOWN
When you're done and want to shut everything down, just run the command docker compose down, or click the trash can icon in Docker Desktop next to your app. This will stop the containers and remove the network they were using.

Heads up: When you use docker compose down, it doesn't automatically delete the named volumes listed in your Compose file. These volumes hold your data, so they stick around unless you specifically tell Docker to remove them by adding the --volumes option to the command.

Also, if you're using Docker Desktop and delete your app from the dashboard, it won’t remove the volumes either. You’ll need to delete them manually if you want them gone.

Summary
In this part, you learned how Docker Compose makes it easier to manage apps that use more than one container. Instead of running lots of commands, you can describe everything your app needs in one file, and then start or stop everything with just one simple command. This also makes it easier to share your app with others.

PART 8
IMAGE-BUILDING BEST PRACTICES
Image layering
With the docker image history command, you can look at the steps that were taken to build a Docker image—kind of like checking the recipe that was followed. Each line shows one layer that was added, along with the command that created it.

Run the following command in your terminal to see the different layers that make up your getting-started image: docker image history getting-started

This will show you a list of steps (layers) that were used to build the image, including things like which base image was used, any files copied, packages installed, and other commands run during the build. It's like looking at the construction steps of the image, from bottom to top.
You should get output that looks something like the following.

Each line you see is like a step in a recipe. The line at the bottom shows the base image (the starting point), and each line above it shows something that was added later. This view helps you understand how the image was built and lets you spot which parts take up the most space—so if your image is too big, you can figure out why.

You might see that some of the lines are cut short (truncated). If you want to see the whole thing without anything being cut off, you can add --no-trunc to the command. That way, all the details will be shown in full.

docker image history --no-trunc getting-started

Layer caching
Now that you’ve seen how the image layers work, here’s an important tip to make your builds faster: if one layer changes, everything built after it has to be rebuilt too.

Check out this Dockerfile you made for the getting started app to see how this happens.

Let’s go back to what the image history showed: every line in your Dockerfile becomes a separate layer in the image. You might’ve noticed that when you made a small change, like updating your app, Docker reinstalled all your packages again—even though they didn’t change. That’s a waste of time and effort.

Here’s how to fix it: rearrange your Dockerfile so Docker installs your dependencies before it copies the rest of your app code. For Node.js apps, this means:

a. First, copy in just the package.json file.
b. Then install the dependencies.
c. Finally, copy in the rest of the app.

By doing this, Docker will only reinstall packages if package.json changes, saving time during rebuilds.

Change the Dockerfile so that it first brings in the file that lists your app’s tools (package.json), installs those tools, and then adds the rest of your project files. This way, Docker won’t reinstall everything every time you make a small change to your code—it’ll only do that if the list of tools changes. # syntax=docker/dockerfile:1 FROM node:lts-alpine WORKDIR /app COPY package.json yarn.lock ./ RUN yarn install --production COPY . . CMD ["node", "src/index.js"]

Create a fresh version of your app’s image by running the docker build command. This tells Docker to put everything together based on your updated instructions.

docker build -t getting-started .
You should see output like the following.

Go to the src/static/index.html file and change the title of the page. For example, change it from whatever it is now to say: "The Awesome Todo App". This is just a small update to see your changes in action.

Now run the command to build your Docker image again:

docker build -t getting-started .

This time, the build process should be faster for some steps. That’s because Docker notices that some things didn’t change (like the dependencies), so it reuses them instead of redoing everything from scratch.

Multi-stage builds
Multi-stage builds are a smart way to break your image creation into steps. Here's what that means in simple terms:

You use one part to build the app, where you might need tools and libraries just to help create the final version.
Then, you create a second, much smaller part, where you only keep what the app needs to run, not all the extra tools used during building.

This approach helps you:

Keep things clean by not mixing build tools with your actual app.
Make your final image smaller, faster, and easier to share or deploy.

Maven/Tomcat example
When you're building Java apps, you need some heavy tools like the JDK (Java Development Kit) and build tools like Maven or Gradle to put your code together. But once your app is built, you don’t need those tools anymore to actually run the app.

So instead of putting everything into one image (which makes it big and messy), multi-stage builds let you use those tools only while building, and then leave them out of the final product. This way, your final app image is lighter, faster, and cleaner — it only contains what’s truly needed to run the app.

syntax=docker/dockerfile:1

FROM maven AS build
WORKDIR /app
COPY . .
RUN mvn package

FROM tomcat
COPY --from=build /app/target/file.war /usr/local/tomcat/webapps

In simple terms: this setup has two steps.

The first step (called build) uses Maven to put your Java app together.
The second step (starting with FROM tomcat) is where you take the finished app from the first step and place it into a clean, ready-to-run environment.

Only the second step ends up in the final Docker image, so the extra tools used during the build (like Maven) aren’t included in the final product. This keeps the image small and tidy.

If needed, you can also choose to stop after a certain step using the --target option.

React example
When you build a React app, you need Node.js to turn your code (like JSX and SASS) into regular files like HTML, JavaScript, and CSS that browsers can understand. This is called compiling.

But once that’s done, for running the app in production, you don’t need Node.js anymore. Instead, you can just serve those ready-made files using a simple web server like nginx inside a lightweight container. This keeps things faster and simpler.
`# syntax=docker/dockerfile:1
FROM node:lts AS build
WORKDIR /app
COPY package* yarn.lock ./
RUN yarn install
COPY public ./public
COPY src ./src
RUN yarn run build

FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html`

In the earlier example, the Dockerfile first uses a node image to build the app (which helps speed things up by reusing parts it already made), then it takes the finished files and puts them into a simple nginx web server container to run the app.

Summary

In this part, you learned some good tips for building images, like saving work with layer caching and using multi-step builds to make smaller, cleaner images.

How to Create and Configure a Virtual Network in Azure (The Easy Way via Azure Portal)

Kosisochukwu Ugochukwu — Tue, 29 Apr 2025 12:17:53 +0000

Introduction

If you're just getting started with Microsoft Azure, there's one foundational concept you will run into early: Virtual Networks, or VNets.

Think of a VNet as your own private network in the cloud — a space where your resources (like virtual machines, databases, and web apps) can securely talk to each other. In this guide, i will walk through how to create and configure one using the Azure Portal, no command-line knowledge required.

Let’s dive in.

💡 Why Virtual Networks Matter

When you spin up resources in Azure, you don’t want them floating around the internet without guardrails. A VNet gives you:

Isolation and segmentation of services
Control over IP address ranges, subnets, and routing
Integration with on-premises networks
The ability to set firewall rules using Network Security Groups (NSGs)

Basically, if you're building anything beyond a demo app, you will likely need a VNet.

🛠️ What You will Need

Before we get started, make sure you have:

A Microsoft Azure account
Access to the Azure Portal

🚧 Step 1: Create a Virtual Network

Let’s start by creating the VNet itself.

Log in to the Azure Portal Head over to https://portal.azure.com and sign in.

Search for “Virtual Networks” Use the search bar at the top of the portal, type Virtual Networks, and select the service from the dropdown.

Click “+ Create” to Start a New VNet

Fill in the Basics
Subscription: Choose the correct subscription
Resource Group: Create a new one (e.g., VNet-Demo-RG) and press ok or use an existing resource group

Name: Something like MyFirstVNet
Region: Pick the region closest to you

Set the IP Address Space

Click on IP addresses

The default should be something like 10.0.0.0/16, which is fine for now

Add your first subnet, e.g., Frontend with address range 10.0.0.0/24
Click on the pensil sign on default

change the name to Frontend. Explore the other default settings including the starting address, size and subnet address range and click on Save

Add your second subnet, e.g., Backend with address range 10.0.0.0/24
Click on the +Add a Subnet

Change the name to Backend. Explore the default settings and click on Add

Click through the Remaining Tabs

For now, you can skip advanced features like security and DNS unless you're familiar with them.
Click “Review + Create”, then Create

Deployment is complete

🔧 Step 2: Configure the VNet to use firewall

Now that your network exists, let’s do a little customization.

+Add More Subnets

Create a new Virtual Network: Go to the search box and type virtual network, on the dropdwon click on virtual network

Click on +Create

Use your active subcription, select
Resource group
Choose a name, and a region (prefferable same with the previous region used)

Click on IP addresses

Click on default

On the subnet purpose, click on the dropdown and click on Azure Firewall
Then click on save

Click “Review + Create”, then Create

Set Up VNet Peering

If you're working across multiple VNets (e.g., for isolation or region-based separation), peering connects them securely.

Just go to the Peerings section of your MyFirstVNet settings
Click +Add, and set up a peer with another VNet in your subscription.

On the remote virual network , peering link name should be MyFirstVbet-to-hub
On the virtual Network choose hub-vnet
Check the resource manager and also check the Allow 'hub-vnet to access MyFirstVNet'

On the local virual network , peering link name should be hub-to-MyFirstVNet
Check the resource manager and also check the Allow 'MyFirstVNet to access hub-vnet'
Then click on Add

To confirm the peering of the remote VNet and Local VNet was successfull, the peering state of the two VNet will show connected

🧭 Where to Go From Here

Now that your VNet is in place, here are a few things you might want to explore next:

Deploy a Virtual Machine into one of your subnets
Experiment with NSG rules to control traffic
Try connecting two VNets using peering
Set up a VPN Gateway to connect your VNet to an on-prem network

🔄 A Quick Word on VNet Peering
In the steps we went through, I mentioned something called Virtual Network Peering, but what does that actually mean?

Think of each Virtual Network (VNet) in Azure like a private neighborhood. By default, one neighborhood can’t talk to another even if you own both. VNet Peering is like building a secure road between two of your own neighborhoods, so that resources (like virtual machines or apps) in one can easily and privately communicate with those in the other.

It’s super useful when:

You want to organize resources into separate VNets (maybe for security or scaling reasons)
You have VNets in different regions but need them to work together
You’re building a hub-and-spoke network model

And the best part? The traffic between VNets stays private, it doesn’t go over the public internet.

So when you add a peering connection in Azure, you’re basically telling two of your networks, “Hey, you’re family now go ahead and talk to each other securely.”

💬 Final Thoughts

Getting hands-on with Azure networking doesn’t have to be intimidating. The Azure Portal makes it surprisingly straightforward to set up and customize a Virtual Network.

If this was helpful or if you want a follow-up guide on deploying VMs or setting up hybrid networks, let me know in the comments. Happy building!

🧵 Follow me for more beginner-friendly Azure and cloud development tutorials!

Introduction to Creating Web and Console Applications with C#

Kosisochukwu Ugochukwu — Fri, 21 Mar 2025 13:32:35 +0000

Introduction

C# is a versatile programming language used for various applications, including console and web applications. In this guide, we will walk through setting up Visual Studio Code (VS Code) for C# development and creating two simple applications: a console application and a web application.

A console application is a program that runs in a command-line interface (CLI) or terminal, allowing user interaction via text input and output. Console applications are commonly used for automation, testing, and simple utilities.

Requirements

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

Visual Studio Code (VS Code) - Download and install it from https://code.visualstudio.com/
.NET SDK - Download and install the latest .NET SDK from https://dotnet.microsoft.com/download

C# Extension for VS Code - Install it via the VS Code Extensions Marketplace

Setting Up VS Code for C#

Install VS Code and Required Extensions

Open VS Code.
Go to the Extensions Marketplace (Ctrl + Shift + X).
Search for "C# Dev Kit" and install the official C# extension by Microsoft.

Verify .NET Installation

On the upper left, click on view, on the dropdown click on terminal to Open a terminal in VS Code
Run the command: dotnet --version

If .NET is installed correctly, it outputs version number will show

Creating a Simple C# Web App with ASP.NET Core

Create a New web Project

Create a directory by opening a terminal in VS Code and run: mkdir (directory/folder name)

open the directory by running the command: cd (directory/folder name)

we have successfully created and opened a directory/folder

To create a new web application, give it a name put it inside new directory/folder, run the command: dotnet new web -n Mywebapp -o .

Breakdown of Flags:

dotnet new web → Creates a new ASP.NET Core web project.

-n Mywebapp → Specifies the name of the project (Mywebapp).

-o (or --output) → Specifies the output directory for the project files.

On the left side click on mywebapp on the dropdown click on program.cs Notice that this command has created a simple application for us called "Hello World"

This creates a new ASP.NET Core minimal web API.

Run the Web App by executing the following command: dotnet run
The output will show a URL (e.g., https://localhost:5065).

Open the URL in a web browser to see the web app running.

Modify the Web App Code

On the left up panel, click on mywebapp and on dropdown click on Program.cs to open and modify it as follows:

WebApplication.CreateBuilder(args) – Sets up a new web application.

builder.Build() – Builds the application instance.

app.MapGet("/", () => "Hello, Web!"); – Defines a route that returns "Hello, Web!

app.Run(); – Runs the web application.

Creating a Simple C# Console App

Create a new folder/diretory by running the command: mkdir (directory/folder name)

Open the directory/folder with the command: cd (directory/folder name)

To create a new console application, give it a name, put it inside new directory/folder, run the command: dotnet new console -n MyConsoleapptest -o .

To verify the console application created: on the left side, click on my-console, on the dropdown, then click on program.cs

Run the console app using the command: dotnet run

Modify the Console App Code

Open Program.cs and modify it as follows: Replace the "hello word!" with *"I am learning the foundation of c#" *
On the terminal run the command dotnet build and then followed by the command dotnet run

Running a kids maths game: In program.cs, write the kids maths game console c# code, then on the terminal run the command dotnet build and after that run the command dotnet run.

Now the kids maths game is running.

Difference Between a Console Application and a Web Application in C#

If you're new to programming, think of a console application as a calculator you use by typing commands, while a web application is like a website you visit in a browser.

Console Application (C#)

What is it?
A console application is a text-based program that runs inside a terminal or command prompt.

Example in real life: Imagine an old-school pocket calculator. You enter numbers, press a button, and it gives you a result. No fancy graphics, just text.
Where does it run? Runs on your computer using a command-line interface (like Command Prompt or Terminal).
How does the user interact? You type commands and see responses printed on the screen.

Web Application (C#)

What is it?
A web application is a program that runs inside a web browser and is accessed via the internet.

Example in real life: Imagine Facebook or Google, you open a website, click buttons, and interact with it.
Where does it run? It runs on a web server and users access it through a web browser (like Chrome, Edge, or Firefox).

Conclusion

We have successfully:

Installed VS Code and the required extensions.
Built and ran a basic web application using ASP.NET Core.
Created a simple C# console application and understood how it works.

From here, you can expand your project by adding more features and exploring C# development further!

Understanding Load Balancers: A Step-by-Step Guide in creating a load balancer in Azure

Kosisochukwu Ugochukwu — Fri, 14 Mar 2025 14:31:36 +0000

Introduction
What is a Load Balancer?

A load balancer is a tool used to spread incoming network traffic among several servers so as to prevent overload of any one server. Think of it as a traffic police officer who directs cars (data requests) to different open lanes (servers) to avoid congestion and delays.

Why is a Load Balancer Useful?

Improves Performance: It ensures faster response times by balancing the workload across multiple servers.
Ensures High Availability: If one server goes down, the load balancer redirects traffic to healthy servers, keeping applications running.
Enhances Security: It can protect against cyber-attacks like Distributed Denial-of-Service (DDoS) by distributing traffic efficiently.

Types of Load Balancers in Azure

Azure provides different types of load balancers to cater to various needs:

Azure Load Balancer (Layer 4 – Transport Layer): Used for distributing traffic within a Virtual Network.
Azure Application Gateway (Layer 7 – Application Layer): Provides additional features like SSL termination and routing traffic based on URL paths.
Azure Traffic Manager: Used for DNS-based traffic distribution across different geographic locations.
Azure Front Door: Optimized for web applications by routing traffic based on performance, security, and latency.

Step-by-Step Guide to Creating a Load Balancer in Azure

Step 1: Log in to Azure Portal

Open your web browser and go to Azure Portal.
Sign in using your Microsoft Azure account.

Step 2: Create a New Load Balancer

In the search bar at the top, type "Load Balancer" and select "Load Balancers" from the results.

Click "Create" to begin setting up your load balancer.

"notice the type on the left panel marked"

Step 3: Configure the Basic Settings

Subscription: Select your Azure subscription.
Resource Group: Choose an existing resource group or create a new one.
Region: Pick the Azure region where you want to deploy the load balancer.
Name: Provide a name for your load balancer (e.g., "MyLoadBalancer1").
SKU: Choose Standard, Gateway, or Basic (Standard is recommended for production use since it distributes traffic to backend resources).
Type: Select either Public (for internet-facing applications) or Internal (for internal network applications). For the purpose of this tutorial, we choose public
Tier: Select either Regional or Global
Click Next: Frontend IP Configuration.

Step 4: Configure the Frontend IP

Click + Add a frontend IP configuration."

Provide a name for the frontend IP.

Create a new Public IP if you are using a public load balancer or select Private IP for internal use.

Give the public address a name
Avaliability zone choose zone redundant or no zone
Click save
Click Next: Backend pools.

Step 5: Configure the Backend Pool

Click + Add a backend pool.

Give it a name (e.g., "BackendPool1").
On the Virtual network: Select Virtual Machines as the backend.
Add the Virtual Machines that will receive the traffic.

Click Next: Inbound rules.

Step 7: Configure Load Balancing Rules

Click + Add a load balancing rule.

Provide a name for the rule (e.g., "LBRule1").
Set the frontend IP configuration.
Choose the backend pool created earlier.
Select the protocol (TCP, or UDP).
Set the port (e.g., 80 for web traffic).

Health probe: Click create new

Give it a name (e.g., "HealthProbe").
Select the protocol (TCP, HTTP, or HTTPS).
Set a port (e.g., 80 for HTTP traffic).
Configure probe intervals (recommended: 5 seconds).
Then click save

Then click Review + Create.

Click Create to deploy your load balancer.

Deployment in progress

Step 8: Test the Load Balancer

Open a web browser or use a tool like curl to test the public IP of the load balancer.

If configured correctly, traffic will be distributed among backend virtual machines.

Conclusion

An Azure Load Balancer is a powerful tool for improving application speed, availability, and security. By following this step-by-step instruction, you will be able to successfully create and configure a load balancer to effectively control traffic in your Azure environment.

DEV Community: Kosisochukwu Ugochukwu

Deploy a .NET 8 App to Azure Kubernetes Service (AKS) – Tutorial Guide

A beginner-friendly guide to deploying a .NET app to the cloud using Docker and Kubernetes.

Test Your Setup

Step 1: Create the .NET Application

1.1 Set Up Project Structure

1.2 Initialize a .NET Project

1.3 Add Dependencies

1.4 Write the Application Code

1.5 Run and Test Locally

Step 2: Containerize Your Application

2.1 Create a Dockerfile

2.2 Create a .dockerignore File

2.3 Build and Test the Container

Step 3: Set Up Azure Infrastructure

3.1 Authenticate with Azure

3.2 Select Your Subscription

3.3 Create a Resource Group

3.4 Create a Container Registry (ACR)

3.5 Build & Push the Image to ACR

3.6 Create an AKS Cluster with ACR Integration

3.7 Connect to Your AKS Cluster

3.8 Verify ACR Integration (Optional)

Step 4: Create Kubernetes Configuration

4.1 Set Up a Manifests Directory

4.2 Create the Deployment

4.3 Create the Service

4.4 Deploy to Kubernetes

4.5 Troubleshooting Tips

Describe pod to see error details

Verify the image exists in ACR

Restart deployment (forces a new image pull)

Step 5: Set Up GitHub Actions CI/CD

5.1 Initialize Git Repository

5.2 Create Azure Service Principal

5.3 Create GitHub Repository

5.4 Configure GitHub Secrets

5.5 Create GitHub Workflow

5.6 Deploy Your Application

Step 6: Access Your Deployed Application

6.1 Get the External IP Address

6.2 Test Your Live Application

Step 7: Test Continuous Deployment

7.1 Make a Code Change

7.2 Push the Changes

7.3 Verify Auto-Deployment

Troubleshooting Guide

Clean Up Resources

Delete Kubernetes resources (Deployment + Service)

Delete AKS cluster

Delete Azure Container Registry (ACR)

Delete the entire resource group (removes AKS, ACR, etc.)

What we have Accomplished

📚 Next Steps

Azure Kubernetes Service (AKS) Deployment - Complete Guide Sheet

🛠️ The Full Stack DevOps Workshop

Understanding DevOps: Bridging Development and Operations

Hands-On Practice: Preparing Your DevOps Workspace

🔧 Before You Begin: Install Required Tools

Final Check: Make Sure Everything Works

Step 1: Set Up Git for Version Control

One-time Git Setup

Step 2: Build a Node.js Web App

1. Initialize Node.js Project

Step 3: Create Proper Tests

Creating Proper Tests

1. Create Tests Directory and File

2. Write Test Cases

Step 4: Add GitHub Actions for CI/CD

Fixed GitHub Actions CI/CD

Step 5: Create a Dockerfile

Creating a Dockerfile

1. Create Dockerfile

2. Add Dockerfile Content

Step 6: Essential Configuration Files

Essential Configuration Files

1. Create .dockerignore

2. Create .gitignore

3. Create .env.example

4. Create .eslintrc.js

1. Create `.dockerignore`

2. Create `.gitignore`