DEV Community: Bala Audu Musa

Weather Report Automation

Bala Audu Musa — Mon, 05 Jan 2026 01:53:52 +0000

Aim:
To build an AI agent that we can speak to and it tells us the weather condition of any place we want.

Tools

Vapi
Large Language Model (LLM) like OpenAI, Gemini AI etc.
n8n

Visit https://n8n.io/workflows/ to sign in to n8n if you already have an account. Or Get Started to create one.

Since I had created account already, I will be signing in. Thenafter, I click on Open Instance.

Click on Workflows

Click on the Large Plus (+) sign above where is written Add first step... or start from a template.

Search for Webhook and select in the dropdown

Search for AI agent and click it in the drop down.

Click on the bar where GET is and select POST in the drop-down. Leave every other thing in default and click on (x) to close the page.

Click on the plus (+) to the right of Webhook and search AI agent in the popped-out dialog box and select it.

Close the page that opened.

Let's now add a weather_tool
Click on the plus (+) under tool. Search for Weather in the bar and Select the OpenWeatherMap tool

If you have not created credentials for OpenWeatherMap do it. In the City bar click on the stars **to automatically get that decided by **AI. Close the page after that.

Lets now add chat model
Click on the plus (+) below chat model. Under the language models dialog box search for Gemini or OpenAI etc. In this case I am searching for Gemini because I had exhausted my credit in OpenAI.

You need to create credential and generate an API if you have not done so. Select the flash option of Gemini.

Close the window.

Let's now setup VAPI
Create an account or sign in. I am using my Github account to sign in in this case.

Click on Assistants and then click on Create Assistant

Give the your Assistant a name. Lets call it Weather Agent.
Then click on Create Assistant.

Under model; type in the First Message and the System Prompt.

Let's now create the Weather_tool.

Scroll down to Tools. Click on the Tools bar and click on Create New Tool.

Click on Create Tool

Click on Custom Tool

Rename the tool as Weather1_tool. And Give a description below.

Scroll down to Parameters and click on + Add Property.

Give the Parameter name; Place and write a description and click on Apply. Don't click on Required.

Scroll to Server Settings
For the Server URL, we need to go back to n8n, double click on Webhook and copy the POST URL

Go back to Vapi and paste the URL in the Server URL bar. Then click on Save.

We just finished setting up our Weather_tool.

Click on Assistants and then click on Tools.

Click on Select Tool bar and click to Select the weather_tool we just created.

Click on Publish at the top right-hand corner of the page.

Click on Configure Structured Output. Select the first one; Call Summary and click on Next.

Click on Publish.

Back to n8n. Click on Listen for test event.

As it starts listening... Go back to Vapi and click on Talk to Assistant.

The Weather Assistant will call to ask you where you want to get its weather. On telling it. It will say he is not able to get it. That is true. We now need to configure the part it actually gives a good reply.

End the call. Back to n8n. You should see the output dialog box has been populated with data on the call you just made.

Double click on your AI Agent in n8n. And under Source for Prompt (User Message) select Define below.

Type in the Prompt box and move in codes from the left panel to represent key indices. Make sure you select Expression

Lets now add a Response to Webhook

Double click on Webhook and click on Using 'Respond to Webhook Nodes'

Click on Execute workflows in n8n and go to Vapi to Talk to Assistant.

You will notice it still could not give us intend answer. That is natural. Let's tweak it a bit further.

Double click on Respond to Webhook. You should see the Output format. Now that format can't be sent to Vapi. Hence, why Vapi didnt response to us.

Message sent to Vapi has to be in a particular format. Now let's open Vapi Documentation.

Click on Custom Tools. Scroll to Server Response Format: Providing Results and Context and copy the JSON.

Back to n8n. Double click on Respond to Webhook. Click on First incoming message bar and select JSON in the drop-down.

Paste the JSON you have copied into the Respond body.

Replace CallID X and Result Y with their equivalent from the left pane.

Let's test again.
Execute workflows. Then click on Talk to Assistant

This is what success looks like. Alhamdulillah.

MULTI-CONTAINER SYSTEM + REVERSE PROXY (CONSOLIDATION)

Bala Audu Musa — Sat, 27 Dec 2025 15:44:42 +0000

🎯 What this project consolidates

You already know CI/CD.
Now we consolidate runtime architecture.

You will practice:

Docker Compose (real-world usage)
Service-to-service communication
Reverse proxying with Nginx
Port isolation (security thinking)
Clean project structure
Debugging container networking (a core DevOps skill)

🧱 What we will build

Browser
   ↓
Nginx (port 8080)
   ↓
App container (internal only)

📂 Project structure (professional)

project-2-multicontainer/
├── app/
│   ├── app.js
│   ├── package.json
│   └── Dockerfile
├── nginx/
│   └── nginx.conf
├── docker-compose.yml
└── README.md

🧪 Outcome (what you should be able to say)

“I run applications behind an Nginx reverse proxy using Docker Compose, isolating services and exposing only the gateway.”

🧱 CLASS 1 — PROJECT SETUP (START HERE)
Step 1: Create project directory

cd ~/OneDrive/Desktop
mkdir project-2-multicontainer-v2
cd project-2-multicontainer-v2

Initialize git:

git init

Step 2: Create folders

mkdir app nginx

Step 3: Create docker-compose.yml

code docker-compose.yml

Paste exactly:

services:
  app:
    build: ./app
    container_name: app
    expose:
      - "3000"

  nginx:
    image: nginx:alpine
    container_name: nginx
    ports:
      - "8080:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app

Save.

🧱 PROJECT 2 v2 — CLASS 2
Build the App Container + Configure Nginx Reverse Proxy

Goal: When you open http://localhost:8080, you see a message served by the app container, through Nginx.

1) Create the Node app (inside app/)

Go into app folder:

cd app
npm init -y
npm i express

Create app.js:

code app.js

Paste:

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Hello from app container (Project 2 v2) ✅");
});

app.listen(3000, () => console.log("App running on port 3000"));

Create Dockerfile (inside app/):

code Dockerfile

Paste:

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]

Go back to project root:

cd ..

2) Create Nginx config (inside nginx/)

Create nginx/nginx.conf:

code nginx/nginx.conf

Paste:

events {}

http {
  server {
    listen 80;

    location / {
      proxy_pass http://app:3000;
    }
  }
}

✅ Key part: proxy_pass http://app:3000;

app is the service name from docker-compose.
At this stage make sure your Docker Desktop is up and running.

3) Run the stack

From project root:

docker compose up --build

Open browser:

http://localhost:8080

Expected:
Hello from app container (Project 2 v2) ✅

Stop:

Ctrl + C

Then clean up:

docker compose down

🧱 PROJECT 2 v2 — CLASS 3
Add Health Checks + Make Nginx “Production-ish”

Goal: Add /health endpoint + improve Nginx proxy settings + verify using curl and logs.

1) Add /health endpoint (App)

Open app/app.js:

code app/app.js

Update it to this (keep your existing / route too):

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Hello from app container (Project 2 v2) ✅");
});

app.get("/health", (req, res) => {
  res.status(200).send("OK");
});

app.listen(3000, () => console.log("App running on port 3000"));

Save.

2) Improve Nginx config (headers + timeouts)

Open:

code nginx/nginx.conf

Replace with:

events {}

http {
  upstream app_upstream {
    server app:3000;
  }

  server {
    listen 80;

    location / {
      proxy_pass http://app_upstream;

      proxy_http_version 1.1;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_connect_timeout 5s;
      proxy_read_timeout 30s;
      proxy_send_timeout 30s;
    }
  }
}

Save.

3) Rebuild and run

From project root:

docker compose up --build

4) Verify via curl (proof)

In a new terminal tab:

curl -i http://localhost:8080/
curl -i http://localhost:8080/health

Expected:

/ returns 200 and your message
/health returns OK

5) Check logs (bonus skill)

docker compose logs nginx --tail 20
docker compose logs app --tail 20

6) Stop and clean

Ctrl + C then:

docker compose down

🧱 PROJECT 2 v2 — CLASS 4
Publish to GitHub + Add CI (recruiter-ready)

Goal: Put this project on GitHub with a clean READMEand a CI workflow that validates the Node app.

1) Initialize git (if not already) + check status

From project root (project-2-multicontainer-v2):

git status

If it says “not a git repository”, run:

git init
git branch -M main

2) Create a recruiter-friendly README (short, strong)

Create/open:

code README.md

Paste:

# Project 2 v2 — Multi-Container App with Nginx Reverse Proxy (Docker Compose)

A production-style multi-container setup where a Node.js app runs privately behind an Nginx reverse proxy.

## Architecture
Browser → Nginx (8080) → App (internal:3000)

## What this demonstrates
- Docker Compose orchestration
- Reverse proxying with Nginx
- Service-to-service networking via Compose
- Health checks (`/health`) for operational readiness

## Run locally

`docker compose up --build`

**3) Run curl in a NEW terminal tab/window**

Open a new Git Bash window/tab and run:

curl -i http://localhost:8080/health
curl -i http://localhost:3000


**4) Stop containers when done**

Go back to the terminal running compose and press:

Ctrl + C


Then clean up:

docker compose down

CI/CD Pipeline for a Dockerized App on AWS (From zero to production).

Bala Audu Musa — Thu, 25 Dec 2025 19:53:20 +0000

At the end of the project, you should be able to confidently say to your potential employer:

"I built a CI/CD pipeline using GitHub Actions to automatically test, build, and deploy a Dockerized application to AWS EC2, using Nginx and a blue/green strategy to achieve zero-downtime deployments."

Step 0.1 — Create a new project folder
On your local machine:

cd ~/OneDrive/Desktop
mkdir start-project1-cicd-from-scratch
cd start-project1-cicd-from-scratch

Initialize git:

git init

Step 0.2 — Create a NEW GitHub repository
Go to 👉 https://github.com/new

Repository name:

start-project1-cicd-from-scratch

Visibility: Public
❌ Do NOT add README
❌ Do NOT add .gitignore
Create the repo.

Then connect local → GitHub:

git remote add origin https://github.com/dr-musa-bala/start-project1-cicd-from-scratch.git
git branch -M main

Step 0.3 — Confirm clean state
Run:

git status

You should see:

On branch main
No commits yet

✅ This is perfect.

🧱 PHASE 1 — Build the Minimal Node App (the “deploy target”)

Goal: Create a tiny app + test so CI has something real to run.
1) Create the project files
From inside start-project1-from-scratch run:

npm init -y
npm i express
npm i -D jest supertest

2) Create app.js.

code app.js

Paste:

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Project 1: CI/CD from scratch ✅");
});

app.get("/health", (req, res) => {
  res.status(200).send("OK");
});

module.exports = app;

*3) Create *server.js

code server.js

Paste:

const app = require("./app");

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

4) Create a test file

Create folder + test:

mkdir test
code test/app.test.js

Paste:

const request = require("supertest");
const app = require("../app");

describe("GET /", () => {
  it("should return 200", async () => {
    const res = await request(app).get("/");
    expect(res.statusCode).toBe(200);
  });
});

5) Update package.jsonscripts
Open:

code package.json

Replace the scripts section with:

"scripts": {
  "start": "node server.js",
  "test": "jest"
}

6) Run locally (must pass)

npm test

You should now see output like:

PASS  test/app.test.js
✓ should return 200

npm start

Open in browser:
http://localhost:3000

You should see:
Project 1: CI/CD from scratch ✅

Stop server with:

Ctrl + C

🧱 PHASE 2 — Dockerize the App (so CI/CD can ship it)
Goal: Package your app into a Docker image that runs the same everywhere.
1) Create Dockerfile (in project root)

Run:

code Dockerfile

This opens up VS Code.
Paste:

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Control + S to save.

2) Create .dockerignore (keeps image clean)

code .dockerignore

Paste:

node_modules
npm-debug.log
.git
.github
Dockerfile
docker-compose.yml
README.md

3) Create docker-compose.yml (local run)

code docker-compose.yml

Paste:

services:
  app:
    build: .
    ports:
      - "3000:3000"

Ensure at this stage that your Docker Desktop is powered on.

4) Build + run with Docker Compose
From project root:

docker compose up --build

Test in browser:

http://localhost:3000

You should see:
Project 1: CI/CD from scratch ✅

Stop:

Ctrl + C

Then clean up:

docker compose down

🧱 PHASE 3 — Push to GitHub + Add CI (GitHub Actions)
Goal: Every push runs tests automatically. If tests fail → pipeline fails.

1) Commit and push your current code
From project root:

git add .
git commit -m "Phase 2: Add Node app + tests + Docker setup"
git push -u origin main

Got an error.

Git is telling you the truth:

“I’m trying to push to a repository that does not exist at that URL.”

So either:

the GitHub repo was not created, or
the repo name is slightly different from what your local git thinks

We’ll fix this cleanly.

✅ STEP 1 — Check what remote URL Git is using

Run:

git remote -v

From the picture illustration above we can see where the problem is coming from wrong repo (repo not tallying).

Lets reset repo.
Enter the command:

git remote set-url origin https://github.com/dr-musa-bala/start-project1-cicd-from-scratch.git
git remote -v

Now we push again;

git push -u origin main

Check github under same repository.

🧱 PHASE 3 (CONT.) — Add GitHub Actions CI
1) Create the workflow file
From your project root:

mkdir -p .github/workflows
code .github/workflows/ci.yml

Paste this:

name: CI

on:
  push:
    branches: ["main"]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

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

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "18"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Save.

2) Commit + push

git add .github/workflows/ci.yml
git commit -m "Add GitHub Actions CI pipeline"
git push

3) Verify it’s running

Go to your GitHub repo → Actions tab → you should see a workflow run.

✅ If it turns green, you’re done.

✅ That means Project 1 now has real CI.

Now we level it up into CD: build a Docker image in CI and push it to **Docker Hub **automatically.

🧱 PHASE 4 — Docker Hub Build & Push (CD starts)

0) One-time setup on Docker Hub (important)

You need:

Docker Hub username
Docker Hub Access Token (not your password)

Create the token

Docker Hub → Account Settings → Security → New Access Token
Name it: github-actions-project1
Copy it (you won’t see it again).

1) Add GitHub Secrets (this is the “secret stuff” done correctly)

In your GitHub repo:
Settings → Secrets and variables → Actions → New repository secret

Create exactly these:

DOCKERHUB_USERNAME = your Docker Hub username (e.g., drmusabala)

DOCKERHUB_TOKEN = the access token you generated

✅ Secret names are fixed (left box)
✅ Secret values are your real details (right box)

2) Update workflow to build & push Docker image

Open the workflow:

code .github/workflows/ci.yml

Replace its content with this (CI + Docker push):

name: CI/CD

on:
  push:
    branches: ["main"]
    tags:
      - "v*.*.*"
  pull_request:

jobs:
  test-build-push:
    runs-on: ubuntu-latest

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

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "18"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ${{ secrets.DOCKERHUB_USERNAME }}/project1-cicd:latest

3) Commit + push

git add .github/workflows/ci.yml
git commit -m "Add Docker build and push to Docker Hub"
git push

Very critical: Make sure in your secrets, it's your Docker Hub username you are using. Because I kept using my GitHub username and keeps getting errors.

You have successfully built, tested**, **containerized, authenticated, and pushed an image via CI. That’s core DevOps skill.

BONUS:
📌 Immediate next steps (important)
1️⃣ Lock this win into documentation (VERY important)

To be pasted in README.md

🚀 **Production CI/CD Pipeline — Docker & GitHub Actions**

This project demonstrates my ability to design, implement, and troubleshoot a production-grade CI/CD pipeline using modern DevOps tooling.

It reflects how CI/CD is actually done in real teams, including secure credential handling, container image lifecycle management, and failure debugging — not just “happy-path” automation.

🔍 What This Project Proves

- By completing this project end-to-end, I demonstrate the ability to:
- Build automated CI pipelines triggered on source control events
- Containerize applications using Docker best practices
- Securely authenticate and push images to Docker Hub
- Manage secrets and tokens using GitHub Actions
- Debug real CI failures (auth issues, build errors, test failures)
- Think in terms of repeatability, security, and automation
- This is the same workflow used in real production teams — simplified, but not diluted.

🧱 Technical Stack

- CI/CD: GitHub Actions
- Containerization: Docker
- Registry: Docker Hub
- Runtime: Node.js
- OS (CI runners): Linux
- Version Control: Git & GitHub
- 🔁 CI/CD Workflow (High-Level)

The pipeline automatically runs on every push to main.

- Pipeline Stages:
- Source checkout
- Node.js environment setup
- Dependency installation
- Test execution
- Secure login to Docker Hub
- Docker image build
- Docker image push to registry

📍 Workflow definition:

.github/workflows/ci.yml

🐳 Docker Image Automation

- The application is built into a Docker image and published automatically.
- Image build is fully automated
- Authentication uses Docker Hub access tokens
- No credentials are committed to source control

Example:

docker pull <dockerhub-username>/start-project1-cicd-from-scratch:latest

🔐 Security Practices

- Security was treated as a first-class concern, not an afterthought.
- Secrets stored in GitHub Actions Secrets
- Docker Hub authentication via access token, not password
- No sensitive data committed to Git
- Pipeline follows least-privilege principles

Secrets used:

DOCKERHUB_USERNAME

DOCKERHUB_TOKEN

📂 Repository Structure
.
├── .github/workflows/ci.yml   # CI pipeline definition
├── Dockerfile                # Production-ready Docker image
├── docker-compose.yml        # Local orchestration
├── index.js                  # Application entry point
├── package.json              # Dependencies & scripts
└── README.md

🧪 Testing Philosophy

- Tests are executed automatically during CI
- Pipeline fails fast if tests fail
- Enforces discipline expected in real engineering teams
- This models quality gates commonly used in production pipelines.

🧠 Engineering Mindset Demonstrated

This project emphasizes:

- Automation over manual steps
- Secure-by-default configuration
- Debugging over blind copy-paste
- Reproducibility across environments
- Clear separation between build, test, and release stages

🚀 Why This Matters to Employers

This project shows I can:

- Contribute to existing CI/CD systems
- Own small-to-medium automation tasks independently
- Understand how code moves from commit → container → registry
- Communicate infrastructure clearly through code and documentation
- It forms a strong foundation for:
- Continuous Deployment (CD)
- Cloud deployments (EC2, ECS, Kubernetes)
- Infrastructure as Code (Terraform)

📈 Next Steps (Planned Enhancements)

- Automated deployment to cloud (EC2)
- Zero-downtime deployment strategies
- Monitoring & health checks
- Infrastructure provisioning with Terraform

👤 About Me

**Dr. Musa Bala Audu**
Junior DevOps Engineer — Open to Remote Roles
GitHub: https://github.com/dr-musa-bala
Dev.to: https://dev.to/bala_audu_musa
Hashnode: https://hashnode.com/@musabalaaudu

Your README should include:

Project overview
CI workflow explanation
Docker image link
What problem it solves
What you learned

✅ Step 1: Make sure you are in the project directory

In Git Bash, run:

pwd

You should see something like:

/Users/fresh/OneDrive/Desktop/start-project1-cicd-from-scratch

If not, go there:

cd ~/OneDrive/Desktop/start-project1-cicd-from-scratch

✅ Step 2: Confirm README exists

ls

You must see:

README.md

If you don’t, create it:

touch README.md

✅ Step 3: Open README and paste the content

Open with VS Code (recommended):

code README.md

👉 Paste the recruiter-tailored README I wrote for you
👉 Save the file (Ctrl + S)
👉 Close the editor

✅ Step 4: Stage the README
git add README.md

Check status:

git status

You should see:

new file: README.md

modified: README.md

✅ Step 5: Commit the README (important message)

Use a professional commit message:

git commit -m "docs: add production-grade README for CI/CD project"

✅ Step 6: Push to GitHub
git push origin main

If main is already tracking:

git push

✅ Step 7: Verify on GitHub

Open your repo in browser

Refresh the page

You should see:

README rendered automatically

Professional project overview visible to recruiters

Provisioning AWS Infrastructure Using Terraform (IaC)

Bala Audu Musa — Mon, 22 Dec 2025 18:27:42 +0000

6 million dollar question: “If everything went down today, could you rebuild it from code?”

After this project, the answer is YES.

🎯 PROJECT 3 — GOALS

By the end of this project, you will:
Provision AWS infrastructure entirely from code
Create and destroy EC2 safely using Terraform
Manage Security Groups declaratively
Understand Terraform state (very important)

Be able to say (confidently):

“I provision AWS infrastructure using Terraform.”
📦 WHAT WE WILL BUILD (CLEAR SCOPE)

Terraform will create:

✅ EC2 instance (Ubuntu)

✅ Security Group

SSH (22)
HTTP (80)

✅ Key Pair (or reference existing)

✅ Output values (public IP)

This will replace manual EC2 creation.

🗂 PROJECT STRUCTURE (PROFESSIONAL)

project-3-terraform-aws/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
└── README.md

NB: Note that we are using Bash terminal throughout the project except stated otherwise.

🧱 CLASS 1 — TERRAFORM SETUP & BASICS
Step 1: Install Terraform (Windows)

Download:
👉 https://developer.hashicorp.com/terraform/downloads

Choose:

Windows AMD64
Extract terraform.exe
Add it to PATH

How do you add to path?

🧱 STEP 4 — ADD TERRAFORM TO PATH (CRITICAL)

This is the step most people miss.

3️⃣ Add C:\terraform to PATH (CRITICAL)

Press Windows key
Search: Environment Variables
Open Edit the system environment variables
Click Environment Variables
Under System variables, select Path
Click Edit
Click New

Click on Browse.. and select the terraform folder we have save in C:.

Click OK on all windows.

⚠️ You must close and reopen Git Bash after this.

🧪 STEP 5 — VERIFY INSTALLATION

Close all terminals.

Open Git Bash again, then run:
Verify:

terraform -version

You must see a version number.

✅ STEP 2: Create the Terraform project directory

Now create it:

mkdir project-3-terraform-aws

Enter it:

cd project-3-terraform-aws

Confirm:

pwd

You should see:

.../Desktop/project-3-terraform-aws

✅ Now you’re in the right place.

☁️ AWS SETUP — KEY PAIR (SAFE & CORRECT)
🎯 What we are doing

By the end of this, you will have:

An AWS account
An EC2 Key Pair
A .pem file saved safely
The key pair NAME ready for Terraform ⚠️ We are NOT creating EC2 yet — just preparing access.

STEP 1: Log in to AWS Console

Go to:
👉 https://console.aws.amazon.com/

Top-right corner of AWS Console:

Select US East (N. Virginia) → us-east-1

Why?

Free-tier friendly
Matches our Terraform default
Most tutorials & AMIs work here

STEP 3: Go to EC2 Dashboard

In the AWS search bar, type:

EC2

Click EC2.

STEP 4: Create a Key Pair

In the left sidebar:

Network & Security → Key Pairs

Click Create key pair.

Fill the form:

Name:

terraform-key

(simple, professional, reusable)

Key pair type: RSA

Private key file format: .pem

Click Create key pair.

STEP 5: SAVE THE KEY FILE (VERY IMPORTANT)

Your browser will download:

terraform-key.pem

Do NOT delete it

Do NOT rename it

⚠️ AWS will never show this file again.

✅ STEP 3: Initialize the project files
Create the Terraform files we’ll use:

`touch main.tf variables.tf outputs.tf terraform.tfvars`

Confirm:

ls

You should see:

main.tf  variables.tf  outputs.tf  terraform.tfvars

Now that the folder exists and files are created, open it in VS Code:

code .

Step 1: Paste variables.tf

Open variables.tf and paste:

variable "region" {
description = "AWS region"
type = string
default = "us-east-1"
}

variable "instance_type" {
description = "EC2 instance type (keep low-cost)"
type = string
default = "t2.micro"
}

variable "key_name" {
description = "Existing AWS key pair name (NOT the .pem filename)"
type = string
}


Step 2: Paste `main.tf`

Open `main.tf `and paste:

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

provider "aws" {
region = var.region
}

resource "aws_security_group" "web_sg" {
name = "terraform-web-sg"
description = "Allow SSH and HTTP"

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

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

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

data "aws_ami" "ubuntu" {
most_recent = true

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

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

owners = ["099720109477"] # Canonical (Ubuntu)
}

resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
key_name = var.key_name

vpc_security_group_ids = [aws_security_group.web_sg.id]

tags = {
Name = "terraform-web-instance"
}
}

Step 3: Paste `outputs.tf`

Open `outputs.tf` and paste:

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


Step 4: Set `terraform.tfvars`

Open `terraform.tfvars` and paste (edit the key name):

key_name = "YOUR_KEYPAIR_NAME"


⚠️ This must be your AWS Key Pair name (example: nodejs-key) — not nodejs-key.pem.

Step 5: Run Terraform commands (from Git Bash in project-3 folder)

terraform init
terraform fmt
terraform validate
terraform plan

STEP 6: Confirm the **Key Pair** exists

Back in `AWS Console → Key Pairs`

You should see:

terraform-key

👉 Terraform uses the **name**
👉 SSH uses the **.pem file**

STEP 7: Prepare for **Terraform**

Now go back to your local machine.

Open:

`project-3-terraform-aws/terraform.tfvars`


Set:

key_name = "terraform-key"



✅ This is correct.

🚀 PROJECT 3 — CLASS 2 (CONTINUED)
Terraform Plan → Apply → Verify → Destroy (Cost-Safe)

You already have:

✅ Terraform installed

✅ AWS CLI configured

✅ Key pair created: terraform-key

✅ Terraform files created

Now we proceed.

✅ **Step 1: Set the key pair in Terraform**

Open `terraform.tfvars` and confirm it contains exactly:

`key_name = "terraform-key"`

Save the file.

✅ FIX AWS CLI v2 (Windows 11)

Step 1: Check if AWS CLI files actually exist

Open File Explorer and go to:

C:\Program Files\Amazon\AWSCLIV2\


Look for:

aws.exe


Also check this folder:

C:\Program Files\Amazon\AWSCLIV2\bin\



Look for:

aws.exe


How to add PATH:

Press **Win key** → type **Environment Variables**

Open **Edit the system environment variables**

Click **Environment Variables…**

Under User variables (top), select **Path** → **Edit**

New → paste the path above

**OK → OK → OK**

✅ Now close ALL terminals (PowerShell + Git Bash) and reopen PowerShell.

Test:

**where aws
aws --version**

**After AWS works: configure creds for Terraform**

Once `aws --version` works, do:

aws configure


Set:

region: `us-east-1
`
output: `json`

Then confirm:

aws sts get-caller-identity


Then go back to your **Terraform folder** and **run**:

terraform plan

Expected output (example):

C:\Program Files\Amazon\AWSCLIV2\aws.exe
aws-cli/2.xx.x Python/3.xx Windows/10 exe/AMD64

✅ **Then continue Project 3 (Terraform AWS)**
Configure AWS credentials:

aws configure


Enter:

**Access Key ID** → from AWS IAM
**Secret Access Key** → from AWS IAM
**Region** → `us-east-1`
**Output** → `json`

Verify:

aws sts get-caller-identity

Then:

Copy code
terraform init
terraform plan

You should get a successful result.

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5nmvwgspcd28m35yxgap.png)

**Next step (Project 3)**

From the same folder `(~/OneDrive/Desktop/project-3-terraform-aws)` run:

terraform apply


Type **yes **when it asks.

After it finishes, **run**:

terraform output


You should see the

public_ip


**1) Get the EC2 Public IP**

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6gwnfgstg8rlqvp0a7kf.png)

Run (in the same project folder):

terraform output public_ip

If it says “no outputs found”, run:

terraform refresh
terraform output


(That will display it.)

Then we test it

1) SSH into the server (Git Bash)

Your keypair name is terraform-key, so your file is likely on Desktop.

Run:

chmod 400 ~/OneDrive/Desktop/terraform-key.pem
ssh -i ~/OneDrive/Desktop/terraform-key.pem ubuntu@34.229.201.13


If your key is in **Downloads** instead:

chmod 400 ~/Downloads/terraform-key.pem
ssh -i ~/Downloads/terraform-key.pem ubuntu@34.229.201.13


2) Once you’re inside EC2: install Docker and run the proof app

Paste these **exactly**:

sudo apt-get update -y
sudo apt-get install -y docker.io
sudo systemctl enable --now docker
sudo usermod -aG docker ubuntu
newgrp docker
docker run -d --name hello -p 80:80 nginx:alpine


Now open in your browser:

http://34.229.201.13

You should see the Nginx page ✅

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/284x0mgp2nyppdwk2obl.png)

**Destroy everything (from your Terraform folder)**

Make sure you’re in the **right folder**:

cd ~/OneDrive/Desktop/project-3-terraform-aws




Run:

`terraform destroy`

Type:` yes`


This will remove:

- EC2 instance
- Security Group

2) Confirm it’s gone

After it completes, run:

`terraform output`


It should either show nothing useful or error because resources are gone.

Multi-Container Web Application with Nginx Reverse Proxy and Docker Compose

Bala Audu Musa — Sat, 20 Dec 2025 18:26:27 +0000

This project demonstrates a production-style multi-container architecture using Docker Compose, where a Node.js application is deployed behind an Nginx reverse proxy.

The goal of this project is to showcase real DevOps patterns, not single-container demos.

🚀 What This Project Demonstrates

Multi-container application design
Docker Compose for service orchestration
Nginx as a reverse proxy
Private application containers (not exposed to the internet)
Service-to-service communication via Docker networking
Clean separation between application and web server
Production-ready container structure

🧱 Architecture Overview

Client (Browser)
|
v
Nginx (public, port 8080)
|
v
Node.js App (private, port 5000)

Only Nginx is exposed to the host
The Node.js app is accessible only inside the Docker network
Containers communicate using service names, not IPs

📁 Project Structure

project-2-multicontainer/
├── app/
│ ├── Dockerfile
│ ├── index.js
│ ├── package.json
│ └── package-lock.json
├── nginx/
│ └── nginx.conf
├── docker-compose.yml
└── README.md

⚙️ Technologies Used

Docker
Docker Compose (v2)
Node.js (Express)
Nginx
Linux-based containers

🛠 How to Run the Project Locally

Prerequisites

Docker Desktop
Docker Compose v2

Steps

Clone the repository:

git clone https://github.com/dr-musa-bala/project-2-multicontainer.git
cd project-2-multicontainer

2. **Build and start the containers**:

docker compose up --build


3. Open your browser:

Open your browser:

localhost:8080




![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1i3isd39y65f8rc0ttbv.png)

🔒 **Security & Production Considerations**

The application container does not expose any ports to the host

All external traffic is handled by **Nginx**

This mirrors how applications are deployed in real production environments

💡 **Why This Matters (DevOps Perspective)**

This project reflects how modern DevOps teams:

- Isolate application services
- Control ingress traffic via reverse proxies
- Use declarative configuration for reproducibility
- Build systems that are easy to extend into CI/CD pipelines

🔜 **Next Improvements**

- Add CI/CD with GitHub Actions
- Push application images to Docker Hub
- Deploy the stack to AWS EC2
- Implement zero-downtime updates
- Add HTTPS with Let’s Encrypt

I Set Up My Windows 11 Machine Once for All DevOps Projects — Here’s How.

Bala Audu Musa — Sun, 14 Dec 2025 12:49:40 +0000

INTRODUCTION:

Most people fail at DevOps before they even begin — not because DevOps is hard, but because their Windows setup is broken.

Docker errors. Git **not found. Half-installed tools.
Instead of learning **CI/CD, they spend weeks debugging their machine.

This is Phase 0.

No pipelines. No Kubernetes. No cloud magic.
Just a clean, one-time Windows 11 DevOps setup that won’t break later.

In 60–90 minutes, we’ll install only what’s required for real CI/CD projects:
Git, GitHub, Docker (WSL 2), Node.js, VS Code, and AWS CLI — nothing extra.

If every command works at the end, your foundation is solid.
From here on, everything we build is real proof.

✅WHAT YOU WILL HAVE AT THE END OF PHASE 0

A working terminal
Git connected to GitHub
Docker running correctly
Node.js ready (for the sample app)
VS Code configured
AWS CLI ready (but not used yet)

🔹** STEP 1: Install Visual Studio Code (Editor)**

Why?

We need a clean, reliable editor. VS Code is industry standard.

👉 [https://code.visualstudio.com/Download]

After Installation — Install These Extensions ONLY:

Open VS Code → Extensions (Ctrl+Shift+X)

Install:

✅ Docker
✅ GitHub Pull Requests and Issues
✅ YAML
✅ Terraform (for later, but safe to install now)

Do not install random themes or plugins.

🔹 STEP 2: Install Git (Source Control)

Why?

Git is non-negotiable. Recruiters check GitHub first.

Download & Install
👉 [(https://git-scm.com/download/win)]

During installation:

Click Next for everything
When asked about default editor → choose VS Code
When asked about line endings → Checkout Windows-style, commit Unix-style

Verify Installation

Open Command Prompt or PowerShell and run:

git --version

✅ You should see a version number.

STEP 3: Create / Confirm GitHub Account

Platform you’ll showcase everything on

👉 [https://github.com]

Actions

Create an account (if you don’t have one)
Choose a professional username Example: first-devops,firstname-cloud, etc.

⚠️ This GitHub profile will go on your CV.

🔹 STEP 4: Install Node.js (For Sample App)

We are not learning Node.js.
We only need it to run the app and tests.

👉 [https://nodejs.org/en/download/]

Choose:

LTS version
Windows Installer (.msi)

Verify

node --version
npm --version

Both should return versions.

🔹 STEP 5: Install Docker Desktop (CRITICAL)

Why?

CI/CD = Docker. No Docker, no DevOps.

👉 [https://www.docker.com/products/docker-desktop/]

During installation:

Enable WSL 2
Allow it to install Linux kernel updates

⚠️ You may be asked to restart your PC — do it

After Restart:

Open Docker Desktop

Wait until it says: “Docker is running”

Verify

docker --version
docker compose version

✅ Both must work.

🔹 STEP 6: Install AWS CLI (Preparation)

We won’t use AWS yet, but install now to avoid breaking flow later.

👉 [https://aws.amazon.com/cli/]

Download:

AWS CLI v2 – Windows

Verify

aws --version

You should see version info.

⚠️ Do NOT configure credentials yet.

🔹 STEP 7: Install Git Bash (Terminal We’ll Use)

If you installed Git correctly, Git Bash is already installed.

Open:

Right-click anywhere → Git Bash

This will be our main terminal.

🔹 STEP 8: Quick Health Check (IMPORTANT)

Run these commands one by one in Git Bash:

git --version
docker --version
docker compose version
node --version
npm --version
aws --version

✅ All must return versions

Note well: If your environment is broken, everything later breaks.

Create an Ansible Playbook to Install Git on managed host

Bala Audu Musa — Tue, 24 Jun 2025 19:56:47 +0000

Project Introduction:
In this project, I automated the installation of Git on a remote Managed Host using an Ansible Playbook executed from a Control Host. The objective was to demonstrate real-world configuration management by securely provisioning software across systems using Ansible’s agentless architecture.

After setting up passwordless sudo access for the ansible user on the managed host, I created a playbook (install_git.yml) that uses the aptmodule to install Git, ensuring the system cache is updated and the package is present.

This project highlights core automation principles including:

Playbook creation
Privilege escalation with become: yes
Secure SSH-based remote execution
Inventory group targeting with Ansible

The successful execution of this playbook marks a key milestone in simplifying repeatable tasks in server administration — a foundational DevOps skill.

Let's begin...

Requirement:
Ensure you have enabled passwordless sudo on the managed-host.

Run the command on the managed-host as the ansible user;

su - ansible
sudo visudo

Add the command below at the end of the file.

ansible ALL=(ALL) NOPASSWD:ALL

Save (CTRL+S) and exit (CTRL+X).

Creating the First Ansible Playbook
On the control-host, as the ansible user, create the playbook file:
Run the command: vi install_git.yml. An editor will open. Paste the following instructions into it. Remember to set paste (ESC KEY, then colon(:). type set paste and enter) then right click to paste. You do set paste so your instructions are well aligned when you paste. Exit editor (esc:wq enter).

Run the command below to execute the Playbook:

ansible-playbook install_git.yml

Verify Git Installation on Work-station

Once the playbook runs successfully, In the** control-host*, **SSH* into the managed-host and check Git version:

ssh ansible@<managed-host ip>
git --version

You should see something like:
git version 2.43.0

Achievements: Installing Git Using Ansible Playbook

Granted passwordless sudo access to the ansible user on the Managed Host via visudo.
Created an Ansible playbook (install_git.yml) to automate Git installation.
Defined the target host group (web) in the playbook matching the inventory file.
Usedbecome: yes in the playbook to allow privilege escalation (sudo access).
Included an** apt module** task to:

Update the package cache
Ensure Git is installed and up-to-date.
1. Executed the playbook using the ansible-playbook command from the Control Host.

Successfully connected to the Managed Host over SSH using the ansible user.
Verified the Git installation by running git --version on the Managed Host.

How to Set Up Passwordless SSH from Control Host Managed Host

Bala Audu Musa — Sun, 22 Jun 2025 17:25:41 +0000

Objective:
Allow ansible@Control-Host to connect to ansible@Work-station without typing a password (using SSH keys).

Setup Requirements

Two EC2 instances:

Control Host: This is where you’ll download and install Ansible.

Work-station: This is the machine you want to manage.

We Begin...
Spin two EC2 instances (virtual servers). This can be achieved either by terraform, Azure or AWS.** Using AWS*;
Log into the **AWS portal* and search EC2 in the all-purpose search bar. Click EC2 in the displayed search option. In the Launch a virtual server window, click on Launch instance.

In the Launch an instance page, make the following adjustments:
Name and tags (Name): Leave blank
Number of instances: 2,
Application and OS Images (Amazon Machine Image): Select Ubuntu
Instance type: leave in default t3.micro Free tier eligible. In some other availability zones, it is the t2.micro.
Key pair (login): Click on Create new key pair if you don't have any existing one.
Give key pair a name and click on Create a key pair. Note the downloaded key pair for later use in this project.

Network settings: take the defaults and click on Launch instance. Click on View all instances. Click on the pencil to edit the names of the instances. The first should be Control host and second Managed host or Remote host or Work station host.
.
NB: A vpc, Subnet, Firewall (security groups), which** Allow SSH traffic from Anywhere (0.0.0.0/0)** will be created.

Copy the Managed host's Public IPv4 address.

Connect the created servers to the terminal. GitBash or PowerShell terminals can be used. Using the PowerShell terminal;

Open PowerShell and enter the following command.

[ssh -i 'C:/Users/fresh/Downloads/musa_key.pem' ubuntu@16.171.135.131](url)and enter.

'C:/Users/fresh/Downloads/musa_key.pem' is the earlier downloaded key pair path.

16.171.135.131 is the Public IP address of the Managed host.

When prompted Are you sure you want to continue connecting (yes/no/[fingerprint])?
**. Type **yes and enter. Managed host has been successfully connected to the terminal.

We do the same, for the Control host to be connected in a separate terminal. Don't forget to change the Public IP address to that of the Control host. You should get the below result when successful.

Icing sugar!
I encountered challenges connecting with this command [ssh -i "C:/Users/fresh/Downloads/musa_key.pem20%(1)" ubuntu@16.171.135.131](url). I had to rename the key pair path to 'C:/Users/fresh/Downloads/musa_key.pem' in single quotation mark before it went through successfully.

3. Changing the servers' name from ubuntu@ to Control host and Managed host.
Enter the command:
sudo hostnamectl set-hostname control-host in the Control host terminal and sudo hostnamectl set-hostname managed-host terminal. Enter the command logout and enter. Re-type and re-enter the command `[ssh -i 'C:/Users/fresh/Downloads/musa_key.pem' ubuntu@16.171.135.131] again for the server name to change.

for the control-host:

for the managed-host:

4. Creating an ansible user
Run the command; sudo useradd -m -s /bin/bash ansible

Adding the user to sudo group and granting the user administrative privileges. Run the command; sudo usermod -aG sudo ansible

6. Creating a password for ansible user.
Run the command: sudo passwd ansible. Enter a password. Note that it won't show. Re-enter the password again to confirm.

Switching to the ansible user on the The Control Host Run the command: sudo su - ansible

Do same to the Managed Host

Install ansible only on the control host Run the following command:

sudo apt update && sudo apt upgrade -y sudo apt install -y software-properties-common sudo add-apt-repository --yes --update ppa:ansible/ansible sudo apt install -y ansible
Wait for it to update and install ansible. Then confirm successful installation by running the command;
ansible --version.

Ansible has been successfully installed in the control host.

Generate an SSH Key Pair on Control Host Run the command: ssh-keygen -t rsa -b 4096. Press Enter to all the prompts.

Two files will be created by this command;
i) ~/.ssh/id_rsa → your private key (keep safe!)
ii)** ~/.ssh/id_rsa.pub** → your public key (this is what you’ll copy to Work-station)

Keypair has been successfully created.

Creating -ssh folder on Managed Host Run the following commands:

mkdir -p ~/.ssh chmod 700 ~/.ssh touch ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys chown -R ansible:ansible ~/.ssh

Command Purpose
mkdir -p ~/.ssh Creates the .ssh directory in the user's home folder. The -p ensures no error if it exists.
chmod 700 ~/.ssh Sets permissions on .ssh so only the owner can read, write, or execute.
touch ~/.ssh/authorized_keys Creates the authorized_keys file if it doesn't already exist.
chmod 600 ~/.ssh/authorized_keys Restricts authorized_keys so only the owner can read or write it (secure SSH key file).
chown -R ansible:ansible ~/.ssh Changes the ownership of .ssh and all its contents to user ansible and group ansible.

Generating Public key from the Control Host: Run the command; cat ~/.ssh/id_rsa.pub
Copy the whole key.
Create a folder in Managed Host with the command:
vi ~/.ssh/authorized_keys. Paste the copied key into it and exit (escape:wq + enter)

Re-run the following commands to double check. If no error messages, everything is fine.

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R ansible:ansible ~/.ssh

15. Test Passwordless in the Control Host
Run the command: ssh ansible@<managed-host private ip>

We have accessed our managed host from the control host.

16. Creating an Ansible Inventory File
The Ansible inventory file is a core configuration file that tells Ansible which** hosts (servers, devices, or VMs) to manage, and optionally how to group and connect to them.**.

Run the command sudo vi /etc/ansible/hosts. Once the text editor opens you should see texts already in it. Enter
[web] 16.171.200.117 ansible_user=ansible. 16.171.200.117 is the Public IP **address of the managed-host. Press **escape key :wq and enter to save and exit the editor.

[web] is the group name (you can call it whatever you want)

ansible_user=ansible tells Ansible to SSH into that machine using the ansible user.

17. Testing Ansible Connection
On Control-Host Run this command " ansible all -m ping "

We should get An Output with a success Message.

It Shows we have Successfully Created Ansible Inventory File.

Copy-Paste Not Working Between Windows and Ubuntu VirtualBox? Here's the Fix!"

Bala Audu Musa — Thu, 15 May 2025 22:12:31 +0000

📝 Introduction
One of the most common frustrations faced by users running Ubuntu Linux in VirtualBox on a Windows host is the inability to copy and paste text—especially command-line instructions—between the two systems. This issue becomes particularly inconvenient when you're trying to copy terminal commands, configuration snippets, or file paths from Windows into Ubuntu, only to find that the clipboard doesn't work as expected. Fortunately, VirtualBox offers a feature called Shared Clipboard, which allows seamless copy-paste between the host and guest operating systems. However, this functionality is not enabled by default and requires proper configuration, including the installation of Guest Additions in the Ubuntu virtual machine. This guide walks you through the steps to enable clipboard sharing and eliminate the hassle of manual retyping.

A. Start Ubuntu in VirtualBox
Log into your Ubuntu VM.

B. Click on Devices then on Insert Guest Addition CD Image....

C. If prompted to run it, choose Run. You might need to enter your password.

If not prompted:

Open Terminal and run: 
sudo mkdir /media/cdrom
sudo mount /dev/cdrom /media/cdrom
sudo /media/cdrom/VBoxLinuxAdditions.run

You might need to run them one after the other.

What does each command do?
sudo mkdir /media/cdrom

Creates a new directory called cdrom inside /media.

sudo is used to run the command with superuser (administrator) privileges.

sudo mount /dev/cdrom /media/cdrom

Mounts the CD/DVD device (/dev/cdrom) to the /media/cdrom directory, making its contents accessible from that location.

sudo /media/cdrom/VBoxLinuxAdditions.run

Executes the VirtualBox Guest Additions installer from the mounted CD.
This typically improves integration between a VirtualBox guest OS and the host (e.g., better graphics support, shared clipboard, etc.).

In summary, these commands mount the VirtualBox Guest Additions CD and install the tools inside a Linux virtual machine.

C. Reboot Ubuntu VM
sudo reboot

Furthermore, Enable Shared Clipboard in VirtualBox Settings.

On the Virtualbox start up page, click on setting, then Advanced and under Shared Clipboard, click on Bidirectional.

(Optional) Set Drag and Drop to Bidirectional.

Test Copy and Paste
After rebooting Ubuntu:

Try copying text from Windows and pasting into Ubuntu (e.g., in Terminal or a text editor).
Also try copying from Ubuntu to Windows.

Copy from window;

Paste in Linux terminal;

Transitioning Terraform State File from Local to Remote Backend

Bala Audu Musa — Fri, 09 May 2025 20:39:20 +0000

DEFINITION
The terraform.tfstate file is a JSON file that Terraform uses to track the current state of your infrastructure. It acts as a source of truth, allowing Terraform to understand what resources already exist so it can determine what changes are needed during operations like terraform apply. It's essential for ensuring that Terraform doesn't duplicate or unintentionally alter infrastructure. Because it can include sensitive data, it should be stored securely and never edited manually.

Migrating Terraform state from local to remote storage is a** critical step for improving collaboration, security, and reliability in infrastructure as code.**

What does terraform.tfstate file contain?
The terraform.tfstate file is in JSON format and contains:

Resource names and types (e.g., aws_instance.web_server)
Resource properties (e.g., IP addresses, IDs, configurations)
Metadata, dependencies, and outputs
Sometimes sensitive information like secrets or credentials (unless specifically filtered out)

WHY MIGRATE?
Migrating the file to remote state makes Terraform safer, more scalable, and team-friendly. It's like moving your most important documents from a personal notebook to a secure, shared digital vault—so everyone can work together, safely and efficiently.

Let's begin...

Go to the link [https://app.terraform.io/public/signup/account]. Create a terraform registry account. Input Username, email, password and click on Create account.

You will be prompted that Confirm your email address.

Go to your email and click on the confirmation link. It will then redirect you back to the terraform page. Click on Create organization. An organization in the Terraform Registry is a shared namespace used to manage and publish Terraform modules or providers collaboratively under a team or company's name.

Input your organization name and click on Create organization.

You are now on the Create a** Workspace page**. Click on the CLI-driven Workflow. HCP Terraform organizes your infrastructure resources by workspaces. A workspace contains infrastructure resources, variables, state data, and run history.

Why Choose a particular Workflow?
The CLI-driven workflow is ideal for users who prefer working directly from the terminal while still benefiting from Terraform Cloud’s features like** remote state storage*, **locking, and **logging. Unlike the **Version Control (VCS)-driven workflow, which automatically runs plans and applies on every Git push—great for teams using **GitOps—the* CLI-driven method** gives you more control and flexibility without needing to change your development habits. The API-driven workflow offers the highest level of automation and customization through scripts or integrations but requires more setup and technical effort. Overall, the CLI-driven workflow strikes a balance between ease of use, control, and cloud-backed reliability, making it a strong choice for individuals or small teams.

Give your Workspace a name and click on Create.

Click on your account logo. Then click on Account settings.

Click on Tokens to generate one.

Click on Create an API token

Give your token a Description and click on Generate token

Copy the token and navigate to your VS code.

Run the code terraform login. Type yes to proceed. Just** right click** and p*ress the enter key* when asked to provide the Token for app.terraform.io.

You should get the picture below;

Navigate back to Terraform cloud to copy your code. To locate the code. Click on Choose an organization at the bottom left hand corner of the page. Then click on your organization name.

Click on your Workspace name. In this case Musa-workspace.

Boom there is your configuration code block. Copy the segment of it highlighted below.

We now need to add the code block to our Terraform configuration files to set up the cloud integration. Navigate to VS code, click on main.tffile and paste the copied code block between line 7 and 9 (i.e line 8) and CTRL S **to **save. You should have something like the one below;

Navigate to VS code and run terraform login again. Click on generate a new token. Copy it and proceed to right click in the VS code. You should get the result below once again.

Navigate to terraform cloud and click on State. It can be seen no saved states yet.

Navigate to VS code and Run terraform init. Afterwards check state in terraform cloud. You should now see it in shaa Allah.

From the foregoing we have successfully migrated terraform.tfstate file to terraform cloud (Remote setting).

We can decide to delete it from our local state with the command **rm terraform.tfstate**. Since we already have it in the remote state.

Bonus
If you already had existing resources, you can run the command terraform import azurerm_resource_group.test 'full resource id'

To get the full resource id;
Navigate to Azure (in this case), Resource group then settings. Click on Properties and copy the resource id.

in VS code run the command above. Thereafter run terraform initand yes when appropriate. Visit terraform cloud to find your State.

List of Achievements

Created a Terraform Cloud account via the official signup portal.
Verified the email address to activate the Terraform Cloud account.
Created a new organization in Terraform Cloud to group and manage infrastructure projects.
Created a workspace using the** CLI-driven workflow**, ideal for terminal-based operations.
**Generated an API token **for secure authentication between Terraform CLI and Terraform Cloud.
Logged in to Terraform Cloud from the terminal using terraform login.
Copied and added the remote backend configuration block into the local main.tf file.
Ran terraform init to reinitialize the project and migrate the state to the remote backend.
Confirmed successful state migration by verifying the uploaded state in Terraform Cloud.
Optionally deleted the local terraform.tfstate file to avoid duplication and conflicts.
(Bonus) Demonstrated how to import existing Azure resources into Terraform using terraform import.

Hands-On Guide to Azure Infrastructure as Code Using Terraform and GitHub

Bala Audu Musa — Fri, 09 May 2025 14:42:05 +0000

Have you wondered how you could build resources in the cloud without the normal clickings? For example:

You write down (in code):
"I want a resource group in Azure, name it test-group and put it in East US."

That is what exactly Terraform does. How does it do this?

Terraform reads that note.

It logs into Azure **or any other cloud providers and **builds exactly what you asked for, all from the code terminal — no clicks needed.

You then login to your cloud provider portal to check and boom - there is everything, already created for you. Sounds cool right?

Terraform is like a recipe book for building things in the cloud.
Just like how:

A recipe tells your kitchen what ingredients to use and how to cook,

Terraform code tells Azure (or any cloud) what to build — like a virtual machine, database, or storage.

Terraform is an infrastructure-as-code (IAC) software tool created by HashiCorp. The user tells Terraform what cloud resources to build, and Terraform builds them.

After understanding completely what terraform is all about, let us understand some basic terraform commands.

Commands in Terraform.

terraform init

"Get ready!" – Sets things up and downloads what Terraform needs.

terraform plan

"What will happen?" – Shows what it would build or change.

`terraform apply

"Go!" – Actually builds the stuff in the cloud.

terraform destroy
"Clean up!" – Destroys everything you made.

terraform fmt

"Make it neat!" – Fixes spacing and formatting in our files.

terraform validate
"Is this okay?" – Checks if your code has mistakes.

terraform show

"What did I build?" – Shows details of what exists now.

terraform output

"Give me the results." – Shows final values after building stuff.

terraform version

"What version is this?"– Tells you the Terraform version.

Setting Up Terraform on Windows

There are two ways this can be done;

Manual Download of terraform and adding its path to environment variable on Windows.
Running the command; choco install terraform in Windows PowerShell. ---

A. Manual Installation
i. Go to [https://developer.hashicorp.com/terraform] and click on Install.

ii. Select your operating system and your processor architecture. In this case Windows was selected and the download **in front of **amd64 was clicked to download the terraform file.

Brief Expo
The choice between 386 and AMD64 when downloading Terraform (or any software) depends on your computer's CPU architecture — specifically whether it's a 32-bit or 64-bit system.

Use 386 if your PC is very old or 32-bit, and AMD64 if your PC is modern and 64-bit (which is most systems today).

IN SIMPLE TERMS
If your computer is newer than 2010, you almost definitely need amd64.

Continuation...
When the folder has downloaded, a pop-up will be seen has shown below.

Double click on the pop-up or go to file manager and click on Downloads to reveal it. It will be noted that it is a zip folder. Right click and click on Extract all to have access to its contents.

Click on Extract

Once extraction is done. Right click on the** terraform file** and copy the path. But for the system we are using the option to copy path is absent. Hence, we must setup terraform using the second method.

But for those whose system has the option, I will go on and explain how they can get it done.

Navigate to the Windows start menu and search for Environment variables. Click on Edit the system environment variables.

System properties dialog box will open up. Under Advanced option click on Environment variables...

Under System variables select Path and click on Edit...

Click on New... and paste the terraform path you had copied while ensuring it is without quotation marks. Ok every opened dialog box and proceed to sign-in to GitHub account to create a repository.

Before proceeding to GitHub, let's recall that we weren't able to setup terraform with the first method. Now let's use the second method.

B. Running the command; choco install terraform in **Windows
PowerShell.**

Navigate to the Windows start up menu search bar and type in PowerShell and click on Run as administrator.

Before you run choco install terraform, here are the prerequisites in very simple terms:

i. Windows OS: You're using a Windows computer (Chocolatey is for
Windows).

ii. Admin Access: You must run PowerShell or Command Prompt as
Administrator.

iii. **Chocolatey Installed: **You need to have Chocolatey installed
first.

Run the command: choco install terraform. When prompted if you want to run the Script?, type 'A' to answer yes to all and press the Enter key. You should get the result below.

To further confirm if successfully installed, run the command terraform --version. You should get something like Terraform v1.11.4. Thus indicating successful installation.

PREPARATION OF GITHUB TO COMMUNICATE WITH VS CODE
in GitHub, click on the drop-down arrow, then click on New repository to create one.

Give the repository a name, in this case Repo1 and click the box of Add a README file to tick it.

Click on Create repository to create the repository.

Click on Code **and click on the highlight **copy symbol to copy the HTTP URL.

NUGGET;
We use the HTTP URL to clone with Visual Studio (VS) because it works without extra setup, while SSH and GitHub CLI need extra configuration or tools installed.

We now need to clone the created repository in VS code.

CLONING A GITHUB REPOSITORY IN VS CODE

Open VS code and begin by installing the terraform extension. Click on the extensions icon on the left, then in the search bar type terraform and install the HashiCorp terraform.

Once it has finished installing, you should see the terraform extension icons to the left as hightlighted below.

TO CLONE...
Navigate to the Source control icon on the left and click. Then click on the Clone repository option.

Click on the Clone from GitHub option.

Click on your created repository name in GitHub among the listed options.

Right click in the open dialog box. Then click on New and then Folder to create a folder for your repository.

Give your folder a name, press the Enter key and click on Select as repository destination.

Click on** Open** in the pop-up dialog box.

The repository has successfully been cloned into VS code has highlighted below.

CREATING A main.tf file.
A main.tf file is like the main recipe in Terraform — it tells Terraform **what to build **in the cloud, like virtual machines or networks.

Simple Example:
If Terraform is a cook, main.tf is the instruction sheet saying:

"Make 2 pizzas (VMs), 1 drink (storage), and serve it on a tray (network)."

Without main.tf, Terraform wouldn’t know what you want it to create. Hence this must be kept safe.

To continue...
Click on the file icon in front of the repository name. Type into the empty bar main.tfand press the Enter button.

The main.tf file has just been created.

From the foregoing, the field has been prepared for us to begin planting.

CONNECTING TERRAFORM TO CLOUD SERVICE PROVIDER (AZURE)

We connect Terraform to a cloud service provider **like **Azure so it can create and manage real cloud resources for us automatically, like virtual machines, storage accounts, or networks — instead of us clicking around manually in the Azure Portal.

Layman Analogy:
Imagine** Terraform is a **remote control, and Azure is your smart TV.
To change the channel (make cloud changes), Terraform needs to connect to the TV (Azure) — otherwise, the remote won’t do anything.

What do Providers do?
A provider is a plugin that allows Terraform to interact with external systems — like cloud platforms (e.g., AWS, Azure, Google Cloud), SaaS services (e.g., GitHub, Cloudflare), or even local systems.

Go to [https://registry.terraform.io/browse/providers] and among the various providers, click on Azure as we intend using Azure Cloud.

Click on USE PROVIDER

Copy the code

Paste the code into the main.tf file created in VS code. Make the following adjustments into the code
In line 11: Delete the comment # Configuration options and replace with features {. Note that as you type features, the features plugin starting prompting, just select it.

Move the curly brace in Line 13 to 14 and type in its stead subscription id. Select it when prompted and input your Azure subscription id copied from your Azure account. Ensure that your subscription id is within quotation marks.

Click on the three dots(...) in front of Run in the VS code interface. Then click on Terminal. Then click on New terminal to start running the Terraform commands.

THE **terraform init Command**
terraform initprepares your project to use Terraform by downloading the necessary provider plugins (like AWS, Azure, etc.). It sets up your working directory and configures backend settings if needed. It also locks provider versions to ensure consistency in future runs. This information is stored in a file called **.terraform.lock.hcl.**as can be seen below.

CREATING RESOURCES IN AZURE WITH TERRAFORM
Ask any of the AI chatbots or large language model (LLM) assistants like ChatGPT, DeepSeek etc to write you any terraform code for anything you want to create. We will be using the following code as an example.
`
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "4.27.0"
}
}
}
provider "azurerm" {
features {}
subscription_id = "5fdd1cff-4911-4d4a-b28a-969756021e0f"
}

resource "azurerm_resource_group" "test" {
name = "acctestrg"
location = "West US 2"
}

resource "azurerm_virtual_network" "test" {
name = "acctvn"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name
}

resource "azurerm_subnet" "test" {
name = "acctsub"
resource_group_name = azurerm_resource_group.test.name
virtual_network_name = azurerm_virtual_network.test.name
address_prefixes = ["10.0.2.0/24"]
}

resource "azurerm_public_ip" "test" {
name = "publicIPForLB"
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name
allocation_method = "Static"
}

resource "azurerm_lb" "test" {
name = "loadBalancer"
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name

frontend_ip_configuration {
name = "publicIPAddress"
public_ip_address_id = azurerm_public_ip.test.id
}
}

resource "azurerm_lb_backend_address_pool" "test" {
loadbalancer_id = azurerm_lb.test.id
name = "BackEndAddressPool"
}

resource "azurerm_network_interface" "test" {
count = 2
name = "acctni${count.index}"
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name

ip_configuration {
name = "testConfiguration"
subnet_id = azurerm_subnet.test.id
private_ip_address_allocation = "Dynamic"
}
}

resource "azurerm_managed_disk" "test" {
count = 2
name = "datadisk_existing_${count.index}"
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name
storage_account_type = "Standard_LRS"
create_option = "Empty"
disk_size_gb = "1023"
}

resource "azurerm_availability_set" "avset" {
name = "avset"
location = azurerm_resource_group.test.location
resource_group_name = azurerm_resource_group.test.name
platform_fault_domain_count = 2
platform_update_domain_count = 2
managed = true
}

resource "azurerm_virtual_machine" "test" {
count = 2
name = "acctvm${count.index}"
location = azurerm_resource_group.test.location
availability_set_id = azurerm_availability_set.avset.id
resource_group_name = azurerm_resource_group.test.name
network_interface_ids = [element(azurerm_network_interface.test.*.id, count.index)]
vm_size = "Standard_DS1_v2"

# Uncomment this line to delete the OS disk automatically when deleting the VM
# delete_os_disk_on_termination = true

# Uncomment this line to delete the data disks automatically when deleting the VM
# delete_data_disks_on_termination = true

storage_image_reference {
publisher = "Canonical"
offer = "UbuntuServer"
sku = "16.04-LTS"
version = "latest"
}

storage_os_disk {
name = "myosdisk${count.index}"
caching = "ReadWrite"
create_option = "FromImage"
managed_disk_type = "Standard_LRS"
}

# Optional data disks
storage_data_disk {
name = "datadisk_new_${count.index}"
managed_disk_type = "Standard_LRS"
create_option = "Empty"
lun = 0
disk_size_gb = "1023"
}

storage_data_disk {
name = element(azurerm_managed_disk.test..name, count.index)
managed_disk_id = element(azurerm_managed_disk.test..id, count.index)
create_option = "Attach"
lun = 1
disk_size_gb = element(azurerm_managed_disk.test.*.disk_size_gb, count.index)
}

os_profile {
computer_name = "hostname"
admin_username = "testadmin"
admin_password = "Password1234!"
}

os_profile_linux_config {
disable_password_authentication = false
}

tags = {
environment = "staging"
}
}`

BREAKDOWN OF WHAT SPECIFIC AREAS OF THE CODE DOES.
1. Specify the Provider

terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "4.27.0" } } } provider "azurerm" { features {} subscription_id = "5fdd1cff-4911-4d4a-b28a-969756021e0f" }
These lines tell Terraform to use Azure (azurerm) as the cloud provider and connect to your Azure subscription.

2. Create a Resource Group

resource "azurerm_resource_group" "test" { name = "acctestrg" location = "West US 2" }
Creates a resource group in Azure named "acctestrg" where all other resources will live.

3. Create a Virtual Network

resource "azurerm_virtual_network" "test" { name = "acctvn" address_space = ["10.0.0.0/16"] location = azurerm_resource_group.test.location resource_group_name = azurerm_resource_group.test.name }
Creates a virtual network (VNet) for your infrastructure with an address space of 10.0.0.0/16.

4. Create a Subnet inside the VNet

resource "azurerm_subnet" "test" { name = "acctsub" resource_group_name = azurerm_resource_group.test.name virtual_network_name = azurerm_virtual_network.test.name address_prefixes = ["10.0.2.0/24"] }
Defines a subnet within the virtual network using 10.0.2.0/24.

5. Create a Public IP Address

resource "azurerm_public_ip" "test" { name = "publicIPForLB" location = azurerm_resource_group.test.location resource_group_name = azurerm_resource_group.test.name allocation_method = "Static" }
Sets up a static public IP address to be used by a load balancer.

6. Create a Load Balancer

resource "azurerm_lb" "test" { name = "loadBalancer" ... frontend_ip_configuration { name = "publicIPAddress" public_ip_address_id = azurerm_public_ip.test.id } }
Creates an Azure load balancer using the public IP defined earlier.
**

Define a Backend Pool for Load Balancer**

resource "azurerm_lb_backend_address_pool" "test" { loadbalancer_id = azurerm_lb.test.id name = "BackEndAddressPool" }
Creates a backend pool for the load balancer to distribute traffic to virtual machines.

8. Create Network Interfaces (NICs)

resource "azurerm_network_interface" "test" { count = 2 ... ip_configuration { subnet_id = azurerm_subnet.test.id private_ip_address_allocation = "Dynamic" } }
Creates 2 network interfaces that will be attached to the virtual machines and connected to the subnet.

9. Create Managed Disks

resource "azurerm_managed_disk" "test" { count = 2 ... create_option = "Empty" disk_size_gb = "1023" }
Creates 2 managed data disks (empty, 1023 GB each) that will be attached to the virtual machines.

10. Create Availability Set

resource "azurerm_availability_set" "avset" { ... managed = true }
Creates an availability set to improve high availability of virtual machines by spreading them across fault and update domains.

11. Create Virtual Machines

resource "azurerm_virtual_machine" "test" { count = 2 ... vm_size = "Standard_DS1_v2" storage_image_reference { publisher = "Canonical" ... } os_profile { computer_name = "hostname" admin_username = "testadmin" admin_password = "Password1234!" } os_profile_linux_config { disable_password_authentication = false } tags = { environment = "staging" } }
Creates 2 Ubuntu Linux virtual machines:

Each VM uses a network interface.

Attaches one new data disk and one previously created disk.

Uses an Ubuntu image.

Sets a username and password.

Adds a tag for the environment.

RUNNING COMMANDS CONTINUE..
Run terraform init again because we have paste into the terminal a fresh command codes.

Run terraform plan -out main.tfplan
The command terraform plan -out main.tfplan creates a plan and saves it to a file named main.tfplan instead of just showing it on screen.

It can be noted that when the code was run main.tplan file was added as shown in the picture below.

LOGGING INTO AZURE
Run the code az login. You will then be pompted to selected the appropriate email attached to your account. Select and click on Continue.

You then be asked to select the active subscription if you have more than one. Input the appropriate number and press the Enter key.

Run the terraform apply code
terraform apply actually executes the changes described in your Terraform plan, creating, updating, or deleting resources in your infrastructure. When prompted to enter a value, type yes and press the Enter key.

terraform apply actually executes the changes described in your Terraform plan, creating, updating, or deleting resources in your infrastructure.

Navigate to Azure and appreciate the resources created automatically without clickings

Click on the first Resource group to view its contents

Click on the second Resource group to also view its content

Run the **terraform destroy** command
terraform destroy deletes all the infrastructure resources that were created by your Terraform code, effectively tearing down your setup.

Navigate to Azure portal and ensure all the created resources have been deleted. If not manually delete them to avoid incurring charges.

TAKEHOME FROM THE PROJECT
Understanding Terraform

Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp.
It lets you describe cloud infrastructure in code instead of manually clicking through portals.
You can specify resources like:

Resource groups
Virtual machines
Databases
Storage

Terraform uses code to log into cloud providers (like Azure) and build exactly what you describe.

Analogy: Like a recipe for cloud infrastructure – you write instructions, and Terraform cooks it for you.

Core Terraform Commands

Setting Up Terraform on Windows
Method A: Manual Installation

Download Terraform from the official site.
Choose the correct version (amd64 for modern 64-bit systems).
Extract the downloaded ZIP folder.
Copy the path of the Terraform executable.
Add the path to your Windows Environment Variables under the System Path.

Method B: Using Chocolatey

Open PowerShell as Administrator.
Ensure Chocolatey is installed.
Run choco install terraform.
Confirm installation by running terraform --version.
Preparing GitHub for Terraform Projects
Create a GitHub account if you don’t have one.
Create a new repository (e.g., Repo1).
Enable README creation in the new repo.
Copy the
HTTP URL for cloning (easiest method for VS Code).
Cloning GitHub Repository in VS Code
Install Terraform extension in VS Code.
Open Source Control → Clone Repository → Paste URL or select GitHub repo.
Create/select a folder for the project.
Confirm cloning and open the repo in VS Code.

Creating the main.tf File

main.tf is the primary configuration file where resources are declared.
It acts like the instruction sheet for Terraform.

Connecting Terraform to Azure
Providers are plugins that allow Terraform to communicate with external systems (like Azure).

Visit Terraform Registry and select Azure Provider.

Copy and paste provider block into main.tf.
Modify the config to include:
features {} block
Your Azure subscription_id (inside quotes)

Running Terraform Commands in VS Code
Open a new terminal in VS Code.

Run terraform init to initialize and lock dependencies.

The .terraform.lock.hcl file is generated after init for dependency consistency.

Building an Azure Web App.

Bala Audu Musa — Fri, 04 Apr 2025 07:54:19 +0000

Objective:
Our objective this time as a DevOps Engineer is to build a web application following a cloud-first approach and hosting the application on Azure App Service.

Our tasks:
i. Pushing the application code to GitHub using Git Bash
ii. Deploying the application to Azure App Service using Azure CLI

For better understanding of what are getting ourselves into, let us understand some key GitHub terminologies;

Fork: To create a copy of the original repository.
Clone: To download a copy of the forked repository to your machine.
Branch: To create a new branch to work on your changes.
Commit: **To save your changes to the repository.
**Push: **To upload your changes to your remote repository.
**Pull Request: To submit your changes for review.
Repository: A repository (or repo) in GitHub is a storage location where your project files, including code, documentation, and other resources, are kept. It tracks changes to these files over time, allowing collaboration, version control, and backup of your work.

NOW LET'S GET STARTED.

a) Create a new repository in Github. Give the repository a name. In this case Ittisalat App. Give it a description. Determine who can commit to the repository. In this case left it in the default Public. Tick the box of Add a README. README File usually contains an introduction to the project, instructions, or documentation.

b) Select from the drop-down options of Add .gitignore. This basically choose which files not to track from a list of templates. In this case I had none. Hence, I selected .gitignore template: None. Same for Choose a license **. A license tells others what they can and can't do with your code. Then click on **Create repository.

We are now going to create an index file in Git Bash and Push to GitHub.

c) Open Git Bash and click on Run as administrator. It will prompt you if you want this app to make changes to your device. Click on yes.

d) Configure the Git Bash environment by typing the following commands into the terminal.
To Configure username as in Git Hub:
git config --global user.name Bamboo-cod

To configure useremail address:
git config --global user.email freshabdullaah@mail.com.

Create a directory:
Type mkdir IttisalatApp

Enter into the just created directory by typing the command;
cd IttisalatApp. We can now see that we are now inside the directory depicted by the forward slash "/" before our directory name. Shown in the yellow box.

Initialize the created directory on the local host
git init + ENTER Button

Link git terminal to github.

Create an index.html file on git using this command:
touch index.html + Enter button

In order to input the index.html code open up an editor in the git terminal using the following command:
vi index.html

Use any of the artificial intelligence application like **Chatgpt, Perplexity or Deepseek **to generate an html code for the particular app you want to create. For example I typed in the following prompt into Deepseek ai:

The following result was generated (cut):

Copy and paste the html code into the text editor. Inorder to paste type the "i" button. Right click and then paste. Ensure the code is well aligned.

Snapshot of the code in git;

Save and exit editor by pressing the ESC button and colon (:)wq + Enter button.

Go to your Github account click on the green Code button and copy https code.

Go back to the terminal and type in the following command:
***git remote add originleave a space https://github.com/bamboo-cod/IttisalatApp.git*

The command **git remote add origin https://github.com/bamboo-cod/IttisalatApp.git **links your local Git repository to a remote repository on GitHub.

Then type the command git add index.html The command git add index.html stages the index.html file in Git, preparing it to be included in your next commit.

Type the following code
git commit -m "My first social App" and enter.

Inorder to move the master branch, type the following command
git push origin master and enter

Go back to Github and check your code. You might be asked to verify and authenticate. Tick on compare and pull request.

Type in az login into the GitBass terminal

It will then prompt you to sign in. Select the appropriate email linked to your azure account and click on continue.

The terminal could not recognize my subscription. So i had to type the following prompt: *az login --tenant 42cbee7b-bcaa-4a28-9f5f-1cf6f023a10d
*
output:

Create a Resource Group if you dont have one. Input the following command:az group create --name IttisalatApp(i.e: name of your resource group in azure) -location uksouth

Create an App Servicer Plan. An App Service Plan in Azure is a foundational component that defines the compute resources and configuration for hosting web applications, APIs, mobile backends, and other services within Azure App Service.

Type into the terminal the following command:
az appservice plan create --name IttisalatAppServ --resource-group IttisalatApp

I got an error:- MissingSubscriptionRegistration

Meaning: My Azure subscription lacks the necessary registration for the Microsoft.Web resource provider, which is required for Azure App Service (and related resources like App Service Plans).

I had to rectify this problem by doing the following:

az provider register --namespace Microsoft.Web

Verifying the registration status by typing into the terminal the following command: az provider show --namespace Microsoft.Web --query "registrationState"

Create the Web App using the following command: az webapp create --name IttisalatWebApp --resource-group IttisalatApp --plan IttisalatAppServ

A quick run on History shows the commands so far:

Deployment of the Web App
**
**az webapp deployment source config --name IttisalatApp --resource-group IttisalatApp --repo-url https://github.com/bamboo-cod/IttisalatApp.git --branch master --manual-integration

This command does one simple thing:

Connects your Azure Web App (named "IttisalatApp") to a GitHub repository so that you can deploy code manually from the master branch of that repo.

Breakdown:

az webapp deployment source config: "Set up where the app's code comes from."
--name IttisalatApp: "The name of your Azure Web App."
--resource-group IttisalatApp: "The resource group where your app lives in Azure."
--repo-url https://github.com/...: "Link to your GitHub code repository."
--branch master: "Use code from the master branch of the repo."
--manual-integration: "Azure won’t auto-deploy when you push code to GitHub. You’ll have to trigger deployments manually."

What happens next?

After running this command:

Azure knows where your code is stored (GitHub).
When you’re ready to deploy, you’ll need to manually sync or trigger a deployment (e.g., via the Azure Portal or CLI).

This shows we have successfully deploy our web app.

To verify log into the azure account.

Clicking on the Default domain url: ittisalatwebapp.azurewebsites.net

Creating a deployment slot
A deployment slot in Azure is like a separate, isolated instance of your web app that allows you to test changes in a staging environment before swapping it with production. Think of it as a "copy" of your live app where you can safely deploy and validate updates without affecting real users.

Click on Upgrade

Select the first premium service

Click on select and Upgrade

Click on Add Slot
Give the slot a name and click on add

After working on the readjustment of the webapp in the background, click on swap to grant full traffic to users.

DEV Community: Bala Audu Musa

Weather Report Automation

MULTI-CONTAINER SYSTEM + REVERSE PROXY (CONSOLIDATION)

CI/CD Pipeline for a Dockerized App on AWS (From zero to production).

Provisioning AWS Infrastructure Using Terraform (IaC)

Multi-Container Web Application with Nginx Reverse Proxy and Docker Compose

🚀 What This Project Demonstrates

🧱 Architecture Overview

📁 Project Structure

⚙️ Technologies Used

🛠 How to Run the Project Locally

Prerequisites

Steps

I Set Up My Windows 11 Machine Once for All DevOps Projects — Here’s How.

INTRODUCTION:

Create an Ansible Playbook to Install Git on managed host

How to Set Up Passwordless SSH from Control Host Managed Host

Copy-Paste Not Working Between Windows and Ubuntu VirtualBox? Here's the Fix!"

Transitioning Terraform State File from Local to Remote Backend

Hands-On Guide to Azure Infrastructure as Code Using Terraform and GitHub

Click on New... and paste the terraform path you had copied while ensuring it is without quotation marks. Ok ** every opened **dialog box and proceed to sign-in to GitHub account to create a repository.

Building an Azure Web App.

Breakdown:

What happens next?

Click on New... and paste the terraform path you had copied while ensuring it is without quotation marks. Ok every opened dialog box and proceed to sign-in to GitHub account to create a repository.