DEV Community: Kolarinde Awopetutimileyin

Containerizing a Full-Stack To-Do Application with Docker Compose (Node.js + MySQL)

Kolarinde Awopetutimileyin — Fri, 07 Aug 2026 10:48:18 +0000

A hands-on lab documenting the orchestration of a multi-container application using Docker Compose — from cloning source code to a live, database-backed web app.

Project Overview

This lab covers the containerization and orchestration of a multi-service web application using Docker Compose. The project clones a real-world Node.js to-do list application backed by a MySQL database, defines both services declaratively in a single compose.yaml file, and brings the entire stack online with one command — demonstrating core DevOps skills in container orchestration, service networking, and persistent data management. Two real configuration errors were also encountered and resolved along the way, since debugging is as much a part of the DevOps process as the happy path.

Tools & Technologies

Docker Desktop — container runtime and management UI
Docker Compose — multi-container orchestration (compose.yaml)
Node.js (node:22-alpine) — application server image
MySQL 8.0 — relational database with a persistent named volume
Git — cloning the application source from GitHub
VS Code + PowerShell — local development and terminal environment

Architecture at a Glance

The compose.yaml file defines two services on a shared Docker network: an app service built from the node:22-alpine image and exposed on port 3000, and a mysql service running MySQL 8.0 with its data persisted to a named volume (todo-mysql-data) so records survive container restarts. Environment variables provision the database root password and create the todos database automatically on first boot, letting the entire stack start with a single docker compose up command.

Step-by-Step Walkthrough

Step 1 — Clone the Application Source Code
Work began in a fresh DOCKER COMPOSE working directory inside VS Code. The first clone attempt used a malformed URL (missing the // after the protocol), which Git misread as an SSH host reference, producing a "Could not resolve hostname" error. Correcting the URL to a proper HTTPS format resolved the issue immediately.

git clone https://GitHub.com/dockersamples/todo-list-app   # failed — bad URL
git clone https://GitHub.com/dockersamples/todo-list-app   # corrected
cd todo-list-app

Troubleshooting note: git clone requires a well-formed protocol (https://); a single missing slash caused Git to treat the URL as an SSH remote instead of HTTPS.

Step 2 — Review the Docker Compose Configuration

With the source cloned, compose.yaml was opened to inspect the service definitions. The mysql service specifies a persistent named volume (todo-mysql-data) so database data isn't lost when the container restarts, along with environment variables that set the root password and auto-create the todos database on first startup.

Step 3 — Build and Start the Multi-Container Stack

Running docker compose up from the parent DOCKER COMPOSE folder failed with "no configuration file provided: not found", since Compose looks for compose.yaml in the current directory. Moving into the todo-list-app project folder and re-running the command resolved it: Compose pulled the node:22-alpine and mysql:8.0 images, created a dedicated network and volume, and started both containers successfully.

docker compose up -d --build     # failed — wrong directory
cd todo-list-app
docker compose up -d --build     # succeeded — 19/19 steps

Troubleshooting note: docker compose commands must be run from the directory containing compose.yaml (or with the -f flag pointing to it).

Step 4 — Verify the Running Containers in Docker Desktop

Switching to Docker Desktop's Containers view confirms the todo-list-app project group is live, with two healthy containers: app-1 running node:22-alpine and mapped to port 3000, and mysql-1 running mysql:8.0. Both show active CPU and memory usage, confirming the stack is up and communicating over its internal Docker network.

Step 5 — Test the Live Application

Finally, browsing to localhost:3000 confirms the full stack is working end-to-end: the Node.js frontend renders and reads/writes to-do items that are persisted in the MySQL container, with add, check-off, and delete actions all functioning against the live database.

Outcome

Starting from a cloned repository, this lab produced a fully functional, networked two-container application — a Node.js frontend and a MySQL database — orchestrated entirely through a single Docker Compose file and brought online with one command. Two realistic configuration errors were hit and resolved along the way, mirroring the kind of debugging that happens in real container deployments.

Skills Demonstrated

Cloning and configuring application source repositories with Git
Authoring and reading multi-service Docker Compose definitions
Container orchestration: networks, named volumes, and service dependencies
Environment-variable-driven database provisioning (MySQL)
Debugging common Docker CLI and Git configuration errors
Verifying containerized services through Docker Desktop and browser testing

From Local Node.js App to Automated AWS Deployment: A Full CI/CD Pipeline with GitHub Actions

Kolarinde Awopetutimileyin — Fri, 07 Aug 2026 09:16:14 +0000

Project Overview

This project documents a complete continuous deployment pipeline: a Node.js application built locally, pushed to GitHub, deployed onto a provisioned AWS EC2 instance, and finally automated so that every future git push triggers a hands-free deployment via GitHub Actions and SSH. It touches nearly every layer of a real DevOps workflow — app scaffolding, source control, cloud infrastructure, security groups, secrets management, and pipeline-as-code.

Skills demonstrated: Node.js/Express project scaffolding, Git version control, GitHub repository management, AWS EC2 provisioning, security group configuration, SSH key-based server access, GitHub Actions workflow authoring (YAML), GitHub Secrets management, automated remote deployment scripting, process management with PM2.

Screen-by-Screen Breakdown
Screen 1 — Scaffolding the Node.js Project

Initialized a new Node.js project from the command line, generating a package.json to track dependencies and scripts for the application.

Steps:

Create and enter the project directory: mkdir aws-cicd-lab && cd aws-cicd-lab.
Run npm init -y to generate a default package.json.
Confirm the file was created with the expected project metadata.
Screen 2 — Installing Express and Defining the Start Script

Added a start script to package.json and installed Express as the project's web framework, preparing the app to serve HTTP responses.

Steps:

Edit package.json to add "start": "node app.js" under scripts.
Run npm install express.
Confirm Express appears under dependencies in package.json.

Screen 3 — Verifying the App Locally

Ran the application locally and confirmed it served the expected response in the browser before pushing any code — catching issues early, before they reach the cloud.

Steps:

Run npm start (or node app.js) locally.
Open localhost:3000 in the browser.
Confirm the expected response renders ("CI/CD Deployment Successful!").

Screen 4 — Creating the GitHub Repository

Created a new public GitHub repository (node-app-actions) to host the project's source code and serve as the trigger point for the deployment pipeline.

Steps:

On GitHub, click New repository.
Set the Repository name (node-app-actions) and visibility (Public).
Leave README/.gitignore/license unchecked (added manually).
Click Create repository.

Screen 5 — Reviewing the Push Instructions

Reviewed GitHub's auto-generated command-line instructions for connecting a local repository to the newly created remote.

Steps:

Note the "push an existing repository from the command line" commands.
Copy the git remote add origin URL for use in the local terminal.

Screen 6 — Pushing the Local Repository to GitHub

Connected the local Git repository to the GitHub remote and pushed the initial commit, making the codebase available as the deployment source.

Steps:

Run git remote add origin https://github.com//node-app-actions.git.
Run git branch -M main.
Run git push -u origin main.
Confirm the push output shows objects written and the branch tracking origin/main.

⚠️ Security note: This repo push included vpc-key.pem — the EC2 private key — as a tracked file in a public repository. A private key committed to a public repo is a live credential exposure, not just a portfolio detail. Before publishing this project: rotate/replace the EC2 key pair in AWS, remove the file from Git history (git filter-repo or BFG Repo-Cleaner — deleting it in a new commit isn't enough, history still has it), and add *.pem to .gitignore going forward. The project later handles the SSH key correctly via GitHub Secrets (Screens 15–16) — the same discipline should apply here too.

Screen 7 — Launching the EC2 Instance

Began provisioning a new AWS EC2 instance (nodeApp) using a free-tier-eligible Ubuntu 24.04 LTS image as the deployment target.

Steps:

In the AWS Console, go to EC2 → Launch an instance.
Set the Name (nodeApp).
Under Quick Start, select Ubuntu → Ubuntu Server 24.04 LTS.
Confirm the instance summary (AMI, instance type) before continuing.

Screen 8 — Configuring Network Settings and Security Group

Configured the instance's network settings, creating a new security group (node-app-nsg) with explicit inbound rules for SSH (port 22) and HTTP (port 80).

Steps:

Under Network settings, confirm the VPC and subnet.
Choose Create security group and name it (node-app-nsg).
Add an inbound rule: Type SSH, Port 22, Source Anywhere (or restrict to your IP for better security).
Add a second inbound rule: Type HTTP, Port 80.
Click Launch instance.

Screen 9 — Confirming the Instance Is Running

Verified the new EC2 instance launched successfully, noting its public IP, instance type, and associated VPC/subnet details.

Steps:

Open EC2 → Instances and select the new instance.
Confirm Instance state shows Running.
Note the Public IPv4 address and Instance type (t3.micro) for later use.

Screen 10 — Retrieving the SSH Connect Command

Used the EC2 console's built-in Connect panel to generate the correct SSH command for accessing the instance, referencing the downloaded private key.

Steps:

Select the instance and click Connect.
Open the SSH client tab.
Note the chmod 400 command to secure the key file's permissions.
Copy the generated SSH command (ssh -i ".pem" ubuntu@).

Screen 11 — Connecting to the Instance via SSH

Established an SSH session into the EC2 instance from the local terminal, confirming a clean Ubuntu boot with no pending critical issues.

Steps:

In the local terminal, run the copied SSH command with the correct key path.
Confirm the Ubuntu welcome banner and system status appear.
Note the instance's internal IP for reference.

Screen 12 — Preparing the Server (Nginx & SSH Keys)

Enabled and started Nginx on the instance as a base web-facing service, then inspected the server's SSH key configuration to confirm what was authorized for access.

Steps:

Run sudo systemctl enable nginx.
Run sudo systemctl start nginx.
Inspect ~/.ssh/authorized_keys to confirm the expected public key is present.

Screen 13 — Navigating to Repository Settings

Opened the GitHub repository's Settings tab to begin configuring the secrets that GitHub Actions would need to deploy to the EC2 instance securely.

Steps:

Open the repository on GitHub.
Click the Settings tab.
Locate Secrets and variables in the left sidebar.

Screen 14 — Opening Actions Secrets

Navigated into the Actions secrets section, where sensitive deployment values (host, username, private key) would be stored securely rather than hardcoded into the workflow file.

Steps:

Under Secrets and variables, click Actions.
Confirm the Actions secrets panel is ready to accept new entries.

Screen 15 — Adding the VM_HOST Secret

Stored the EC2 instance's public IP as a GitHub Actions secret (VM_HOST), so the deployment workflow could reference it without exposing it in the codebase.

Steps:

Click New repository secret.
Set Name to VM_HOST.
Set Secret to the EC2 public IP address.
Click Add secret.

Screen 16 — Preparing the SSH Private Key for a Secret

Opened the EC2 private key file to copy its full contents, in preparation for storing it as a GitHub Actions secret (VM_SSH_KEY) rather than committing it to the repo.

Steps:

Open the .pem key file in a text editor.
Select and copy the entire contents, including the BEGIN/END RSA PRIVATE KEY lines.
Paste the full key into a new GitHub secret named VM_SSH_KEY.

This is the correct way to handle the private key — as a GitHub Secret, never as a tracked file. It's worth applying the same standard retroactively to Screen 6.

Screen 17 — Scaffolding the GitHub Actions Workflow

Created the folder structure GitHub Actions requires (.github/workflows/) and an empty workflow file to hold the deployment pipeline definition.

Steps:

From the project root, run mkdir .github.
Run mkdir workflows inside it, then cd workflows.
Run touch deploy.yml to create the workflow file.

Screen 18 — Writing the Deployment Job

Authored the core deployment step using the appleboy/ssh-action, referencing the GitHub Secrets to SSH into the EC2 instance and run a deploy script — cloning on first run, pulling and restarting via PM2 on subsequent runs.

Steps:

Define a deploy job under jobs:.
Add a step using uses: appleboy/ssh-action@v0.1.10.
Reference secrets.VM_HOST, secrets.VM_USER, and secrets.VM_SSH_KEY under with:.
Write the deploy script: — conditionally clone the repo, then git pull, npm install, and restart via pm2 restart app || pm2 start app.js --name app.
Screen 19 — Adding the Checkout Step and Triggering the Pipeline

Completed the workflow with a trigger (on: push) and a checkout step, then committed and pushed the workflow file — which immediately kicked off the first automated deployment.

Steps:

Add on: push: at the top of the workflow to trigger on every push to the branch.
Add a Checkout Code step using actions/checkout@v3.
Run git add .github/, git commit -m "added aws workflow file", and git push origin main.
Watch the Actions tab on GitHub to confirm the workflow runs and deploys successfully.

Azure Network Foundations: Provisioning a Secure VNet, NSG-Governed Subnets & SSH-Accessible Linux VM

Kolarinde Awopetutimileyin — Fri, 07 Aug 2026 07:39:51 +0000

Project Overview

This project documents the foundational networking layer that most Azure workloads sit on top of: a Virtual Network (VNet), address-space planning via subnets, and traffic control through Network Security Groups (NSGs). It closes the loop by provisioning a Linux virtual machine into that network and connecting to it over SSH — proving the network, security rules, and compute layer all work together end to end.

Skills demonstrated: VNet and subnet design (CIDR planning), Network Security Group configuration, inbound/outbound rule prioritization, custom SSH access rules, VM provisioning with SSH key-pair authentication, NIC-to-subnet association, public IP assignment, secure remote access verification.

Screen-by-Screen Breakdown
Screen 1 — Creating the Virtual Network

Provisioned a new Virtual Network (KOLAVN_RG) inside a dedicated resource group, establishing the foundational address space that all subnets and resources in this project would live inside.

Steps:

Navigate to Virtual networks → Create virtual network.
Under Project details, create a new resource group (KOLAVN_RG).
Under Instance details, name the virtual network and select the region (West US).
Move to the IP addresses tab to configure the address space.

Screen 2 — Configuring the First Subnet

Defined the first subnet (kola_subnet) within the VNet's address space, setting a /24 range to segment part of the network for later resource placement.

Steps:

On the IP addresses tab, click Add a subnet.
Name the subnet (kola_subnet).
Confirm the IPv4 address range (10.0.0.0/16) and set the starting address (10.0.1.0).
Set the subnet size (/24, 256 addresses).
Click Add, then proceed to Review + create.

Screen 3 — Confirming the VNet Deployment

Verified the Virtual Network deployment completed successfully before moving on to add further subnets and security configuration.

Steps:

Wait for the deployment to finish.
Confirm the green "Your deployment is complete" status.
Click Go to resource to open the new VNet.

Screen 4 — Reviewing Subnets Before Adding Security

Checked the VNet's subnet list after adding a second subnet (kola_sub2), noting that neither subnet yet had a Network Security Group attached — flagging the next task.

Steps:

Open the VNet and go to Settings → Subnets.
Review the subnet list: names, IPv4 ranges, and available IPs.
Note the Security group column is empty for both subnets — this is the gap to close next.

Screen 5 — Navigating to Network Security Groups

Used the global Azure search to jump directly to the Network Security Groups service, in preparation for creating and attaching a security boundary to the subnets.

Steps:

Click the top search bar in the Azure Portal.
Search "network security group."
Select Network security groups from the Recent services list.

Screen 6 — Reviewing the Network Security Group's Default Rules

Opened the newly associated NSG (kolaweb) and reviewed its default inbound and outbound rules — the baseline Azure applies automatically (allow VNet traffic, allow Azure Load Balancer, deny everything else by default).

Steps:

Open the NSG resource (kolaweb).
Review Essentials: resource group, location, subscription.
Review the default Inbound Security Rules (AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound) and Outbound Security Rules.
Navigate to Settings → Inbound security rules to add a custom rule.

Screen 7 — Opening Inbound Security Rules

Confirmed the current inbound rule set before adding a custom rule to explicitly allow SSH traffic to the VM that would later sit behind this
NSG.

Steps:

Go to Settings → Inbound security rules.
Review existing default rules and priorities.
Click + Add to create a new custom rule.

Screen 8 — Adding a Custom SSH Inbound Rule

Created a dedicated inbound rule permitting SSH traffic (TCP port 22), explicitly named and documented so the rule's purpose would be clear to anyone auditing the NSG later.

Steps:

In Service, select SSH (auto-fills TCP port 22).
Set Protocol to TCP and Action to Allow.
Set Priority (e.g. 100) — lower numbers are evaluated first.
Name the rule (SSH_NETWORK) and add a description ("Connect SSH network").
Click Add to save the rule.

Screen 9 — Starting Virtual Machine Creation

With the network and security layer in place, began provisioning a virtual machine to deploy into the secured subnet.

Steps:

Navigate to Virtual machines under Compute infrastructure.
Confirm no existing VMs are listed.
Click + Create to start the VM creation wizard.

Screen 10 — Configuring VM Basics

Configured the core VM settings: name, region, a cost-efficient Ubuntu image and size, and SSH public-key authentication instead of a password for secure, auditable access.

Steps:

Set Virtual machine name (KOLA-VM) and Region (West US).
Choose the Image (Ubuntu Server 24.04 LTS) and Size (Standard_D2s_v3).
Set Authentication type to SSH public key.
Set the Username (azureuser) and Key pair name (KOLA-VM_key).
Set Public inbound ports to None (access will be governed by the NSG rule instead).

Screen 11 — Attaching the VM to the Secured Subnet

Connected the VM's network interface to the previously created VNet and subnet, assigned a new public IP, and applied the NSG containing the SSH rule — tying the whole project together at the networking layer.

Steps:

Go to the Networking tab.
Confirm Virtual network (KOLAVN_RG) and select Subnet (kola_subnet, 10.0.1.0/24).
Confirm a new Public IP will be created.
Set NIC network security group to Basic (or Advanced to select the custom NSG directly).
Leave accelerated networking enabled for better throughput, then click Review + create.

Screen 12 — Validating and Generating the SSH Key Pair

Passed validation on the VM configuration and generated a new SSH key pair, downloading the private key — the only copy, since Azure does not retain it after generation.

Steps:

Confirm "Validation passed" at the top of the Review + create tab.
Review the configuration summary (resource group, VM name, region, security type).
In the Generate new key pair dialog, click Download private key and create resource.
Store the downloaded .pem file securely — it cannot be re-downloaded later.

Screen 13 — Connecting to the VM via Native SSH

Used the Azure Portal's built-in Connect blade to generate and run the correct SSH command, pointing to the downloaded private key, to establish a secure remote session into the new VM.

Steps:

Open the VM and go to Connect → Connect.
Select Native SSH, and confirm the destination VM's public IP and port (22).
Provide the local path to the downloaded private key file.
Copy the generated SSH command (ssh -i "" azureuser@).
Run it in a local terminal to connect.

Deploying and Exposing a Scalable NGINX Web Service on Azure Kubernetes Service (AKS)

Kolarinde Awopetutimileyin — Fri, 07 Aug 2026 05:44:05 +0000

Project Overview

This lab demonstrates a complete, production-style workflow for standing up a containerized web application on Microsoft Azure using Azure Kubernetes Service (AKS). It covers cluster provisioning via the Azure CLI, secure node authentication, namespace-based workload isolation, application deployment, and public exposure through a cloud-native Load Balancer — the same pattern used to ship containerized services in real DevOps environments.
The objective was to take a project from a completely empty Azure subscription to a live, internet-reachable NGINX service, while documenting every command and its output for reproducibility and portfolio presentation.

Tools & Technologies

Microsoft Azure — Resource Groups, Azure Kubernetes Service (AKS), Load Balancer, Virtual Machine Scale Sets
Azure CLI (az) — cluster and resource provisioning
Kubernetes / kubectl — namespace, deployment, and service management
NGINX — containerized workload deployed to the cluster
VS Code + PowerShell — local development and terminal environment
SSH (ED25519) — secure node authentication

Architecture at a Glance
A resource group (kolakub-RG) hosts the AKS control plane, while Azure auto-generates a companion managed resource group (myNodeRG) containing the underlying VM Scale Set, virtual network, network security group, and Load Balancer that back the cluster's worker nodes. Inside the cluster, a dedicated frontend namespace isolates the NGINX deployment, which is exposed externally through a Kubernetes Service of type LoadBalancer.

Step-by-Step Walkthrough

STEP 1 Generate an SSH Key Pair for Node Authentication

he command produced a private key (aks-ssh) and a public key (aks-ssh.pub), which is later injected into the AKS cluster so nodes can be reached over SSH without password authentication.

Every AKS Linux node needs an SSH key for secure administrative access. Working inside the LAB-1 project folder in VS Code's PowerShell terminal, a dedicated .ssh directory was created, followed by an ED25519 key pair generated specifically for this cluster.

STEP 2 Create a Resource Group

Before any Azure resource can be provisioned, it needs a resource group to live in. The subscription was first checked for existing groups, then a new one — kolakub-RG — was created in the West US region.

The returned JSON confirms the resource group was created successfully and is ready to host the AKS cluster

STEP 3 Provision the AKS Cluster

With the resource group in place, the AKS cluster itself — MyAKSCluster — was provisioned using az aks create. The configuration defines a single-node systemp nodepool on Standard_D2s_v3 VMs, injects the previously generated SSH public key, uses the Azure CNI network plugin, and enables the cluster autoscaler (scaling between 1 and 2 nodes) so the workload can grow automatically under load.

Azure CLI streams back the complete cluster definition, confirming settings such as autoscaling, node pool profile, and orchestrator version once provisioning completes.

STEP 4 Verify the Cluster in the Azure Portal

Switching to the Azure Portal confirms the cluster was created successfully outside the CLI as well. Inside kolakub-RG, MyAKSCluster appears with resource type "Kubernetes service", deployed to the West US region.

STEP 5 Inspect the Auto-Generated Node Resource Group
AKS automatically creates a second, system-managed resource group (myNodeRG) to hold the infrastructure backing the cluster's nodes. Reviewing it surfaces the public IP address, the network security group, the virtual machine scale set running the actual worker node(s), the virtual network, the Load Balancer, and the managed identity used by the cluster.

This separation keeps user-managed resources (kolakub-RG) cleanly apart from Azure-managed cluster infrastructure (myNodeRG).

STEP 6 Create an Isolated Namespace

To keep the application workload logically separated from system components, a dedicated frontend namespace was created using kubectl, then verified against the cluster's full namespace list.

STEP 7 Deploy the NGINX Application

With the namespace ready, an NGINX deployment was rolled out into frontend. Checking the default namespace first confirms no resources exist there — the workload is correctly scoped — while querying across all namespaces and then filtering to frontend shows the deployment running with all 3 replicas ready and available.

STEP 8 Expose the Deployment with a LoadBalancer Service

To make the NGINX deployment reachable from outside the cluster, it was exposed as a Kubernetes Service of type LoadBalancer, mapping external port 80 over TCP to the pods.

STEP 9 Connect kubectl to the Cluster & Confirm Node Health

To manage the cluster from the local machine, its credentials were merged into the local kubeconfig with az aks get-credentials. A quick kubectl get node confirms the worker node is Ready and running Kubernetes v1.34.6.

STEP 10 Validate Public Access via the External IP

The final check confirms the service is live on the public internet. Querying the frontend namespace's services shows nginx-service of type LoadBalancer with an assigned EXTERNAL-IP, reachable on port 80 — proof the NGINX application is now publicly accessible.

From Commit to Cloud: CI/CD Deployment of a PHP eLearning Platform to Azure App Service via GitHub Actions

Kolarinde Awopetutimileyin — Thu, 06 Aug 2026 16:49:22 +0000

Project Overview

This project documents a complete CI/CD deployment loop for a PHP-based eLearning platform. It starts at the very beginning—initializing version control on a local project—and follows the code through GitHub into an Azure Web App wired for continuous deployment, ending with a live, publicly accessible site verified in the browser. It's a practical demonstration of how source control, cloud hosting, and automated build pipelines connect into a single working system.

Skills demonstrated: Git version control fundamentals (init, add, and status); GitHub repository management; Azure App Service provisioning; GitHub-to-Azure Deployment Center integration; GitHub Actions build pipelines; PHP runtime configuration on Linux App Service; deployment log verification; and live production validation.

Screen-by-Screen Breakdown
Screen 1 — Initializing Git and Staging the Project

Initialized a local Git repository inside the eLearning project folder in VS Code and staged all project files — HTML/PHP pages, styles, scripts, and assets — for the first commit.

Steps:

Open the project folder (elearning) in VS Code.
Open the integrated terminal and run git init to create a local repository.
Run git add . to stage all files.
Note the LF-to-CRLF line-ending warnings (expected on Windows; Git will normalize line endings automatically — not an error).

Screen 2 — Reviewing Git Status Before the First Commit

Verified exactly which files were staged before committing, confirming the full project structure — PHP pages, CSS, images, and library assets — was ready to be tracked.

Steps:

Run git status to review staged changes.
Confirm the branch is master with no commits yet.
Review the full list of new files under "Changes to be committed."
Proceed to git commit and set up the remote origin (not pictured, but the natural next step).

Screen 3 — Pushing the Repository to GitHub

Pushed the committed project to a public GitHub repository (kolarinde/kola-elearning), making the source code available as the deployment source for Azure.

Steps:

Create a new repository on GitHub (kola-elearning).
Add it as a remote: git remote add origin .
Push the code: git push -u origin master.
Confirm the files appear on GitHub under the master branch with the commit message "Adding code files."

Screen 4 — Provisioning the Azure App Service

Created and reviewed the Azure Web App (kolaAPP2), confirming it was running on a Linux-based App Service Plan in West US 3, with the GitHub repository already linked as its project source.

Steps:

In the Azure Portal, navigate to App Services and open the Web App (kolaAPP2).
Review the Overview blade: resource group, default domain, status, App Service plan, region, and OS.
Confirm the GitHub project link matches the intended repository.

Screen 5 — Connecting Azure to GitHub via Deployment Center

Configured the Deployment Center to source code directly from GitHub, selecting the correct organization, repository, and branch, with GitHub Actions as the build provider and PHP as the runtime stack.

Steps:

Open Deployment → Deployment Center on the Web App.
Set the source to GitHub and authorize the connection.
Select the GitHub organization (kolarinde), repository (kola-elearning), and branch (master).
Confirm the build provider is set to GitHub Actions and the runtime stack to PHP.
Save — Azure automatically generates a GitHub Actions workflow file in the repository.

Screen 6 — Verifying the GitHub Actions Deployment Log

Confirmed the automated deployment triggered by the GitHub Actions workflow completed successfully, reviewing the deployment log entry for status and timing.

Steps:

In Deployment Center, open the Logs tab.
Locate the latest deployment entry by date.
Confirm Status shows "Succeeded," and the log source is linked to the app logs.
Click into the log entry for full build/deploy details if troubleshooting is needed.

Screen 7 — Validating the Live Deployed Application

Opened the live Azure-hosted domain in the browser to confirm the eLearning platform deployed correctly, rendering the full site—navigation, course cards, and imagery—from the automated pipeline.

Steps:

Copy the App Service default domain from the Overview blade (*.azurewebsites.net).
Open it in a new browser tab.
Verify the site renders correctly: navigation, hero content, and course listings.
Spot-check a few pages/links to confirm assets (CSS, images) loaded correctly from the deployed build.

Infrastructure as Code: Modular Multi-Resource Azure Deployment with ARM Templates & CLI

Kolarinde Awopetutimileyin — Thu, 06 Aug 2026 06:41:03 +0000

Project Overview

This project documents a modular Azure deployment pipeline built entirely through the Azure CLI and ARM (Azure Resource Manager) templates in VS Code. Each Azure resource — Key Vault, Storage Account, and Web App — was isolated into its own project folder with dedicated template.json and parameters.json files, deployed into its own resource group. The walkthrough also captures genuine debugging moments: resolving a missing-file path error and repeated DNS/connectivity failures against management.azure.com, both handled through methodical retries rather than guesswork.

Skills demonstrated: ARM template authoring & parameterization, Azure CLI deployment workflows (az group create, az deployment group create), resource group isolation per workload, working-directory/path troubleshooting, transient network error diagnosis and recovery, modular Infrastructure-as-Code project structure.

Screen-by-Screen Breakdown
Screen 1 — Verifying Azure Session & Provisioning the Key Vault Resource Group

Confirmed the active Azure CLI session and subscription context before provisioning, then worked through a transient DNS resolution failure on a listing command to successfully create a dedicated resource group for the Key Vault module.

Steps:

Open the integrated PowerShell terminal in VS Code.
Run az account list to confirm the active subscription, tenant, and signed-in user.
Run az group list to check existing resource groups (encountered a transient getaddrinfo failed DNS error against management.azure.com).
Run az group create -n key-rg -l westus3 to provision a new resource group scoped to the Key Vault deployment.
Confirm success via the returned JSON ("provisioningState": "Succeeded").

Screen 2 — Deploying the Key Vault ARM Template

Deployed a parameterized ARM template into key-rg, first resolving a working-directory mismatch, then supplying required parameters interactively and retrying past a transient connectivity error until the Key Vault deployment completed.

Steps:

Attempt az deployment group create --resource-group key-rg --template-file template.json from the ARM-Templates root — fails (No such file or directory: 'template.json').
Run cd keyvault to move into the correct template directory.
Re-run the deployment command; the CLI interactively prompts for required parameters (vaultName, keyName).
Supply parameter values (e.g. nazarethvault, nazarethkey).
Retry after a transient DNS/connection error.
Confirm the successful deployment output, showing the dependency on Microsoft.KeyVault/vaults/nazarethvault.

Screen 3 — Provisioning and Deploying the Storage Module

Created a second, isolated resource group for the storage workload, pushed through repeated transient Azure Resource Manager connectivity errors, and deployed the storage ARM template from its own dedicated directory.

Steps:

Run az group create -n storageRG -l "westus3" — retried after two consecutive DNS resolution failures.
Confirm resource group creation ("provisioningState": "Succeeded").
Navigate out of the previous module and into the storage template folder: cd .. then cd storage-lab.
Run az deployment group create --resource-group storageRG --template-file storage.json.
Retry through further transient connection errors until the deployment succeeds.
Confirm the deployment output (deployment name: storage).

Screen 4 — Modular Project Structure & Web App Parameters

Organized the full IaC project into clean, per-resource folders and configured the Web App module's parameters file ahead of deployment, keeping each resource's template and parameter definitions self-contained.

Steps:

Structure the root ARM-Templates project into isolated subfolders: keyvault, storage-lab, webapp.
Open webapp/parameters.json.
Define parameter values, including webAppName (e.g. ChlarityApp43564) and appServicePlanName.
Review the terminal history confirming the prior successful Key Vault and Storage deployments.
Proceed to deploy the Web App module using the same az deployment group create --resource-group --template-file template.json` pattern.

Provisioning and Securing Azure Blob Storage: End-to-End Deployment Walkthrough

Kolarinde Awopetutimileyin — Wed, 05 Aug 2026 21:08:53 +0000

Project Overview

This project documents the full lifecycle of setting up an Azure Blob Storage solution — from creating the storage account through to uploading and publishing a file for public access. It covers core Azure concepts: resource groups, storage redundancy tiers, container-level access control, and blob-level configuration, all performed directly through the Azure Portal.

Skills demonstrated: Azure Storage Account provisioning, resource group management, data redundancy strategy (LRS), storage configuration (TLS, access tiers, anonymous access policy), container and blob lifecycle management, access-level security controls.

Screen 1 — Creating the Storage Account

Configured a new storage account (kolastorage1) under a dedicated resource group (kola_storage) in the West US 3 region. Selected Blob Storage as the preferred storage type with Standard performance and Locally-Redundant Storage (LRS) for cost-efficient redundancy.

Steps:

Navigate to Create a storage account in the Azure Portal.
Select the subscription and create/select a resource group (kola_storage).
Enter a unique storage account name (kolastorage1).
Choose the region (West US 3).
Set Preferred storage type to Azure Blob Storage / Data Lake Storage Gen2.
Choose Standard performance and Locally-redundant storage (LRS) for redundancy.
Click Review + create.

Screen 2 — Reviewing and Deploying

Reviewed all configuration settings against the defaults before confirming deployment, ensuring the resource group, region, and redundancy settings matched the project plan prior to provisioning.

Steps:

On the Review + create tab, verify Subscription, Resource group, Location, and Storage account name.
Confirm Performance and Replication settings.
Click Create to trigger deployment.
Wait for the "Initializing deployment" confirmation.

Screen 3 — Configuring Storage Account Settings

Adjusted account-level configuration, enabling Blob anonymous access and storage account key access to support later public blob access, and set the default access tier to Cool for infrequently accessed data.

Steps:

Open the storage account and go to Settings → Configuration.
Enable Allow Blob anonymous access.
Enable Allow storage account key access.
Set Minimum TLS version to 1.2 for secure transport.
Set Blob access tier (default) to Cool.
Click Save.

Screen 4 — Setting Redundancy

Confirmed the storage redundancy configuration under the Redundancy blade, verifying Locally-Redundant Storage (LRS) was applied and the primary data center (West US 3) was active and available.

Steps:

Go to Data management → Redundancy.
Confirm or update the redundancy option (LRS).
Review the storage endpoint location and status.
Click Save.

Screen 5 — Creating a Blob Container

Created a new container (kolastorage) within the storage account to logically organize blob data, setting the initial anonymous access level to private.

Steps:

Go to Data storage → Containers.
Click + Add container.
Enter a container name (kolastorage).
Click Create.

Screen 6 — Verifying Container Creation

Confirmed the new container appeared alongside the default $logs container, with private access level and available lease state, validating successful creation.

Steps:

Go to Containers under Data storage.
Confirm the new container is listed.
Select it to proceed to container-level settings.

Screen 7 — Opening Container Access Controls

Opened the container's management pane to review upload options and access-level controls before publishing content.

Steps:

Open the container (kolastorage).
Review the toolbar options: Add Directory, Upload, Change access level.
Click Change access level to proceed.

Screen 8 — Setting Public Blob Access

Changed the container's anonymous access level to allow public read access to individual blobs, while keeping the container listing itself private — a common pattern for publishing static assets without exposing the full container index.

Steps:

In Change access level, set Anonymous access level to "Blob (anonymous read access for blobs only)".
Click OK to apply.

Screen 9 — Uploading a Blob

Uploaded a file into the container using the drag-and-drop upload panel, making it available for storage and later retrieval via a public URL.

Steps:

Click Upload in the container toolbar.
Drag and drop the file, or browse to select it.
Click Upload to complete the transfer.

Screen 10 — Verifying the Uploaded Blob

Confirmed the uploaded file was stored correctly by inspecting its blob properties, including size, content type, access tier, and public URL — validating the file was live and accessible.

Steps:

Select the uploaded blob from the container list.
Review properties: URL, size, access tier, content type.
Copy the blob URL to test/share public access.

Creating and Attaching an Amazon EBS Volume to an EC2 Instance on AWS

Kolarinde Awopetutimileyin — Mon, 27 Jul 2026 17:26:11 +0000

Step 1 — Open the EC2 Console

From the AWS EC2 dashboard, click Launch instance to begin creating a new virtual server that will later have an EBS volume attached.

Step 2 — Name the Instance and Choose an AMI

On the Launch an instance page, name the instance (e.g. "EBS-SERVER") and select an Amazon Machine Image — in this case, Amazon Linux 2023.

Step 3 — Configure Key Pair and Network Settings

Select or create a key pair (e.g. "ebs-key") for SSH access. Under Network settings, confirm the VPC and subnet, enable auto-assign public IP, and allow SSH traffic from Anywhere (or a restricted IP range) via the security group.

Step 4 — Review Storage and Launch the Instance

In Configure storage, keep the default root volume (8 GiB, gp3). Leave file systems set to None (since the EBS volume will be attached separately), review the launch summary, and click Launch instance.

Step 5 — Confirm the Instance Is Running

On the Instances page, confirm the new instance ("EBS-SERVER") shows a Running state with status checks passed.

Step 6 — Navigate to EBS Volumes

Under Elastic Block Store > Volumes, view existing volumes and click Create volume to provision a new EBS disk.

Step 7 — Configure the New Volume

Set the volume type (General Purpose SSD gp3), size (e.g. 4 GiB), IOPS, and throughput. Choose the same Availability Zone as your EC2 instance (critical — EBS volumes can only attach to instances in the same AZ), then create the volume.

Step 8 — Attach the Volume via Actions Menu

Back in the Volumes list, select the new volume's checkbox, click Actions, and choose Attach volume to link it to the running instance.

Step 9 — Complete Attachment Details

On the Attach volume page, confirm the Volume ID and Availability Zone match, select the target instance ("EBS-SERVER"), specify a device name (e.g. /dev/sdb), and click Attach volume.

Step 10 — Connect to the Instance

From the Instances page, select "EBS-SERVER" and click Connect to proceed to SSH connection setup.

Step 11 — Locate the Private Key

In your local editor (e.g. VS Code), open the downloaded private key file ("EBS-KEY.pem") to confirm it's accessible and ready to use for the SSH connection.

Step 12 — Copy and Run the SSH Command

Under the SSH client tab, follow the steps to set correct key permissions (chmod 400 "EBS-KEY.pem") and copy the SSH command (e.g. ssh -i "EBS-KEY.pem" ec2-user@ec2-18-232-77-8.compute-1.amazonaws.com) to connect to the instance and verify the attached EBS volume from within the OS.

Provisioning an Amazon EFS File System and Mounting It to an EC2 Instance on AWS

Kolarinde Awopetutimileyin — Sat, 25 Jul 2026 00:06:33 +0000

Step 1 — Create the EFS File System

In the Amazon EFS console, click Create file system, name it (e.g. "kola-fs"), and select the target VPC. Review the recommended settings — Elastic throughput mode, lifecycle transitions to Infrequent Access and Archive, automatic backups, and encryption — then click Create file system.

Step 2 — Confirm File System Creation

A success banner confirms the file system ("kola-fs") is Available, showing its file system ID, encryption status, size, and creation time in the File systems list.

Step 3 — Launch an EC2 Instance

On the EC2 Launch an instance page, name the instance (e.g. "KOLA-SERVER"), select an Amazon Machine Image (Amazon Linux 2023), choose the instance type (t3.micro), and select or create a key pair (e.g. "EBS-KEY") for SSH access.

Step 4 — Configure Storage and Attach EFS

Under Configure storage, keep the default root volume settings. In the File systems section, select EFS as the file system type to attach to this instance.

Step 5 — Review the EFS Network and Mount Targets

On the EFS file system's detail page, check the Network tab to confirm mount targets are Available across each availability zone, along with their subnet IDs, IP addresses, and associated security groups — necessary for EC2 to connect.

Step 6 — Configure Network Settings for the Instance

Back in the EC2 launch wizard, under Network settings, confirm the VPC and subnet match the EFS file system's network, enable auto-assign public IP, and configure the security group to allow inbound SSH (port 22) traffic.

Step 7 — Set the File System and Mount Point

In the File systems configuration panel, select the EFS file system (kola-fs) and specify the mount point (e.g. /mnt/efs/fs1). Leave "Automatically create and attach security groups" and "Automatically mount shared file system" checked so EFS attaches on launch.

Step 8 — Launch the Instance

Review the configuration summary and click Launch instance to provision the EC2 server with the EFS file system attached.

Step 9 — Confirm Successful Launch

A success message confirms the instance launch, with a link to the new instance ID for further management.

Step 10 — Open the Instance Summary

On the instance details page, confirm the instance ("KOLA-SERVER") is Running, and note its public IPv4 address and public DNS. Click Connect to proceed to SSH connection setup.

Step 11 — Get the SSH Connection Command

Under the SSH client tab, follow the steps to locate your private key file, set correct permissions (chmod 400), and copy the example SSH command (e.g. ssh -i "EBS-KEY.pem" ec2-user@).

Step 12 — Connect and Verify the EFS Mount

In a local terminal (e.g. VS Code), run the SSH command to connect to the instance. Once connected, run df -T to confirm the EFS file system is mounted (visible as an nfs4 filesystem type under /mnt/efs/fs1), verifying the EC2 instance has successful shared storage access.

Deploying a Kubernetes Application on Azure Kubernetes Service (AKS): From Cluster Creation to Live Deployment

Kolarinde Awopetutimileyin — Fri, 24 Jul 2026 22:21:25 +0000

Step 1 — Create a Resource Group and Verify It

Using PowerShell, run az group create --name aks-rg --location westus3 to create a dedicated resource group for the AKS cluster. Follow up with az group list to confirm the resource group was created successfully (status: "Succeeded") alongside other existing resource groups in the subscription.

Step 2 — Create the AKS Cluster

In the VS Code integrated terminal, run az aks create --resource-group aks-rg --name my-aks-cluster --node-count 1 --generate-ssh-keys to provision the Kubernetes cluster. Azure returns a detailed JSON response describing the cluster configuration, including agent pool profiles, node count, and orchestrator version.

Step 3 — Verify the Cluster and Get Credentials

Run az aks list --output table to confirm the cluster ("my-aks-cluster") shows a Succeeded provisioning state, running Kubernetes version 1.34.6 in the westus3 region. Then run az aks get-credentials --resource-group aks-rg --name my-store-cluster to merge the cluster's credentials into your local kubeconfig for kubectl access.

Step 4 — Confirm Node Connectivity

g)
After credentials are merged (confirmed by "Merged 'my-aks-cluster' as current context"), run kubectl get nodes to verify the cluster node is Ready and running Kubernetes version v1.34.6.

Step 5 — Deploy the Application and Check Pods

Apply your Kubernetes manifest with kubectl apply -f my-aks.yaml, which creates the deployments and services (RabbitMQ, order-service, product-service, store-front). Run kubectl get pods to confirm all pods are Running (or initializing) as expected.

Step 6 — View the Live Application

Navigate to the cluster's public IP in a browser to view the deployed application — in this case, a "Contoso Pet Store" storefront displaying a product catalog with images, descriptions, prices, and "Add to Cart" functionality, confirming the full stack is live and accessible.

Deploying and Connecting to an Ubuntu Linux VM on Azure Using SSH Public Key Authentication

Kolarinde Awopetutimileyin — Thu, 23 Jul 2026 12:26:43 +0000

Step 1 — Configure SSH Public Key Authentication

On the Create a virtual machine page under Administrator account, set Authentication type to SSH public key. Enter a username, leave SSH public key source as "Generate new key pair," keep the RSA SSH format, and name the key pair. Under Inbound port rules, allow selected ports and choose SSH (22), then click Review + create.

Step 2 — Review and Create the VM

On the Review + create tab, confirm validation has passed, review the basics summary (subscription, resource group, VM name, region), and click Create to start deployment. Azure will prompt you to download the private key (.pem) at this point — save it somewhere memorable.

Step 3 — Deployment in Progress

The deployment overview page shows "Deployment is in progress" while Azure provisions the network interface, network security group, and public IP address.

Step 4 — Deployment Complete

Once finished, the page updates to "Your deployment is complete." Click Go to resource, or use the linked resource group, to open the new VM.

Step 5 — Open the VM and Start Connecting

From the VM's Overview page, review the essentials (public IP, OS, size) and click Connect to view connection options.

Step 6 — View the Native SSH Command

On the Connect page under Native SSH, Azure displays the destination VM's IP/port and a partial SSH command showing a placeholder — a warning notes the private key file path is missing.

Step 7 — Locate and Copy the Private Key Path

In File Explorer (e.g. Downloads folder), right-click the downloaded .pem private key file and select Copy as path to grab its exact local file location.

Step 8 — Paste the Key Path into Azure

Back on the Connect panel, click Edit settings, paste the copied .pem file path into the "Provide a path to your SSH private key file" field, and save. Azure then assembles the complete SSH command with the key path included.

Step 9 — Connect via Command Prompt

Copy the completed SSH command (e.g. ssh -i "C:\Users\HomePC\Downloads\azureuser.pem" azureuser@20.237.186.3), paste it into Command Prompt, and press Enter to establish the SSH connection to the VM.

"Deploying and Connecting to an Ubuntu Linux VM on Azure via Native SSH

Kolarinde Awopetutimileyin — Thu, 23 Jul 2026 11:40:17 +0000

Step 1 — Configure VM Basics

On the Create a virtual machine page, select your subscription and create a new resource group (named clearly, e.g. "Newkola-RG(Linux)"). Give the VM a unique name, choose your region (West US 2), leave availability/security type at default, and select Ubuntu Server 24.04 LTS – x64 Gen2 as the image. Confirm the architecture (x64) and choose a VM size that fits your workload, then select Password as the authentication type.

Step 2 — Set Administrator Credentials & Inbound Ports

Under Administrator account, create a username and a strong password (confirm it). In Inbound port rules, choose "Allow selected ports" and select SSH (22) from the dropdown so the VM accepts SSH connections from outside.

Step 3 — Review and Create the VM

On the Review + create tab, confirm validation has passed and review the estimated hourly price. Accept the marketplace terms, then click Create to begin deployment.

Step 4 — Confirm Deployment

Once deployment finishes, the "Your deployment is complete" confirmation appears. Click Go to resource to open the newly created VM.

Step 5 — Open the Connect Panel

From the VM's Overview page, click the Connect dropdown at the top to view available connection methods.

Step 6 — Copy the SSH Command (Password Auth)

On the Connect page under Native SSH, verify the destination VM's public IP and port (22), then copy the pre-built SSH command (e.g. ssh username@publicIP) and paste it into your local terminal/command prompt to connect.

Step 7 — Connect Using an SSH Private Key (Alternate Method)

For VMs configured with SSH key authentication, go to Connect on the VM, click Edit settings, and paste the path to your downloaded .pem private key file (e.g. C:\Users<user>\Downloads<key-name>.pem). Azure then generates the full SSH command with the key path included — copy this and run it in your local command prompt to log in.