In this blog, I’ll break down the key concepts from Lecture 1, including:

• Chatbot vs Agent differences

• Agent architecture

• Why the “Agent Era” has started

• Operational challenges

• Scaling AI agents in production

Let’s dive in.

🧠 Chatbot vs AI Agent — The Fundamental Difference

The lecture begins by explaining the core difference.

A chatbot is reactive — it waits for input and produces a response.

An AI agent, however, is proactive — it can decide, plan, and execute tasks.

According to the slide on page 1, the key differences are:

Chatbot

• Role: Interface

• Function: Reactive

• Output: Answers questions

• Status: No real decision-making

AI Agent

• Role: Operator

• Function: Goal-driven

• Output: Executes workflows

• Status: Makes decisions

👉 The best summary from the slide:

“One waits for input; the other takes action.”

1

🔄 How Chatbots Work vs How Agents Work

The architecture is completely different.

Chatbot Flow

As shown on page 2, chatbot processing is simple:

Input → LLM Prediction → Output

Characteristics:

• Stateless

• Single-shot response

• No memory

• No tool usage

Agent Loop

Agents operate in a continuous loop:

• Perception (understanding input)

• Reasoning (planning)

• Tool usage

• Action

• Reflection (self-correction)

This makes agents:

• Stateful

• Multi-step

• Self-correcting

• Capable of retries

  1

🚀 Why We Entered the “Agent Era”

According to page 3, three major technological advancements made AI agents possible:

1️⃣ Reasoning Costs Dropped

Modern models like GPT-4 can plan tasks efficiently.

2️⃣ Tool Interfaces Standardized

Universal function calling allows agents to interact with APIs easily.

3️⃣ Memory Systems Matured

Vector databases allow agents to retain context and history.

Because of these changes, AI is evolving:

From AI as a Copilot → To AI as a Teammate.

1

🏗️ The Architecture of an AI Agent

A powerful diagram on page 4 explains the four core components.

Agent = LLM + Memory + Tools + Planning

Let’s break them down.

👁️ Perception (The Eyes)

Inputs from:

• Databases

• Slack messages

• Webhooks

• APIs

🧠 Reasoning (The Brain)

Handles:

• Planning

• Tool selection

• Reflection

🧾 Memory (The Context)

Stores:

• Chat history

• Vector embeddings

• State information

✋ Action (The Hands)

Executes tasks:

• API calls

• Scripts

• File operations

  1

⚖️ Deterministic vs Probabilistic Systems

A very important concept appears on page 5.

Traditional Microservices

• Deterministic behavior

• Predictable latency (~200ms)

• Fixed cost

AI Agents

• Probabilistic behavior

• Variable latency (reasoning loops)

• Cost varies widely

This means:

👉 Agents are powerful but harder to predict.

⚠️ Operational Challenges of AI Agents

Running agents in production introduces new risks.

According to page 6, major hazards include:

💰 Cost Control

Infinite reasoning loops can burn budget quickly.

🔍 Observability

Traditional CPU metrics are insufficient — we need to track decision paths.

🔐 Security

Agents may have shell or system access, creating risk.

🧠 State Management

Maintaining memory consistency across failures is difficult.

1

🛡️ Introducing AgentOps

To manage agents safely, a new discipline is emerging: AgentOps.

The diagram on page 7 highlights key principles:

• Flight Recorder → Capture reasoning chains

• Circuit Breaker → Stop runaway loops

• Guardrails → Prevent dangerous actions

Goal:

Operate autonomous systems reliably and securely.

1

📈 Scaling AI Agents in Production

According to page 8, real-world deployments require handling:

• 10,000 parallel agent loops

• 50+ external APIs

• Distributed state management

This shows:

👉 Deploying agents is easy.

👉 Orchestrating them at scale is the real challenge.

🔮 The Future of DevOps: Managing Intelligence

The final slide (page 9) gives a powerful insight:

Yesterday → Managing stateless microservices

Tomorrow → Managing stateful decision systems

This changes the DevOps role dramatically:

You are no longer just keeping servers up — you are keeping intelligence aligned.

1

🧩 Final Thoughts

AI agents represent a massive shift in computing:

• From reactive systems → To autonomous decision makers

• From static workflows → To dynamic reasoning loops

• From infrastructure management → To intelligence management

This is why we are entering the Agent Era.

What is RHCSA?

RHCSA stands for Red Hat Certified System Administrator.

Why RHCSA is Important

• Industry-recognized Linux certification

• Required for Linux system administration jobs

• Builds strong foundation in:

  • Linux OS

  • Users & permissions

  • Filesystems

  • Networking

  • Services & processes

• Useful for DevOps, SysAdmin, Cloud, and Server roles

How We Install Linux for Practice

We do not install Linux directly on our main system. Instead, we use Virtualization.

Virtual Machine (VM)

• We use VMware (or VirtualBox)

• A VM allows us to run an OS inside another OS

• Example:

  • Host OS: Windows

  • Guest OS: RHEL / CentOS / Rocky Linux

Installation Steps (High Level)

1. Install VMware

2. Create a new Virtual Machine

3. Attach Linux ISO file

4. Allocate:

   • RAM

   • CPU

   • Disk

5. Install Linux OS inside VM

✅ This method is safe and widely used for learning and testing

Day 2: Linux Directory Structure & Basic Commands

Root Directory /

Linux has a single root directory /. Everything starts from here.

Important System Directories

Basic Commands Learned

whoami

➡ Shows current logged-in user

ls

➡ Lists files and directories

cd

➡ Changes directory

Examples:

cd /etc
cd ..
cd ~

Linux Terminal Prompt Explained

Example:

hassan@server1:/home/hassan$

✅ Correction:

• $ → normal user

• # → root (admin) user

Day 3: How Linux OS Boots + File Commands

How Operating System Works (Boot Process)

Correct boot order:

1. BIOS / UEFI

   • Initializes hardware

2. Bootloader (GRUB2)

   • Loads the kernel

   • Allows selecting different OS

3. Kernel

   • Core of OS

   • Manages CPU, memory, devices

4. init / systemd

   • Starts services

5. Login Screen

   • OS is ready to use

✅ Correction:

• BIOS does not load the OS directly

• BIOS/UEFI loads the bootloader

• Bootloader loads the kernel

• Kernel starts the OS

Multiple OS Concept

• If multiple OS are installed

• GRUB menu allows choosing which OS to boot

🧠 One-Line Memory Trick

• Linux:
  UEFI → GRUB → Kernel → systemd → Services → Ready

• Windows:
  UEFI → Boot Manager → Kernel → Services → Login → Ready

File Commands

cp source destination

➡ Copy files or directories

Examples:

cp file1 file2
cp -r dir1 dir2

mv source destination

➡ Move or rename files

Examples:

mv file1 /tmp
mv oldname newname

Change Hostname

Temporary:

hostname newname

Permanent (Recommended):

hostnamectl set-hostname newname

Day 4: BIOS vs UEFI, Editors & Practice Tasks

BIOS vs UEFI

✅ UEFI is used in modern systems

Text Editors

Linux has command-line editors.

Nano (Easy)

nano file.txt

• Easy to use

• Shortcuts shown at bottom

• Save: CTRL + O

• Exit: CTRL + X

Vim (Advanced)

vim file.txt

Modes:

• Normal mode (default)

• Insert mode → i

• Command mode → :

Common commands:

i        # insert mode
:w       # save
:q       # quit
:wq      # save and quit
:q!      # quit without saving

Practice Tasks

• Create files

• Edit files using nano & vim

• Copy and move files

• Rename files

• Change hostname

• Navigate directories

✅ Summary

You learned:

• RHCSA basics and importance

• Linux installation using VMware

• Linux directory structure

• Basic Linux commands

• Boot process (BIOS → GRUB → Kernel → OS)

• BIOS vs UEFI

• File operations

• Nano & Vim editors

RHCSA – Class Notes (Day 5 & 6)

Day 5: File and Directory Management

Copying Directories

cp -r source_directory destination_directory

• -r → recursive (copy directory and all its contents)

• Example:

cp -r /home/hassan/docs /home/hassan/backup_docs

Deleting Files

rm filename

• Removes a file

rm -i filename

• Asks confirmation before deletion

Deleting Directories

rmdir directory_name

• Removes empty directories only

rm -r directory_name

• Removes directory and all contents recursively

rm -rf directory_name

• Removes directory and contents without warning

• ⚠️ Use carefully! Can delete important data

Wildcard *

• * is used to represent all files or directories

• Example:

rm *.txt

• Deletes all .txt files in current directory

Command Structure

command [options] [arguments]

• Command → what to do (ls, cp, rm)

• Options → modify behavior (-l, -r, -f)

• Arguments → files or directories to operate on

Example:

ls -l /home/hassan

Hidden Files

• Files starting with . are hidden

• Create a hidden file:

touch .hiddenfile

Clear Terminal

clear

• Clears the screen

Creating Directories

mkdir folder_name

Nested Directories

mkdir -p parent_folder/child_folder

• -p → create parent directories if they don’t exist

Creating Multiple Folders

mkdir folder{1..10}

• Creates folder1, folder2, … folder10

Creating Multiple Files

touch file{1..10}.txt

• Creates file1.txt → file10.txt

Viewing Directory Tree

tree directory_name

Day 6: Reading File Content & Searching

View File Content

cat

cat /etc/services

• Displays entire file content

more

more /etc/fstab

• Shows file page by page (use space to scroll)

less

• Better alternative to more

• Scroll forward/backward

less /etc/fstab

head

head -n 10 /etc/services

• Shows first 10 lines of file

tail

tail -n 10 /etc/services

• Shows last 10 lines of file

nl

nl /etc/services

• Shows file content with line numbers

Search Inside Files – grep

grep "pattern" filename

• Search for specific text in a file

• Example:

grep "ftp" /etc/services

With options

• -i → ignore case

• -c → show count of matching lines

• -v → show non-matching lines

• -n → show line numbers

Example:

grep -i "ftp" /etc/services
grep -c "ssh" /etc/services

Word Count – wc

wc filename

• Shows lines, words, characters

Options:

• -l → number of lines

• -w → number of words

• -c → number of bytes

• -m → number of characters

Example:

wc -l /etc/services
wc -w /etc/services

Redirection & Operators

• Redirect output to a file

ls > file.txt

• Overwrites file.txt with output of ls

• Append output to a file

ls >> file.txt

• Adds output to the end of file.txt

• Pipes (send output of one command to another)

cat /etc/services | grep ftp

✅ Correction:

• > → overwrite

• >> → append

• | → pipe (send output to another command)

Summary – Day 5 & 6

You learned:

• Copying, moving, deleting files and directories

• Wildcards * for multiple files

• Command structure (command → options → arguments)

• Hidden files and creating them

• Creating folders/files in bulk

• Reading files (cat, more, less, head, tail, nl)

• Searching in files (grep with options)

• Word count (wc)

• Redirection (>, >>) and pipes (|)

Day 7: Operators in Linux

Linux allows combining commands and controlling execution flow using operators.

1️⃣ Semicolon ;

• Purpose: Run multiple commands sequentially, regardless of whether previous commands succeed or fail

• Syntax:

command1; command2; command3

• Example:

echo "Hello"; ls; pwd

• Output:

  1. Prints “Hello”

  2. Lists files

  3. Shows current directory

✅ Note: Commands run one by one even if one fails.

2️⃣ Single Pipe |

• Purpose: Sends output of first command as input to second command

• Syntax:

command1 | command2

• Example:

cat /etc/services | grep ftp

• cat prints file → grep filters only lines containing “ftp”

3️⃣ Double AND &&

• Purpose: Run second command only if the first command succeeds

• Syntax:

command1 && command2

• Example:

mkdir test && cd test

• Only enters test folder if folder creation succeeds

4️⃣ Single AND &

• Purpose: Run command in background

• Syntax:

command &

• Example:

gedit file.txt &

• Opens gedit in background, so terminal is free to use

5️⃣ Double Pipe ||

• Purpose: Run second command only if the first command fails

• Syntax:

command1 || command2

• Example:

cd nonexistfolder || echo "Folder does not exist"

• If cd fails, prints warning

Summary of Operators

User and Group Management

Linux manages users and groups for access control and permissions.

Types of Users

Types of Groups

Commands (Basics)

• View current user

whoami

• View groups of a user

groups username

• View all users

cat /etc/passwd

• View all groups

cat /etc/group

✅ Corrections / Clarifications

1. UID ranges for system vs regular users:

   • System: 1–999

   • Regular: 1000+

2. Background operator: single & runs command in background, not a chain.

3. Pipes and logical operators (&&, ||) are different:

   • | → sends output to input

   • && / || → controls execution flow

Examples

# Sequential execution
echo "Start"; ls; echo "End"

# Logical AND
mkdir demo && cd demo

# Logical OR
cd nofolder || echo "Folder not found"

# Background process
gedit file.txt &

# Pipe
cat /etc/services | grep ftp

This covers Day 7 operators + intro to user & group management.

RHCSA Day 8 – User and Group Management

User and group management is a core topic in RHCSA and very important for real-world Linux administration. On Day 8, we focused on creating users, managing passwords, understanding user IDs (UIDs), group IDs (GIDs), and how Linux stores user and group information internally.

1. Adding a New User

To create a new user in Linux, we use the useradd command.

useradd username

Example:

useradd ali

This command:

• Creates the user

• Assigns a UID automatically

• Creates a home directory /home/ali

• Assigns a default shell

⚠️ By default, the user does not have a password yet.

2. Setting or Changing User Password

To set or change a password, use:

passwd username

Example:

passwd ali

You will be prompted to enter and confirm the password.

3. Checking User ID and Group Information

Check UID and GID

id username

Example:

id ali

Output shows:

• UID (User ID)

• GID (Primary Group ID)

• Secondary groups

Check Current Logged-in User

whoami

4. Types of Users in Linux

Linux has three main types of users:

5. Modifying a User (User Management)

The usermod command is used to modify user properties.

Example: Set Account Expiry Date

usermod -e 2026-12-31 ali

Lock a User Account

usermod -L ali

Unlock a User Account

usermod -U ali

6. Password Aging and Expiry

We can control password policies using chage.

chage username

Example:

chage ali

To view password aging info:

chage -l ali

You can:

• Set password expiry

• Force password change

• Set warning days

7. Users vs Groups

What is a User?

• An individual account

• Has its own UID

• Can log in

What is a Group?

• Collection of users

• Used to manage permissions easily

• Identified by GID

Groups make permission management easier instead of assigning permissions user by user.

8. Adding Groups

groupadd groupname

Example:

groupadd developers

9. Primary and Secondary Groups

Primary Group

• Each user has one primary group

• Assigned at user creation

• Used by default when creating files

Secondary Groups

• Additional groups a user belongs to

• Used for extra permissions

Add User to a Secondary Group

usermod -aG groupname username

Example:

usermod -aG developers ali

⚠️ -a is very important. Without it, existing groups will be removed.

10. Checking User and Group Files

Linux stores user and group information in /etc directory.

/etc/passwd

cat /etc/passwd

Contains:

• Username

• UID

• GID

• Home directory

• Shell

Passwords are not stored here.

/etc/shadow

cat /etc/shadow

Contains:

• Encrypted passwords

• Password expiry info

Only readable by root user.

/etc/group

cat /etc/group

Contains:

• Group name

• GID

• Group members

11. Summary (Day 8)

On Day 8, we learned:

• How to add users and set passwords

• How to check UID, GID, and group membership

• Difference between users and groups

• Primary vs secondary groups

• How to add users to groups

• User modification and password expiry

• Internal Linux files: /etc/passwd, /etc/shadow, /etc/group

This topic is very important for RHCSA exam and real Linux administration.

🔹 DAY 1 (Detailed)

1️⃣ What is CCNA?

CCNA (Cisco Certified Network Associate) is a foundational networking course by Cisco.

It helps you understand:

• How computers and devices communicate

• How data travels from one device to another

• Networking concepts used in real-world networks

CCNA is mainly focused on:

• Networking fundamentals

• OSI & TCP/IP models

• Routing and switching basics

• Protocols and troubleshooting

2️⃣ OSI Model (Detailed Explanation with Zoom Example)

The OSI (Open Systems Interconnection) Model is a 7-layer reference model used to understand how data moves in a network.

📌 Important:

• OSI is mostly used for learning and understanding

• Data flow:

  • Sender: Layer 7 → Layer 1

  • Receiver: Layer 1 → Layer 7

🔹 Layer 7 – Application Layer

• This is where the user interacts with the network

• Provides services to applications

Examples:

• Zoom

• Browser (Chrome)

• WhatsApp

• Email

📌 When you send a message on Zoom, it starts here.

🔹 Layer 6 – Presentation Layer

• Responsible for:

  • Encryption

  • Decryption

  • Compression

  • Formatting

Example:

• Zoom encrypts your message so no one else can read it

• Compresses data to reduce size

🔹 Layer 5 – Session Layer

• Creates, manages, and terminates sessions

• Keeps communication alive

Example:

• Maintains your Zoom meeting connection

• Handles reconnects if connection drops briefly

🔹 Layer 4 – Transport Layer

• Ensures data delivery

• Decides which protocol to use

Protocols:

• TCP: Reliable, ordered, slower (Zoom login, file transfer)

• UDP: Fast, no guarantee (Live video/audio)

🔹 Layer 3 – Network Layer

• Responsible for routing

• Uses IP addresses

• Finds the best path for data

📌 Routers work at this layer.

🔹 Layer 2 – Data Link Layer

• Uses MAC addresses

• Error detection

• Creates frames

📌 Switches work at this layer.

🔹 Layer 1 – Physical Layer

• Physical transmission of data

• No logic, no addressing

Examples:

• Ethernet cable

• Fiber optic cable

• Wi-Fi signals

📌 Hubs work at this layer.

3️⃣ TCP/IP Model (Real-World Model)

The TCP/IP model is used in real networking.

📌 OSI = learning model
📌 TCP/IP = practical model

4️⃣ Protocol (Detailed)

A protocol is a set of rules that devices follow to communicate.

Without protocols:

• Devices won’t understand each other

• Communication will fail

Examples:

• HTTP / HTTPS → Web

• TCP / UDP → Transport

• FTP → File transfer

📌 Communication happens using protocols on the same layer.

🔹 DAY 2 (Detailed)

1️⃣ Header

A header is extra information added to data by each layer.

Header includes:

• Source address

• Destination address

• Protocol information

• Control details

Each OSI layer adds its own header.

2️⃣ Encapsulation & Decapsulation (Detailed)

🔹 Encapsulation (Sender Side)

• Happens when data is sent

• Data moves from Layer 7 → Layer 1

• Each layer adds its header

📦 Envelope Example:

• Data = letter

• Each layer = one envelope

• Final envelope is sent on the wire

🔹 Decapsulation (Receiver Side)

• Happens when data is received

• Data moves from Layer 1 → Layer 7

• Each layer removes its header

📦 Receiver opens envelopes one by one until data reaches application.

3️⃣ Data Names at Each Layer

4️⃣ Networking Devices & OSI Layers

5️⃣ LAN & WAN

🔹 LAN (Local Area Network)

• Small network (home, office, school)

• Uses switches

🔹 WAN (Wide Area Network)

• Large network (cities, countries)

• Routers connect LANs

📌 Two or more routers connected together form a WAN

6️⃣ Bare Metal vs Shared Hosting

🔹 Bare Metal

• Dedicated physical server

• Full hardware access

• High performance

Example:
Company data center server

🔹 Shared Hosting

• Multiple users share same server

• Limited control

• Lower cost

Example:
Cheap website hosting

7️⃣ Unicast, Multicast & Broadcast

🔹 Unicast

• One sender → one receiver

• Most common communication

Example:
Sending message to one person on Zoom

🔹 Multicast

• One sender → selected group

Example:
Online live class to selected students

🔹 Broadcast

• One sender → all devices in network

Example:
ARP request

📌 Broadcast works only in LAN, not across routers.

✅ FINAL QUICK REVISION

• OSI = 7 layers

• TCP/IP = 4 layers

• Encapsulation = sender

• Decapsulation = receiver

• Hub → L1, Switch → L2, Router → L3

• LAN = local, WAN = network of LANs

• Bare metal = dedicated

• Shared hosting = shared

• Unicast / Multicast / Broadcast = delivery types

DAY 3 – Routers, Addressing & Real-World Infrastructure

1️⃣ Router (Introduction & Characteristics)

A router is a networking device mainly used to connect different networks.

🔹 Characteristics of a Router

1️⃣ Router is a Unicast Device

• A router forwards data from one sender to one specific destination

• It does not broadcast data to everyone

• Uses IP addresses to make decisions

✅ (Correct: Router = Unicast device)

2️⃣ Router is Used at the Edge of LAN and WAN

• Routers sit at the boundary (edge) between:

  • LAN (Local Area Network)

  • WAN (Wide Area Network)

📌 Example:

• Office LAN → Router → ISP / Internet (WAN)

3️⃣ Router is a Layer 3 Device

• Works at OSI Layer 3 (Network Layer)

• Uses IP addressing

• Makes routing decisions

4️⃣ Router is Used for Routing

• Routing = selecting the best path for data

• Router checks routing table and forwards packets

5️⃣ Routers Connect Different Networks

Router is used to communicate between two or more different networks.
If devices are on different networks, they cannot communicate directly.
A router acts as a gateway and forwards data from one network to another using IP addresses.

Example:
A device in 192.168.1.0/24 network can communicate with a device in 10.0.0.0/24 network only through a router.

If you want, I can also simplify it more for CCNA notes 📘

2️⃣ Router Ports (Corrected & Explained)

Your teacher showed router images and explained ports.

🔹 WAN Ports (Serial Ports)

• Serial ports are used for WAN connections

• Used to connect:

  • Router to router

  • Router to ISP

📌 Common WAN media:

• Fiber optic

• Radio link

• VSAT (Satellite)

✅ Correct term: Serial Interface / WAN Interface

🔹 LAN Ports (Ethernet Ports)

Routers have Ethernet LAN ports for local networks.

There are three main Ethernet speed types 👇

❌ Wrong terms corrected:

• “1 MB” ❌ → 10 Mbps / 100 Mbps / 1000 Mbps

• “Super fast” ❌ → Gigabit Ethernet

📌 These LAN ports connect:

• PCs

• Switches

• Servers

3️⃣ Router & Switch Hardware (Inside & Outside)

Your teacher showed inside and outside components.

🔹 Outside Components

• Ethernet ports

• Serial ports

• Power port

• Status LEDs

• Cooling vents

🔹 Inside Components

• CPU → Processes routing decisions

• RAM → Running configuration

• ROM → Bootstrap & POST

• Flash Memory → IOS storage

• Fan → Cooling

📌 Switches also have:

• CPU

• RAM

• Fan

• Ports
  (but switches work at Layer 2 mainly)

4️⃣ Addressing (Introduction)

Teacher explained that networking uses addresses.

🔹 Three Common Addresses

1️⃣ MAC Address
2️⃣ IP Address
3️⃣ Serial Address (covered later)

📌 For now, focus was on MAC & IP

5️⃣ MAC Address (Physical Address)

🔹 What is a MAC Address?

• MAC (Media Access Control) address is a physical address

• Assigned by the manufacturer

• Stored in network interface hardware

• Works at Layer 2

📌 Format example:
00:1A:2B:3C:4D:5E

🔹 One Device Can Have Multiple MAC Addresses

Your example is 100% correct ✅

A laptop can have:

• Wi-Fi MAC address

• Ethernet MAC address

• Bluetooth MAC address

📌 Reason:

• Each network interface has its own MAC address

6️⃣ Banking / FinTech Network Infrastructure (Real-World Example)

Teacher explained real banking infrastructure.

🔹 Head Office (Main Data Center)

• Central location

• Contains:

  • Core switches

  • Routers

  • Database servers

  • Application servers

This forms a LAN at headquarters.

🔹 Branch Offices

• Branches connect to head office

• Connection methods:

  • Fiber optic

  • Radio links

  • VSAT (Satellite)

This creates a WAN

🔹 ATM Network Flow (Corrected & Explained)

When a user enters ATM PIN:

1️⃣ ATM machine
→ connects to local switch

2️⃣ Switch
→ connects to router

3️⃣ Router
→ sends data via WAN (fiber / radio / VSAT)

4️⃣ Head Office Router
→ Head Office Switch

5️⃣ Switch
→ Database servers

6️⃣ DB server
→ verifies PIN & balance
→ response sent back through same path

📌 This is a real-time network transaction

7️⃣ Point-to-Point Communication (Important Concept)

Teacher explained FinTech / Banking communication type.

🔹 Point-to-Point

• One sender ↔ one receiver

• Bi-directional

• Very secure and reliable

📌 Used by:

• Banks

• FinTech apps

• ATM networks

🔹 Direction Types (Corrected)

📌 Banking uses bi-directional point-to-point,
❌ NOT broadcast or omni-directional.

✅ DAY-3 QUICK REVISION

• Router = Layer 3, Unicast, Routing device

• Router connects LAN ↔ WAN

• Serial ports → WAN

• Ethernet / Fast Ethernet / Gigabit Ethernet → LAN

• MAC address = physical address

• One device can have multiple MACs

• Banking networks use WAN + point-to-point

• ATM → Switch → Router → WAN → Head Office → DB

🔹 DAY 4 – MAC Address, IP Address & Number Systems

1️⃣ MAC Address (Detailed)

🔹 What is a MAC Address?

• MAC (Media Access Control) address is a physical address

• It is assigned by the manufacturer

• Stored in the network interface hardware

• Works at OSI Layer 2 (Data Link Layer)

• MAC address is unique worldwide

🔹 MAC Address Naming Conventions (Formats)

MAC address can be written in different formats, but the value remains the same.

Examples:

• Colon format:
  00:1A:2B:3C:4D:5E

• Hyphen format:
  00-1A-2B-3C-4D-5E

• Cisco format:
  001A.2B3C.4D5E

📌 These are just different representations, not different MACs.

🔹 MAC Address Structure

A MAC address is 48 bits total.

It is divided into two main parts:

✅ Corrected term:

• “Verder code” ❌ → Vendor code (OUI) ✅

📌 Example:

00:1A:2B | 3C:4D:5E
Vendor     Serial Number

2️⃣ IP Address (IPv4)

🔹 What is an IP Address?

• IP (Internet Protocol) address is a logical address

• Works at OSI Layer 3 (Network Layer)

• Used for routing and identification

• Can change (unlike MAC address)

🔹 IPv4 Address Structure

• IPv4 address is 32 bits

• Written in decimal dotted format

Example:

192.168.1.10

Each number is 8 bits (1 byte).

🔹 IP Address Parts

An IP address is divided into:

📌 Example:

192.168.1.10
Network   Host

3️⃣ Classes of IP Addresses

IPv4 addresses are divided into classes based on range.

🔹 IP Address Classes (Basic)

📌 Commonly used:

• Home & office → Class C

• Large companies → Class A / B

4️⃣ Number Systems in Networking

Networking uses three number systems:

🔹 Decimal

• Digits: 0–9

• Used by humans

• Example: 192

🔹 Binary

• Digits: 0 and 1

• Used by computers

• Example:

11000000

🔹 Hexadecimal

• Digits: 0–9 and A–F

• Used to represent binary in short form

• Commonly used in MAC addresses

5️⃣ Binary ↔ Hexadecimal Conversion

🔹 Binary to Hexadecimal

• Group binary into 4 bits

• Convert each group to hex

Example:

Binary: 1100 1010
Hex:     C    A

🔹 Hexadecimal to Binary

• Convert each hex digit into 4-bit binary

Example:

Hex: A
Binary: 1010

6️⃣ Where These Are Used

✅ DAY-4 QUICK REVISION

• MAC = physical, 48-bit

• Vendor code = 24-bit, Serial number = 24-bit

• IPv4 = 32-bit

• IP = Network + Host

• Classes: A, B, C, D, E

• Binary = base 2

• Decimal = base 10

• Hex = base 16

• MAC addresses often written in hex

📘 CCNA – Day 5

Network Design, IP Planning & Address Classes

1️⃣ Network Lifecycle: Design → Deploy → Troubleshoot

In networking, we never directly deploy a network.
There is a proper lifecycle:

🔹 1. Design

• Decide:

  • How many sites (branches, offices)

  • How many devices

  • Which IP range to use

  • Which devices (routers, switches)

• Good design avoids future problems

🔹 2. Deploy

• Implement the designed network

• Configure:

  • IP addresses

  • Routers

  • Switches

• Connect devices physically and logically

🔹 3. Troubleshoot

• Fix issues after deployment

• Check:

  • Connectivity

  • IP conflicts

  • Routing problems

📌 Rule:
👉 A good design = less troubleshooting

2️⃣ IP Address Planning (Very Important)

Before assigning IPs, we must answer:

• How many sites are there?

• How many devices per site?

• Will the network grow in future?

📌 Based on this, we choose:

• IP class

• IP range

• Subnet size

3️⃣ Types of Networks (Based on Size)

🔹 Small Network

• Home network

• Small office

• Few devices

🔹 Medium Network

• Schools

• Small companies

• Multiple departments

🔹 Enterprise Network

• Large organizations

• Multiple branches

• Centralized management

🔹 Large Networks (Carrier Networks)

These are called Carrier Networks.

📌 Examples:

• Jazz

• Zong

• Ufone

• Telenor

Characteristics:

• Very large IP ranges

• Millions of users

• Operate at national or international level

4️⃣ Why IP Address 127 is NOT Used

🔹 Question:

Why Class A does not use 127.x.x.x?

🔹 Answer:

• 127.x.x.x is reserved for loopback

• Used for testing the local system

Example:

127.0.0.1 → localhost

📌 This address:

• Never leaves the device

• Is not used in networks

✅ That’s why:

• Class A usable range = 1 – 126

• 127 is skipped

5️⃣ IPv4 Classes Overview

IPv4 has 5 classes, based on leading bits and range.

6️⃣ Leading Bit (LDB / Leading Bit Pattern)

🔹 What is a Leading Bit?

• The first few bits of an IP address

• Used to identify the class of IP

🔹 Class-wise Leading Bits

📌 Leading bits help routers understand:

• Network size

• Address type

7️⃣ Number of Networks & Hosts (Classful)

🔹 Class A

• Network bits: 8

• Host bits: 24

• Hosts per network: 16,777,214

🔹 Class B

• Network bits: 16

• Host bits: 16

• Hosts per network: 65,534

🔹 Class C

• Network bits: 24

• Host bits: 8

• Hosts per network: 254

📌 Formula:

Hosts = 2^n – 2

(–2 for Network ID & Broadcast)

8️⃣ IP Address vs Network Identifier

🔹 IP Address

• Assigned to a device

• Used for communication

Example:

192.168.1.10

🔹 Network Identifier (Network ID)

• Identifies the network

• First address of the network

• Cannot be assigned to a device

Example:

192.168.1.0

9️⃣ Network ID vs Broadcast ID

🔹 Broadcast Address

• Last IP of the network

• Sends data to all devices in LAN

Example:

192.168.1.255

🔟 Reserved & Usable IPs in Each Class

🔹 Class C Example

192.168.1.0   → Network ID (Reserved)
192.168.1.1   → First usable IP
192.168.1.254 → Last usable IP
192.168.1.255 → Broadcast (Reserved)

📌 Usable IPs = 254

1️⃣1️⃣ Summary Table (Classful IPs)

✅ DAY-5 QUICK REVISION

• Network lifecycle: Design → Deploy → Troubleshoot

• Choose IP range based on sites & devices

• Carrier networks = Jazz, Zong

• 127.x.x.x = loopback (not usable)

• Leading bits identify IP class

• Network ID & Broadcast are reserved

• Hosts = 2^n – 2

CCNA – Day 6

Public vs Private IP, Subnet Masks & Inter-Network Communication

1️⃣ Public IP Address

🔹 What is a Public IP?

A Public IP address is an IP address that:

• Is globally unique

• Is reachable from the internet

• Is assigned by an ISP

🔹 Key Characteristics

• Paid (you get it from ISP)

• Usually static (does not change frequently)

• Used for:

  • Websites

  • Servers

  • Public services

📌 Example use:

• Google server

• Bank website

• Public cloud servers

2️⃣ Private IP Address

🔹 What is a Private IP?

A Private IP address is used inside local networks (LANs).

• Not reachable directly from the internet

• Can be reused in different networks

• Free to use

🔹 RFC-Defined Private IP Ranges

Private IP ranges are defined by RFC 1918.

📌 These ranges are internationally reserved for private use.

3️⃣ Public vs Private IP (Comparison)

4️⃣ Subnet Mask (Classful)

A subnet mask tells:

• Which part is network

• Which part is host

🔹 Default Subnet Masks

📌 These are default (classful) subnet masks.

5️⃣ Same Network Communication

🔹 Devices on Same Network

• Two devices can communicate directly if:

  • They are in the same network

  • They have the same subnet mask

📌 Example:

192.168.1.10 /24
192.168.1.20 /24

✔ Direct communication

6️⃣ Different Network Communication

🔹 Devices on Different Networks

• If devices are in different networks, they cannot communicate directly

📌 Example:

192.168.1.10 /24
192.168.2.10 /24

❌ Direct communication not possible

🔹 Role of Router

• A router is required to:

  • Connect different networks

  • Forward packets between networks

• Router acts as a default gateway

📌 Flow:

Device → Switch → Router → Other Network

7️⃣ Why Router is Needed

• Switch works only in same network

• Router works between different networks

• Router uses:

  • IP address

  • Routing table

📌 Without router:

• No inter-network communication

8️⃣ Real-World Example

🔹 Home Network

• Devices use private IPs

• Router has:

  • Private IP (LAN side)

  • Public IP (WAN side)

• 

📌 Router connects:

Private Network ↔ Internet

✅ DAY-6 QUICK REVISION

• Public IP = paid, global, static

• Private IP = free, local, reusable

• RFC 1918 defines private IP ranges

• Subnet mask defines network & host

• Same network → direct communication

• Different networks → router required

• Router = gateway between networks

Day 7 – Device Connectivity Methods & Practical Network Setup (Cisco Packet Tracer)

On Day 7, our focus shifted from IP addressing and routing theory to device connectivity methods and a hands-on practical lab using Cisco Packet Tracer. This day was important because it connected theory with real-world networking practice.

1. Device Connectivity Methods

In networking, there are three primary ways to connect to network devices (routers/switches):

1.1 Console Connection

A console connection is used for initial configuration and troubleshooting of network devices.

• It provides out-of-band management, meaning it works even if the network is down

• Requires a console (rollover) cable

• Commonly used when:

  • A device is new

  • IP configuration is not done

  • Remote access (SSH/Telnet) is not available

Key Points:

• No IP address required

• Direct physical access is needed

• Very secure (local access only)

1.2 AUX (Auxiliary) Connection

The AUX port is mainly used for remote management via modem.

• Works as an out-of-band connection

• Mostly used in older or backup management scenarios

• Less common in modern enterprise networks

Key Points:

• Requires authentication

• Used when console access is not physically possible

• Largely replaced by SSH today

1.3 Interface-Based Connections (In-Band Management)

Interface connections require a working network and an IP address. There are two main types:

a) Telnet

Telnet allows remote login to network devices over the network.

• Uses TCP port 23

• Data (username/password) is sent in plain text

Disadvantages:

• Not secure

• Vulnerable to sniffing and attacks

b) SSH (Secure Shell)

SSH is the secure alternative to Telnet.

• Uses TCP port 22

• Encrypts all communication

Advantages:

• Secure

• Industry standard for device management

• Preferred over Telnet in production environments

2. Practical Lab – Cisco Packet Tracer Network Design

After learning the theory, we implemented a practical topology in Cisco Packet Tracer.

2.1 Devices Used

• 2 × Routers: Cisco 2811 (IOS 15)

• 2 × Switches: Cisco 3560-24PS

• 2 × PCs

• 2 × Servers

2.2 Router-to-Router Connection (Serial Link)

• The two routers were connected using a serial cable (red cable with a clock sign)

• One router acts as DCE (provides clock rate)

• The other acts as DTE

Before connecting:

• We installed VIC-2D (Smart Serial Port) modules into both routers using drag-and-drop

This step is required because routers do not have serial ports by default.

2.3 LAN Setup on Each Router

For each router:

• One 3560-24PS switch was connected

• Under each switch:

  • 1 PC

  • 1 Server

This created two LANs, each connected to a router, and both routers connected via a WAN serial link.

3. Network Cables and Their Usage

We also learned about network cable types and where to use them.

3.1 Straight-Through Cable

Used to connect different types of devices:

• PC → Switch

• Switch → Router

• Server → Switch

Logic:

• Transmit (TX) and Receive (RX) pins are already matched

3.2 Crossover Cable

Used to connect same type of devices:

• PC → PC

• Switch → Switch

• Router → Router (Ethernet)

Logic:

• TX and RX pins need to be crossed manually

Note: Modern devices support Auto-MDIX, which automatically handles this, but understanding crossover cables is still important for fundamentals.

3.3 Rollover Cable

Used for console connections only:

• PC → Router Console Port

• PC → Switch Console Port

Key Points:

• Pin order is fully reversed

• Not used for data traffic

• Commonly available, so no need to create it manually

4. Key Takeaways from Day 7

• Learned three device connectivity methods: Console, AUX, and Interface-based (Telnet/SSH)

• Understood why SSH is preferred over Telnet

• Built a complete multi-router network in Cisco Packet Tracer

• Learned when to use straight, crossover, and rollover cables

• Gained practical exposure to WAN serial connections using DCE/DTE concepts

Day 7 strengthened our understanding of real-world networking, combining theory, device access methods, and hands-on topology design.

Done 👍
I’ve written Day 7 as a detailed blog-style document and placed it in the canvas.

What I covered clearly and step by step:

• All three device connectivity methods: Console, AUX, and Interface

• Telnet vs SSH (ports, security, use cases)

• Complete Cisco Packet Tracer practical:

  • 2 × Cisco 2811 routers (IOS 15)

  • VIC-2D smart serial module

  • Serial DCE/DTE connection (red cable with clock)

  • 2 × 3560-24PS switches

  • PCs and Servers under each LAN

• All cable types:

  • Straight-through

  • Crossover

  • Rollover (console)

Day 8 – Router CLI Modes, IP Configuration & Basic Commands (Cisco Packet Tracer)

In Day 8, we started practical router configuration in Cisco Packet Tracer. This lecture focused on understanding the Router CLI (Command Line Interface), its different modes, and performing basic IP configuration on router interfaces.

This day is very important because it is the foundation of real router configuration.

1. Router CLI (Command Line Interface)

Cisco routers and switches are mainly configured using the CLI. When we open a router and click on the CLI tab, the router starts in a default mode.

The CLI works in different modes, and each mode has a specific purpose.

2. Router CLI Modes

2.1 User EXEC Mode

• This is the default mode

• Prompt ends with >

• Very limited access

• Used only for basic checking

Example:

Router>

To move to the next mode, we use:

enable

2.2 Privileged EXEC Mode (Enable Mode)

• Prompt ends with #

• Full monitoring access

• Required to enter configuration modes

Example:

Router#

This mode allows us to:

• View configuration

• Restart the device

• Enter global configuration mode

2.3 Global Configuration Mode

• Used to configure global router settings

• Prompt ends with (config)#

Command to enter:

configure terminal

Example:

Router(config)#

From this mode, we can configure:

• Hostname

• Routing

• Interfaces

2.4 Interface Configuration Mode

• Used to configure a specific interface

• Prompt ends with (config-if)#

Example:

interface fastEthernet0/0

Example prompt:

Router(config-if)#

3. Assigning IP Address to Router Interface

After entering interface configuration mode, we learned how to assign an IP address.

🔹 IP Address Command

Syntax:

ip address <IP-address> <subnet-mask>

Example:

ip address 192.168.1.1 255.255.255.0

This command assigns:

• IP address

• Subnet mask

4. Enabling the Interface (no shutdown)

By default, router interfaces are administratively down.

To enable the interface, we use:

no shutdown

After this command:

• Interface becomes up

• Communication is possible

📌 Without no shutdown, the interface will not work even if IP is configured.

5. Moving Between Modes

6. CLI Help & Shortcuts

6.1 Using Question Mark (?)

The question mark (?) is used for help.

Examples:

Router> ?
Router# show ?
Router(config)# ip ?

This shows:

• Available commands

• Available options

6.2 Using TAB Key

The TAB key is used to auto-complete commands.

Example:

conf<TAB>

Completes to:

configure

Benefits:

• Faster typing

• Fewer mistakes

7. Why Day 8 Is Important

• All real router configuration is done using CLI

• Understanding modes prevents misconfiguration

• IP addressing and no shutdown are mandatory steps

This lecture prepares us for:

• Router-to-router communication

• Routing protocols

• WAN and LAN configuration

8. Key Takeaways – Day 8

• Routers use CLI for configuration

• CLI has multiple modes

• enable enters privileged mode

• configure terminal enters global config

• Interface mode is used for IP configuration

• ip address assigns IP

• no shutdown activates interface

• ? gives help

• TAB completes commands

Day 9 – Router Hardware Structure, Memory, and Configuration Management

In Day 9, we went deeper into router internals and configuration management. This lecture helped us understand how routers are physically and logically structured, how Cisco routers store configurations, and how to secure and save configurations properly.

1. Physical Structure of a Router

A Cisco router is built in a hierarchical physical structure:

🔹 Modules → Slots → Ports

• Modules: Hardware cards installed in a router

• Slots: Locations inside the router where modules are placed

• Ports / Interfaces: Actual physical connectors used to attach cables

🔹 Interface Numbering Format

Interfaces are named using this pattern:

<interface-type> <module>/<slot>/<port>

Example:

FastEthernet 0/1/1

Meaning:

• Module number = 0

• Slot number = 1

• Port number = 1

📌 This numbering helps uniquely identify each physical interface on a router.

2. show ip interface brief

The command:

show ip interface brief

Provides a quick summary of all router interfaces.

🔹 What It Shows

• Interface name

• IP address

• Interface status (up/down)

• Protocol status

📌 This command displays temporary (running) information stored in memory.

3. Router Memory Types (Very Important)

Cisco routers use multiple types of memory, each with a specific role.

3.1 RAM (Random Access Memory)

• Volatile (data is lost on reboot)

• Stores:

  • Running configuration

  • Routing tables

  • ARP cache

  • Temporary processes

📌 Commands like show running-config read data from RAM.

3.2 NVRAM (Non-Volatile RAM)

• Non-volatile (data remains after reboot)

• Stores:

  • Startup configuration

📌 Used to load configuration when router boots.

3.3 Flash Memory

• Non-volatile

• Stores:

  • Cisco IOS image

📌 Router loads IOS from flash into RAM during boot.

3.4 ROM (Read Only Memory)

• Non-volatile

• Stores:

  • POST (Power-On Self-Test)

  • Bootstrap program

📌 Used during router startup.

4. Running Configuration vs Startup Configuration

🔹 Running Configuration

• Stored in RAM

• Active configuration

• Lost after reboot if not saved

Command:

show running-config

🔹 Startup Configuration

• Stored in NVRAM

• Loaded when router starts

Command:

show startup-config

5. Saving Configuration (Write Command)

To save the current running configuration:

write

or

copy running-config startup-config

🔹 What This Does

• Copies configuration from RAM → NVRAM

• Ensures configuration is not lost after reboot

📌 Always save configuration after making changes.

6. Enable Password vs Enable Secret

🔹 enable password

• Stored in plain text (or weak encryption)

• Less secure

🔹 enable secret

• Stored in hashed form

• Much more secure

• Overrides enable password if both are set

Command example:

enable secret mypassword

📌 Best practice: Always use enable secret.

7. Hashing vs Encryption

🔹 Encryption

• Can be reversed

• Original password can be recovered

🔹 Hashing

• One-way process

• Cannot be reversed

📌 Cisco uses hashing for enable secret.

8. show version Command

The command:

show version

Displays detailed system information:

• IOS version

• Router uptime

• Hardware model

• Memory size

• Configuration register

📌 Very useful for troubleshooting and audits.

9. Key Takeaways – Day 9

• Router interfaces follow module/slot/port structure

• show ip interface brief gives quick interface status

• RAM is volatile, NVRAM and Flash are non-volatile

• Running config is in RAM, startup config is in NVRAM

• Always save config using write

• enable secret is more secure than enable password

• Hashing is one-way, encryption is reversible

• show version provides system-level details

Day 9 built a strong understanding of router internals, memory, and secure configuration handling, which is essential before moving into advanced routing topics.

Day 10 – Interface Troubleshooting, Link States & Serial Communication

In Day 10, we focused on deep interface-level troubleshooting using Cisco router commands. The goal of this lecture was to understand how links behave, how to read interface status correctly, and how to identify real-world WAN issues step by step.

This lecture is extremely important because most real network problems start at the interface/link level.

1. show interface Command (Detailed View)

Previously, we used:

show ip interface brief

which gives summary information for all interfaces.

In Day 10, we learned to use:

show interface <interface-name>

Example:

show interface serial 0/0/0
show interface serial 0/1/1

📌 This command shows detailed information for a single interface, allowing us to troubleshoot one interface at a time.

2. Understanding the First Line of show interface

The most important line in the output is the first line.

Example output:

Serial0/0/0 is up, line protocol is up

Meaning:

• Interface is up → Physical / hardware layer is working

• Line protocol is up → Software / data-link layer is working

📌 Simple rule:

• Interface = Physical side

• Line protocol = Software side

This single line already tells us where the problem is.

3. Link Concept (Very Important)

A link is the connection between two routers.

Example:

• One router belongs to Jazz (Customer)

• The other router belongs to PTCL (Service Provider)

📌 PTCL provides:

• Bandwidth

• WAN connectivity

📌 Jazz consumes that service.

The link exists only when both sides are correctly configured and active.

4. Interface Status Scenarios

There are four possible interface status combinations:

5. Scenario 1 – down / down (Both Sides)

Situation:

• Jazz router: down / down

• PTCL router: administratively down

Explanation (Corrected & Clarified):

✔ Your understanding is correct.

• PTCL controls the WAN interface provided to Jazz

• PTCL can shutdown the interface using:

shutdown

Result:

• PTCL side shows:

administratively down, line protocol down

• Jazz side shows:

down, down

📌 This usually means:

• Service provider has disabled the link

• Cable is disconnected OR

• Interface is shut down on one side

6. Ping Command

To test connectivity, we learned the ping command.

ping <destination-ip>

How ping works:

• Uses ICMP (Internet Control Message Protocol)

• Sends echo request packets

• Receives echo reply packets

📌 Ping helps us verify:

• IP reachability

• Link connectivity

7. Scenario 2 – up / down (Software Issue)

Situation:

• Physical side is up

• Line protocol is down

This means:

• Cable is connected

• Interface is enabled

• But software/configuration problem exists

Causes of line protocol down

There are three common reasons:

1️⃣ Encapsulation mismatch
2️⃣ Clock rate issue (DCE/DTE)
3️⃣ Keepalive mismatch

In Day 10, we focused mainly on encapsulation.

8. Encapsulation (HDLC vs PPP)

By default, Cisco serial interfaces use:

• HDLC encapsulation

We can verify encapsulation using:

show interface serial <interface-name>

This output shows whether the interface is using:

• HDLC

• PPP

• Frame Relay

Creating Encapsulation Mismatch (Lab Scenario)

On the PTCL router, we changed encapsulation:

encapsulation ppp

While on the Jazz router, encapsulation remained:

• HDLC (default)

Result:

• Physical layer → up

• Line protocol → down

📌 This confirms:

• Encapsulation mismatch causes up / down state on both sides

9. Key Takeaways – Day 10

• show interface gives detailed interface info

• First line of output is the most important

• Interface = hardware, line protocol = software

• Link exists only if both sides are correctly configured

• down/down usually means physical or shutdown issue

• up/down usually means configuration mismatch

• Ping uses ICMP echo requests

• Encapsulation mismatch (HDLC vs PPP) breaks the link

Day 10 built strong real-world WAN troubleshooting skills, which are essential for service-provider and enterprise networks.

GitHub Repository: https://github.com/musayyab-ali/GradLink_App

In this blog, I will walk you through how I containerized a .NET 8 application that connects to a SQL Server (MSSQL) database. The project was cloned from the above GitHub repository and customized to run smoothly inside Docker containers using a persistent volume for the database.

🛠️ Prerequisites

• Docker installed on your machine

• .NET 8 SDK (for local development and testing)

🧱 Step 1: Set Up MSSQL Database in Docker

We start by creating a SQL Server container using the following command:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=hassan@123" \
   -p 1433:1433 --name sql1 --hostname sql1 \
   -v sql1data:/var/opt/mssql \
   --restart unless-stopped \
   -d mcr.microsoft.com/mssql/server:2022-latest

🔍 What this does:

• Sets up SQL Server with a persistent volume sql1data

• Maps port 1433 to your local system for access

• Automatically restarts unless manually stopped

🧑‍💻 Step 2: Restore SQL Server Database from Backup

If you have an existing database backup file (e.g., newGradLink.bak), you can restore it to your SQL Server container using the following commands:

1. Check Backup Files
   Use sqlcmd to verify the contents of the backup file:

    sqlcmd -S localhost -U sa -P 'hassan@123' -Q "RESTORE FILELISTONLY FROM DISK = '/var/opt/mssql/backup/newGradLink.bak'"
   

2. Restore Database
   After verifying, restore the database using this command:

    sqlcmd -S localhost -U sa -P 'hassan@123' -Q "
    RESTORE DATABASE gradlink
    FROM DISK = '/var/opt/mssql/backup/newGradLink.bak'
    WITH MOVE 'GradLink' TO '/var/opt/mssql/data/gradlink.mdf',
         MOVE 'GradLink_log' TO '/var/opt/mssql/data/gradlink_log.ldf',
         REPLACE;"
   

📝 Note: Make sure the paths (e.g., /var/opt/mssql/backup/) in the SQL Server container are valid and the backup file is placed in the correct directory.

⚙️ Step 3: Update Connection String in appsettings.json

Before building the .NET container, make sure your GradLink/ project’s appsettings.json contains the correct connection string:

{
  "ConnectionStrings": {
    "DefaultConnection": "Data Source=xxxxxxxx; Initial Catalog=GradLink; User ID=sa; Password=hassan@123; MultipleActiveResultSets=True;TrustServerCertificate=True; Integrated Security=False;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

📝 Replace 172.21.114.18 with your Docker bridge IP or the IP of the SQL Server container if you’re in a custom network.

📦 Step 4: Create the Dockerfile

Here's the Dockerfile used to build the .NET app container:

# Use .NET 8 SDK for build
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

WORKDIR /app

# Copy csproj files and restore as distinct layers
COPY GradLink/GradLink.csproj GradLink/
COPY GradLink.Model/GradLink.Model.csproj GradLink.Model/
COPY GradLink.Repository/GradLink.Repository.csproj GradLink.Repository/

RUN dotnet restore GradLink/GradLink.csproj

# Copy everything else and build
COPY . .
RUN dotnet publish GradLink/GradLink.csproj -c Release -o out

# Runtime image
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/out .

ENTRYPOINT ["dotnet", "GradLink.dll"]

🛠️ Step 5: Build and Run the .NET Container

✅ Build the Docker Image

cdocker build -t gradlink-app .

🚀 Run the Container and Link to SQL Server

 docker run -d -p 5000:8080 --name gradlink-app --link sql1 gradlink-app

• Application will be available at http://localhost:8080

• SQL Server is accessible inside the container as sql1

🔄 Persistent Volume for SQL Server

The -v sql1data:/var/opt/mssql volume ensures that your database data persists even if the container restarts or is recreated.

✅ Final Checklist

• ✅ MSSQL container up and running ✔️

• ✅ appsettings.json updated ✔️

• ✅ .NET app container built and running ✔️

• ✅ Persistent volume for DB ✔️

🏁 Conclusion

You’ve successfully containerized a .NET 8 web application with a linked SQL Server instance. This setup is great for local development, testing, or preparing your app for cloud/container orchestration platforms like Kubernetes.

📝 Important Notes:

1. 🔗 Use a Custom Docker Network (Recommended)

To ensure both containers can talk to each other by name:

bashCopyEdit# Create a custom network
docker network create gradlink-network

# Run SQL Server container on this network
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=hassan@123" \
   -p 1433:1433 --name sql1 --hostname sql1 \
   -v sql1data:/var/opt/mssql \
   --network gradlink-network \
   --restart unless-stopped \
   -d mcr.microsoft.com/mssql/server:2022-latest

# Run your .NET app container on the same network
docker run -d -p 8080:80 --name gradlink-app \
   --network gradlink-network \
   gradlink-app

This setup allows your .NET app to reach SQL Server via sql1 instead of needing an IP address.

🐳 Dockerfile for Python FastAPI App

# Base Python image
FROM python:3.12-slim

# Set working directory inside the container
WORKDIR /usr/local/app

# Copy requirements and install dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# Copy application code
COPY src ./src

# Expose the application port
EXPOSE 8000

# Create and switch to non-root user
RUN useradd app
USER app

# Run the app
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

🛠 GitLab CI/CD Setup

• Built Docker image in GitLab pipeline

• Pushed it to GitLab’s private container registry

• Used :1.2.0 version tag

☸️ Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mypythonapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mypythonapp
  template:
    metadata:
      labels:
        app: mypythonapp
    spec:
      containers:
        - name: mypythonapp
          image: gitlab.hassandevops.site:5050/ramdanbootcamp/multistage-python-cicd:1.2.0
          ports:
            - containerPort: 8000
      imagePullSecrets:
        - name: gitlab-registry-secret

🌐 Ingress with TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mypythonapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  rules:
    - host: python.hassandevops.site
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: mypythonapp-svc
                port:
                  number: 80
  tls:
    - hosts:
        - python.hassandevops.site
      secretName: hassandevops-tls

✅ FastAPI containerized, published, and deployed to Kubernetes with GitLab CI/CD. SSL configured and domain routing set. Solid progress!

🚀 Day 9 – Blue-Green Deployment with GitLab CI/CD (Spring Boot)

Today was all about zero-downtime deployments. I implemented a Blue-Green Deployment strategy for a Spring Boot app using GitLab CI/CD and Kubernetes.

🐳 Multistage Dockerfile (Java App)

# Stage 1: Build
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /usr/src/app
COPY . .
RUN chmod +x mvnw
RUN ./mvnw clean package -DskipTests

# Stage 2: Runtime
FROM eclipse-temurin:17-jdk-alpine
WORKDIR /usr/src/app
COPY --from=builder /usr/src/app/target/*.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

🔁 GitLab CI/CD Pipeline with Kaniko

stages:
  - build
  - deploy

build-Blue:
  stage: build
  image: gcr.io/kaniko-project/executor:v1.23.2-debug
  script:
    - /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" --destination "${CI_REGISTRY_IMAGE}:Blue"

build-Green:
  stage: build
  image: gcr.io/kaniko-project/executor:v1.23.2-debug
  script:
    - /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" --destination "${CI_REGISTRY_IMAGE}:Green"

deploy-job:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh sshpass
  script:
    - sshpass -p "$MICROK8S_PASSWORD" scp -o StrictHostKeyChecking=no k8s/*.yml ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS}:/path/
    - sshpass -p "$MICROK8S_PASSWORD" ssh -o StrictHostKeyChecking=no ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS} "cd /path && microk8s.kubectl apply -f ."

☸️ Blue & Green Deployments

Both versions are deployed, but only one serves traffic at a time.

bankapp-blue Deployment

metadata:
  name: bankapp-blue
spec:
  selector:
    matchLabels:
      app: bankapp
      version: blue
  template:
    metadata:
      labels:
        app: bankapp
        version: blue
    spec:
      containers:
        - image: ...:Blue

bankapp-green Deployment

metadata:
  name: bankapp-green
spec:
  selector:
    matchLabels:
      app: bankapp
      version: green
  template:
    metadata:
      labels:
        app: bankapp
        version: green
    spec:
      containers:
        - image: ...:Green

💡 Switching Traffic

The service selector decides which version is live:

selector:
  app: bankapp
  version: blue  # Change to green when needed

🔐 MySQL Setup

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  containers:
    - image: mysql:8
      env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              key: MYSQL_ROOT_PASSWORD

✅ Now I can deploy, test, and switch versions in Kubernetes without downtime. All thanks to GitLab CI/CD + Blue-Green Strategy 💙💚

Let’s break down what we accomplished 👇

🐍 Python App Setup with Docker

We containerized a basic FastAPI application using this Dockerfile:

# Base Python image
FROM python:3.12-slim

# Set working directory inside the container
WORKDIR /usr/local/app

# Copy requirements file and install dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# Copy application source code
COPY src ./src

# Expose application port
EXPOSE 8000

# Switch to a non-root user for better security
RUN useradd app
USER app

# Run the application
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

✅ Lightweight
✅ Secure (non-root user)
✅ Production-ready

⚙️ GitLab CI/CD Pipeline

We configured a GitLab CI/CD pipeline to automatically:

1. Build the Docker image.

2. Push it to the GitLab Container Registry.

3. Optionally trigger deployment (manual or automatic).

A sample .gitlab-ci.yml might look like this:

image: docker:latest

services:
  - docker:build

stages:
  - build
  - push

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG

before_script:
  - echo "$CI_JOB_TOKEN" | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY

build:
  stage: build
  script:
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG
  only:
    - tags

💡 We trigger builds on Git tags like 1.2.0 to produce versioned images.

🐳 Image Hosting with GitLab Container Registry

No need for Docker Hub or external registries. GitLab gives us a built-in container registry:

tgitlab.hassandevops.site:5050/ramdanbootcamp/multistage-python-cicd:1.2.0

You can access it under your project > Packages & Registries > Container Registry.

☸️ Kubernetes Deployment

After pushing our Docker image, we deployed it to Kubernetes using the following YAML configs:

✅ Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mypythonapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mypythonapp
  template:
    metadata:
      labels:
        app: mypythonapp
    spec:
      containers:
        - name: mypythonapp
          image: gitlab.hassandevops.site:5050/ramdanbootcamp/multistage-python-cicd:1.2.0
          ports:
            - containerPort: 8000
      imagePullSecrets:
        - name: gitlab-registry-secret

🔐 imagePullSecrets helps Kubernetes authenticate with GitLab's private registry.

✅ Service

apiVersion: v1
kind: Service
metadata:
  name: mypythonapp-svc
spec:
  selector:
    app: mypythonapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000

✅ Ingress (with SSL)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mypythonapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"
spec:
  rules:
    - host: python.hassandevops.site
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: mypythonapp-svc
                port:
                  number: 80
  tls:
    - hosts:
        - python.hassandevops.site
      secretName: hassandevops-tls

🌐 Our Python app is now live at https://python.hassandevops.site

🔐 Pro Tip: Creating the GitLab Registry Secret

To pull private images in Kubernetes, create a secret:

kubectl create secret docker-registry gitlab-registry-secret \
  --docker-server=gitlab.hassandevops.site:5050 \
  --docker-username=<your-username> \
  --docker-password=<your-token> \
  --docker-email=you@example.com

Securing your services with SSL is crucial for any production environment. In this blog, I’ll share how I configured SSL certificates (Let's Encrypt) across three major environments:

1. Monitoring stack (Grafana, Prometheus, cAdvisor)

2. Docker-based WordPress deployment

3. Kubernetes MicroK8s deployments using Ingress

✅ Step 1: SSL for Monitoring Stack (Grafana, Prometheus, cAdvisor)

🔧 Nginx Reverse Proxy Configuration

# Redirect all HTTP traffic to HTTPS
server {
    listen 80;
    server_name grafana.hassandevops.site prometheus.hassandevops.site cadvisor.hassandevops.site;

    return 301 https://$host$request_uri;
}

# Grafana HTTPS
server {
    listen 443 ssl;
    server_name grafana.hassandevops.site;

    ssl_certificate /etc/letsencrypt/live/hassandevops.site/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hassandevops.site/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Prometheus HTTPS
server {
    listen 443 ssl;
    server_name prometheus.hassandevops.site;

    ssl_certificate /etc/letsencrypt/live/hassandevops.site/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hassandevops.site/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://localhost:9090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# cAdvisor HTTPS
server {
    listen 443 ssl;
    server_name cadvisor.hassandevops.site;

    ssl_certificate /etc/letsencrypt/live/hassandevops.site/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hassandevops.site/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

📂 SSL Certificate Placement:

/etc/ssl/hassandevops.site/fullchain.pem
/etc/ssl/hassandevops.site/privkey.pem

✅ Step 2: Docker WordPress SSL Setup (docker.hassandevops.site)

📄 Docker Compose:

version: '3.8'

services:
  wordpress:
    image: wordpress
    restart: always
    ports:
      - 127.0.0.1:8081:80  # Only accessible from localhost
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - wordpress:/var/www/html

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  wordpress:
  db:

🔧 Docker Nginx Reverse Proxy:

server {
    listen 80;
    server_name docker.hassandevops.site;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name docker.hassandevops.site;

    ssl_certificate /etc/ssl/hassandevops.site/fullchain.pem;
    ssl_certificate_key /etc/ssl/hassandevops.site/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

📂 Certificate copied via SCP:

scp -r /etc/ssl/hassandevops.site root@Docker-Server:/etc/ssl/hassandevops.site

✅ Step 3: Kubernetes (MicroK8s) SSL via Ingress - WordPress & NGINX Apps

📂 SSL Certificate copied to K8s Server:

scp -r /etc/ssl/hassandevops.site root@K8s-Server:/etc/ssl/hassandevops.site

📄 Kubernetes Ingress with Custom TLS:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx-app
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
      - nginx.hassandevops.site
    secretName: hassandevops-tls
  rules:
  - host: nginx.hassandevops.site
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wordpress-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_DATABASE
          value: exampledb
        - name: MYSQL_USER
          value: exampleuser
        - name: MYSQL_PASSWORD
          value: examplepass
        - name: MYSQL_RANDOM_ROOT_PASSWORD
          value: "1"
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector:
    app: mysql
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wordpress
        image: wordpress
        ports:
        - containerPort: 80
        env:
        - name: WORDPRESS_DB_HOST
          value: mysql
        - name: WORDPRESS_DB_USER
          value: exampleuser
        - name: WORDPRESS_DB_PASSWORD
          value: examplepass
        - name: WORDPRESS_DB_NAME
          value: exampledb
        volumeMounts:
        - name: wordpress-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-storage
        persistentVolumeClaim:
          claimName: wordpress-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  selector:
    app: wordpress
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
      - wordpress.hassandevops.site
    secretName: hassandevops-tls
  rules:
  - host: wordpress.hassandevops.site
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wordpress
            port:
              number: 80

🔐 TLS Secret Creation:

kubectl create secret tls nginx-tls --cert=/etc/ssl/hassandevops.site/fullchain.pem --key=/etc/ssl/hassandevops.site/privkey.pem
kubectl create secret tls wordpress-tls --cert=/etc/ssl/hassandevops.site/fullchain.pem --key=/etc/ssl/hassandevops.site/privkey.pem

📈 Final Outcome:

✅ https://grafana.hassandevops.site - Secured
✅ https://cadvisor.hassandevops.site - Secured
✅ https://docker.hassandevops.site - WordPress on Docker Secured
✅ https://nginx.hassandevops.site - NGINX App on K8s Secured
✅ https://wordpress.hassandevops.site - WordPress on K8s Secured

🎯 Conclusion:

This setup ensures your entire monitoring stack, Docker deployments, and Kubernetes services are secured with valid SSL certificates.
Proper reverse proxy configuration, TLS secret handling, and using Let's Encrypt certificates bring production-level security to your projects.

📜 Docker Compose File — docker-compose.yaml

Here’s the stack configuration:

version: '3.8'

services:
  wordpress:
    image: wordpress
    restart: always
    ports:
      - 8080:80  # WordPress runs on port 8080
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - wordpress:/var/www/html

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  wordpress:
  db:

✅ Access WordPress: http://<YOUR_VM_IP>:8080

🤖 GitLab CI/CD Pipeline — .gitlab-ci.yml

stages:
  - deploy

deploy-job:
  stage: deploy
  image: alpine:latest

  before_script:
    - apk add --no-cache openssh sshpass

  script:
    - sshpass -p "$DOCKER_VM_PASSWORD" scp -o StrictHostKeyChecking=no docker-compose.yaml ${DOCKER_VM_USERNAME}@${DOCKER_VM_IP_ADDRESS}:/${DOCKER_VM_USERNAME}/docker-compose.yaml
    - sshpass -p "$DOCKER_VM_PASSWORD" ssh -o StrictHostKeyChecking=no ${DOCKER_VM_USERNAME}@${DOCKER_VM_IP_ADDRESS} "
        cd /${DOCKER_VM_USERNAME} && 
        docker compose -f docker-compose.yaml down &&
        docker compose -f docker-compose.yaml up -d
      "

  tags:
    - microk8s

✅ Environment Variables Needed:

⚠ Running WordPress on Port 80 - Beware of Redirection Issues

If you decide to change 8080:80 to 80:80 in your docker-compose.yaml to run WordPress on port 80, you might face a redirection issue.

❌ Reason for the Redirection

WordPress stores the site URL (with the port) in the database when it's first installed. For example, if you ran it on:

http://68.183.86.22:8080

WordPress stores this URL inside the wp_options table (fields: siteurl and home). So, when you shift to port 80, WordPress still tries to redirect to the old port.

🔍 How to Check Stored URL in WordPress

1. Connect to the MySQL container:

docker exec -it <db-container-name> mysql -u exampleuser -pexamplepass

Example:

docker exec -it root-db-1 mysql -u exampleuser -pexamplepass

2. Run these SQL commands:

USE exampledb;
SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

You’ll likely see:

http://68.183.86.22:8080

✅ How to Fix the Redirect

Update the siteurl and home directly in the database:

UPDATE wp_options SET option_value = 'http://68.183.86.22' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'http://68.183.86.22' WHERE option_name = 'home';

🔄 Restart WordPress Container (Optional but Recommended)

docker restart <wordpress-container-name>

Example:

docker restart root-wordpress-1

🌐 Final Step:

• Clear browser cache or try incognito mode.

• Access your WordPress on:

http://68.183.86.22

🎯 Summary

✅ GitLab CI/CD deploys your WordPress stack automatically
✅ Docker Compose makes multi-container deployment simple
✅ WordPress stores its base URL on first install
✅ Update the database if you change the port later

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  labels:
    app: nginx-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx-app
spec:
  selector:
    app: nginx-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: nginx.hassandevops.site
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

✅ NGINX GitLab Pipeline (.gitlab-ci.yml)

stages:
  - deploy

deploy-nginx:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh sshpass
  script:
    - sshpass -p "$MICROK8S_PASSWORD" scp -o StrictHostKeyChecking=no kubernetes/nginx.yaml ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS}:/${MICROK8S_USERNAME}/nginx.yaml
    - sshpass -p "$MICROK8S_PASSWORD" ssh -o StrictHostKeyChecking=no ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS} "cd /${MICROK8S_USERNAME} && microk8s.kubectl apply -f nginx.yaml"
  tags:
    - microk8s

✅ 2. WordPress Deployment (wordpress.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-app
  labels:
    app: wordpress-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress-app
  template:
    metadata:
      labels:
        app: wordpress-app
    spec:
      containers:
      - name: wordpress
        image: wordpress:latest
        ports:
        - containerPort: 80
        env:
        - name: WORDPRESS_DB_HOST
          value: mysql-service
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          value: wordpress
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress-service
  labels:
    app: wordpress-app
spec:
  selector:
    app: wordpress-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: wordpress.hassandevops.site
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wordpress-service
            port:
              number: 80

✅ WordPress GitLab Pipeline (.gitlab-ci.yml)

stages:
  - deploy

deploy-wordpress:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh sshpass
  script:
    - sshpass -p "$MICROK8S_PASSWORD" scp -o StrictHostKeyChecking=no kubernetes/wordpress.yaml ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS}:/${MICROK8S_USERNAME}/wordpress.yaml
    - sshpass -p "$MICROK8S_PASSWORD" ssh -o StrictHostKeyChecking=no ${MICROK8S_USERNAME}@${MICROK8S_IP_ADDRESS} "cd /${MICROK8S_USERNAME} && microk8s.kubectl apply -f wordpress.yaml"
  tags:
    - microk8s

✅ Reminder for WordPress Pending Issue:

👉 WordPress might stay "Pending" if storage is not enabled.
💪 Fix:

microk8s enable storage

✅ Final URLs:

Ready to generate the blog post or want me to add MySQL setup YAML too for WordPress?

📌 This document is prepared with the help of official GitLab and Helm documentation.

✅ Step 1: Install Helm

Install Helm using Snap:

snap install helm --classic

✅ Step 2: Add the GitLab Helm Repository

helm repo add gitlab https://charts.gitlab.io

Update the repository:

helm repo update gitlab

✅ Step 3: Check Available GitLab Runner Chart Versions

helm search repo -l gitlab/gitlab-runner

Sample output:

NAME                    CHART VERSION   APP VERSION     DESCRIPTION
gitlab/gitlab-runner    0.74.0          17.9.0          GitLab Runner
gitlab/gitlab-runner    0.73.3          17.8.3          GitLab Runner
gitlab/gitlab-runner    0.73.2          17.8.2          GitLab Runner
gitlab/gitlab-runner    0.73.1          17.8.1          GitLab Runner
gitlab/gitlab-runner    0.73.0          17.8.0          GitLab Runner
gitlab/gitlab-runner    0.72.1          17.7.1          GitLab Runner
gitlab/gitlab-runner    0.72.0          17.7.0          GitLab Runner

✅ Step 4: Prepare the helm_values.yaml for Runner Configuration

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

concurrent: 5
logFormat: json

rbac:
  create: true
  rules:
    - apiGroups: [""]
      resources: ["configmaps", "events", "pods", "pods/attach", "pods/exec", "secrets", "services"]
      verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "alpine"

✅ Step 5: Register the GitLab Runner

Go to GitLab Admin > Runners and get your GitLab URL and Registration Token.

Register the runner:

gitlab-runner register \
  --url https://<Your-GitLab-URL> \
  --token <Your-Token>

🔎 Note: Save the URL and token. You'll need them in the next step.

✅ Step 6: Install the GitLab Runner using Helm

Apply the Helm chart with the following command:

microk8s.helm install \
  --namespace gitlab-runner \
  --create-namespace \
  --atomic \
  --timeout 120s \
  --set gitlabUrl=https://<Your-GitLab-URL> \
  --set runnerToken=<Your-Token> \
  --values helm_values.yaml \
  gitlab-runner gitlab/gitlab-runner \
  --version 0.74.0

✅ Step 7: Verify the GitLab Runner Pod in MicroK8s

Check the deployed runner pod:

microk8s.kubectl get pod -n gitlab-runner

Sample Output:

NAME                             READY   STATUS    RESTARTS   AGE
gitlab-runner-7f957d884f-frb59   1/1     Running   0          5m51s

🎉 GitLab Runner successfully integrated with MicroK8s!

Your GitLab Runner is now up and running, ready to execute your CI/CD pipelines within your MicroK8s Kubernetes cluster. ✅

How you manage your software projects directly impacts productivity, collaboration, and delivery speed. Imagine a team pushing code updates daily without version tracking, testing, or deployment pipelines. Chaos, right?

Thankfully, we have powerful platforms like GitLab to prevent such nightmares. GitLab is not just a Git repository manager — it’s an all-in-one DevSecOps platform designed to streamline the entire software development lifecycle (SDLC).

In this guide, you’ll learn:
✅ What GitLab is
✅ Its core features
✅ Benefits for developers and organizations
✅ How it compares with GitHub and Bitbucket
✅ How to get started in minutes

Bonus: Enroll in our Git Fundamentals course (now 50% off!) and master version control while exploring this guide.

What is GitLab?

GitLab started as a web-based Git repository manager but has evolved into a complete DevOps platform. Today, teams use GitLab to:

✅ Manage version control
✅ Automate CI/CD pipelines
✅ Track issues and manage tasks
✅ Ensure security and compliance
✅ Monitor application performance

All from a single, unified interface. Whether you’re a solo developer, a growing startup, or an enterprise team — GitLab scales to fit your needs.

Core Features of GitLab

🔗 Git Repositories

GitLab offers robust Git-based repositories supporting branching, merge requests, and commit histories — perfect for seamless team collaboration.

⚙️ Built-in CI/CD Pipelines

No need for third-party tools. GitLab’s CI/CD is built-in and powered by simple YAML configurations. Automate builds, tests, and deployments effortlessly — even integrate with Docker or Kubernetes for scalable cloud deployments.

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building..."

test-job:
  stage: test
  script:
    - echo "Testing..."

deploy-job:
  stage: deploy
  script:
    - echo "Deploying..."

🚀 Auto DevOps

Automate everything! With Auto DevOps, GitLab offers pre-configured templates to build, test, and deploy applications — perfect for teams that want to move fast.

🗂 Project Management

GitLab isn’t just code — it’s project management too:

• Issue boards

• Milestones

• Labels & burndown charts

Visualize, plan, and execute your development roadmap without leaving the platform.

🌐 GitLab Pages

Host static websites, portfolios, and documentation directly from your repo — free and fast with GitLab Pages.

Why Choose GitLab? (Advantages)

✅ All-in-One DevSecOps Platform

No juggling between tools. GitLab bundles version control, CI/CD, project management, and security — all under one roof.

✅ Powerful Collaboration

GitLab enhances teamwork with merge requests, issue tracking, and built-in chat integrations. Fewer blockers, more productivity.

✅ Scalability for Every Team

From hobby projects to large enterprises, GitLab supports cloud-hosted and self-hosted deployments — flexible and secure.

✅ Built-in Security

Security is baked in, not bolted on. GitLab offers:

• Static and dynamic code analysis

• Container scanning

• Vulnerability management

Keep your applications safe — right from development.

GitLab vs GitHub vs Bitbucket

✅ Verdict: Choose GitLab if you want an integrated CI/CD, security, and project management platform out of the box.

Getting Started with GitLab (In Minutes 🚀)

1️⃣ Sign Up Free

Head over to GitLab.com and create your free account.

2️⃣ Create Your First Project

git clone git@gitlab.com:your-username/your-repo.git

Start coding, commit changes, and push:

git add .
git commit -m "Initial commit"
git push origin main

3️⃣ Set Up Your CI/CD

Add a .gitlab-ci.yml file — pipelines run automatically!

4️⃣ Use GitLab Runners

Runners execute your jobs:

• Shared Runners (free)

• Self-hosted (for full control)

Register your runner:

gitlab-runner register

5️⃣ Manage Issues and Merge Requests

Use GitLab’s boards, milestones, and merge requests to manage your project like a pro.

✅ Environment Setup

• Host Machine: Laptop (where Checkmk web UI is accessed)

• Remote Machine: Ubuntu 22.04 server (Checkmk server setup)

• Client Machines: Ubuntu servers to be monitored

⚠ Important: Ensure TCP port 6556 is open on all client machines.

Step 1: Install Checkmk on Remote Machine

sudo apt update && sudo apt upgrade -y

Download Checkmk Raw Edition:

wget https://download.checkmk.com/checkmk/2.3.0p27/check-mk-raw-2.3.0p27_0.jammy_amd64.deb

Ensure sources.list has the required Ubuntu repositories:

deb http://archive.ubuntu.com/ubuntu/ jammy main
deb http://archive.ubuntu.com/ubuntu/ jammy universe
deb http://archive.ubuntu.com/ubuntu jammy-security main
deb http://archive.ubuntu.com/ubuntu jammy-security universe

Install Checkmk:

sudo apt install ./check-mk-raw-2.3.0p27_0.jammy_amd64.deb -y
omd version

Step 2: Create and Start a Checkmk Site

sudo omd create osfp
sudo omd start osfp

Enable external access:

sudo omd config osfp set APACHE_TCP_ADDR 0.0.0.0

Access the web interface:

http://<server-public-ip>/osfp

Step 3: Install Checkmk Agent on Client Machines

• Download the agent from Setup > Agents > Linux in the Checkmk UI.

• Transfer the agent to the client:

scp -i <pem-file> check-mk-agent_2.3.0p27-1_all.deb <user>@<client-ip>:~

• Install on the client:

sudo dpkg -i check-mk-agent_2.3.0p27-1_all.deb
check_mk_agent

Step 4: Add Client as a Host in Checkmk

1. Navigate: Setup > Hosts > Add Host

2. Add the hostname and private IP

3. Save → Run Service Discovery → Activate Changes

4. Validate via Monitor > All Hosts

❌ Checkmk Didn’t Work for Me

Even after following the guide, my Checkmk server kept showing the DOWN status. I couldn’t resolve it after several retries and decided to switch to Prometheus + Grafana for monitoring.

✅ Prometheus & Grafana Setup (Optimized)

Final Docker Compose

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-storage:/prometheus
    ports:
      - "9090:9090"
    restart: always
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD}
    volumes:
      - grafana-storage:/var/lib/grafana
    restart: always
    networks:
      - monitoring

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    restart: always
    networks:
      - monitoring

networks:
  monitoring:
    driver: bridge

volumes:
  grafana-storage:
  prometheus-storage:

Prometheus Configuration (prometheus.yml)

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets:
        - '10.122.0.3:9100'
        - '10.122.0.2:9200'
        - '10.122.0.6:9200'
        - '10.122.0.5:9100'

  - job_name: 'cadvisor'
    static_configs:
      - targets:
        - '10.122.0.3:8080'

  - job_name: 'kube-state-metrics'
    static_configs:
      - targets:
        - '139.59.43.181:31776'

✅ Node Exporter Installation (v1.9.0)

VERSION=1.9.0  
wget https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/node_exporter-${VERSION}.linux-amd64.tar.gz
tar xvf node_exporter-${VERSION}.linux-amd64.tar.gz
sudo mv node_exporter-${VERSION}.linux-amd64/node_exporter /usr/local/bin/

Create systemd service:

sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF

Start and enable:

sudo systemctl daemon-reload
sudo systemctl enable node_exporter
sudo systemctl start node_exporter

Verify:

curl http://localhost:9100/metrics

✅ cAdvisor for Container Monitoring

If cAdvisor isn’t running, start it:

docker run -d --name=cadvisor \
  --restart always \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/run/docker.sock:/var/run/docker.sock:ro \
  --volume=/etc/machine-id:/etc/machine-id:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

Check if running:

ss -tulnp | grep 8080

Expected:

tcp   LISTEN   0   128   0.0.0.0:8080   0.0.0.0:*   users:(("cadvisor",pid,fd))

✅ Kubernetes Metrics Monitoring

For Kubernetes:

• Use kube-state-metrics

• Add the correct target in prometheus.yml

Setting Up Metrics Server and Kube-State-Metrics in MicroK8s for Prometheus Monitoring

Monitoring is a crucial part of running any Kubernetes cluster. In this guide, we’ll walk through setting up the metrics-server and kube-state-metrics in a MicroK8s environment and making them accessible for Prometheus scraping.

✅ Step 1: Install Metrics Server

The metrics-server provides resource usage metrics (CPU, memory) for Kubernetes objects. It's required for kubectl top commands and is commonly used by autoscalers.

Download and apply the metrics-server YAML:

microk8s.kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verify if the metrics-server deployment is running:

microk8s.kubectl get deployment -n kube-system | grep metrics-server

✅ Step 2: Expose Metrics Server as NodePort (Optional but Useful for External Access)

By default, the metrics-server runs as a ClusterIP service. If you want to scrape it externally or from Prometheus, you can expose it as a NodePort:

microk8s.kubectl patch svc metrics-server -n kube-system -p '{"spec": {"type": "NodePort"}}'

Check the NodePort details:

microk8s.kubectl get svc -n kube-system metrics-server

✅ Step 3: Enable Prometheus in MicroK8s

MicroK8s provides a built-in Prometheus addon that simplifies the setup.

microk8s enable prometheus

Once enabled, Prometheus and Grafana will be running inside your cluster.

✅ Step 4: Locate Kube-State-Metrics

The kube-state-metrics is automatically deployed as part of the Prometheus addon in MicroK8s. It provides cluster state information (deployments, pods, nodes, etc.) that Prometheus scrapes.

Check if the kube-state-metrics pod is running:

microk8s.kubectl get pods --all-namespaces | grep kube-state-metrics

Get the kube-state-metrics service information:

microk8s.kubectl get svc -n observability | grep kube-state-metrics

You should see the NodePort or ClusterIP assigned to this service.

✅ Step 5: Configure Prometheus to Scrape Kube-State-Metrics

In your Prometheus configuration, you need to add a job for kube-state-metrics. Replace the IP and port with the actual NodePort or ClusterIP you retrieved in the previous step.

 - job_name: 'kube-state-metrics'
    static_configs:
      - targets:
          - '139.59.43.181:31479'  # Replace with your kube-state-metrics NodePort

• RAM: 4GB

• CPU: 2 cores

• Storage: 25GB

🚀 Docker & Docker Compose Installation on Ubuntu 22.04

🔄 Step 1: Update the Machine

sudo apt update -y

🧹 Step 2: Remove Conflicting Packages

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do 
  sudo apt-get remove $pkg; 
done

📦 Step 3: Setup Docker’s APT Repository

Add Docker's Official GPG Key:

sudo apt-get update
sudo apt-get install ca-certificates curl -y
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Add Docker Repository:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

📥 Step 4: Install Docker & Docker Compose

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

✅ Step 5: Verify Docker Installation

sudo docker run hello-world

👨‍💻 Step 6: Run Docker as a Non-Root User

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker
docker run hello-world

Now you can run Docker without sudo.

☸️ Install MicroK8s on Ubuntu 22.04

🔄 Step 1: Update the Machine

sudo apt update -y

📥 Step 2: Install MicroK8s

sudo snap install microk8s --classic --channel=1.32

👥 Step 3: Add Your User to the MicroK8s Group

sudo usermod -a -G microk8s $USER
mkdir -p ~/.kube
chmod 0700 ~/.kube

🔄 Step 4: Apply Group Changes

Exit and log in again or run:

exit

✅ Step 5: Check MicroK8s Status

microk8s status --wait-ready

🔗 Step 6: Set Kubernetes Alias

alias kubectl='microk8s kubectl'

☸️ Step 7: Access Kubernetes Cluster

kubectl get nodes

🏗️ Adding a Worker Node to MicroK8s Cluster

📥 Step 1: Install MicroK8s on Worker Node

sudo apt update -y
sudo snap install microk8s --classic --channel=1.32

🖥️ Step 2: Get Join Command from Master Node

microk8s add-node

This will provide a join command like:

sudo microk8s join <join-command>

⚠️ Important: Both machines (master and worker) must be on the same network.

🔗 Step 3: Run Join Command on Worker Node

sudo microk8s join <join-command>

✅ Step 4: Verify Node is Joined (on Master Node)

microk8s kubectl get nodes

🔗 Optional: Set Alias for kubectl

alias kubectl='microk8s kubectl'

⏹️ To Stop MicroK8s

microk8s stop

✅ Conclusion

You’ve successfully installed Docker, Docker Compose, and MicroK8s on your Ubuntu 22.04 machine. Whether you’re running containers or deploying Kubernetes clusters locally, this guide should help you get started with containerization and orchestration smoothly.

To set up the server, I created a Droplet with the following specifications:

• 8GB RAM, 4-core CPU (recommended for optimal performance)

• Ubuntu 24.04 LTS (must use one of: 20.04 LTS, 22.04 LTS, or 24.04 LTS)

Additionally, I configured my DNS A record to point my GitLab subdomain (gitlab.hassandevops.site) to my server's public IP address using GoDaddy as my domain registrar. Make sure to do this in your GoDaddy DNS settings before proceeding.

GitLab is a popular DevOps platform that allows you to manage repositories, CI/CD pipelines, and more. In this guide, we will walk through the installation and initial configuration of GitLab on an Ubuntu server.

Step 1: Install and Configure Dependencies

Before installing GitLab, ensure that your system is up-to-date and that necessary dependencies are installed. Run the following commands:

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

Additionally, install Postfix (or an alternative SMTP solution) to enable notification emails:

sudo apt-get install -y postfix

During the Postfix installation, a configuration screen may appear. Choose 'Internet Site' and press enter. Use your server's external DNS for 'mail name', then press enter. If additional configuration screens appear, accept the defaults by pressing enter.

Step 2: Add the GitLab Package Repository and Install GitLab

To install GitLab, first add the GitLab package repository:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Then, install GitLab with the following command. Be sure to replace https://gitlab.example.com with your desired GitLab URL:

sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

If you wish to specify a particular version of GitLab, use:

# List available versions:
apt-cache madison gitlab-ee

# Install a specific version:
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee=16.2.3-ee.0

# Pin the installed version to prevent auto-updates:
sudo apt-mark hold gitlab-ee

# Show pinned versions:
sudo apt-mark showhold

i use this for installing GitLab on gitlab.hassandevops.site, use:

sudo EXTERNAL_URL="https://gitlab.hassandevops.site" apt-get install gitlab-ee

# List available versions:
apt-cache madison gitlab-ee

# Install a specific version:
sudo EXTERNAL_URL="https://gitlab.hassandevops.site" apt-get install gitlab-ee=16.2.3-ee.0

# Pin the installed version:
sudo apt-mark hold gitlab-ee

# Show pinned versions:
sudo apt-mark showhold

Step 3: Access GitLab and Log In

Once installation is complete, navigate to your GitLab URL in a browser.

If you did not specify a custom administrator password, a randomly generated password will be stored in:

/etc/gitlab/initial_root_password

Use this password along with the username root to log in.

With GitLab installed, you can now configure your repositories, CI/CD pipelines, and user management. For further customization and security enhancements, check out the official GitLab documentation.

GitLab Access URL:

https://gitlab.hassandevops.site

• Unplanned breaks in workflow can negatively impact productivity.

• Our brains aren’t like computers: It takes time to load and switch tasks, and each shift forces your brain to refocus.

• Each interruption causes you to sort through memory to figure out where you were.

• Context-switching is borrowed from operating systems (OS) where it refers to switching between tasks or processes.

• With too many inputs (emails, chats, open tabs), it's easy to get distracted.

• During complex tasks, our brains handle multiple pieces of information, but only up to 7 items in short-term memory.

• Interruptions shatter this mental model.

• Developers need an average of 23 minutes to fully rebuild focus after an interruption.

• Mental energy reduction: Developers facing frequent interruptions show signs of mental fatigue much earlier, leading to more errors later in the day.

• Code quality suffers due to the impact on focus and mental energy.

Flow State

• Flow state is when work feels effortless, and time seems to disappear.

• This state is fragile, and a single notification can instantly break it.

Strategies to Prevent Context Switching

For Developers

1. Set clear goals: Know what needs to be accomplished.

2. Capture tasks on a TODO list: Have a record of tasks to reduce mental load.

3. Prioritize tasks: Focus on high-priority work first.

4. Deep work blocks: Schedule 90-minute blocks for uninterrupted focus.

5. Parking lot technique: Keep a list of non-urgent tasks to deal with later.

6. Interruptible workflow: Leave comments in code so you can pick up where you left off.

7. Minimize distractions: Turn off notifications or use noise-canceling headphones.

8. Don’t multitask: Focus on one task at a time for better results.

9. Ergonomics: Set up your desk and monitor for comfort to reduce physical strain.

10. Organized environment: Keep your workspace tidy to minimize cognitive load.

11. Regular breaks: Take short breaks to recharge.

12. Be intentionally responsive: Decide when and how to engage with others.

13. Plan your day strategically: Structure your time for maximum focus.

14. Take proper rest: Ensure adequate sleep and downtime.

For Teams

1. Interruption protocols: Define which tasks can be interrupted and which cannot.

2. Focus time agreements: Set specific times for deep work (e.g., no meetings in the afternoon).

3. Asynchronous communication: Use messages and emails instead of immediate calls or chats.

4. Flexible working hours: Allow team members to work when they are most productive.

5. Normalize saying NO: Empower the team to refuse non-essential interruptions.

6. Make meetings meaningful: Ensure meetings are purposeful and efficient.

Tracking and Measuring Disruptions

1. Unplanned interruptions: Track how many occur each day.

2. Duration of uninterrupted coding sessions: Monitor increases over time.

3. Code quality metrics: Check bug rates and review feedback for quality insights.

4. Team satisfaction scores: Survey the team regularly to gauge satisfaction.

5. Sprint velocity trends: Monitor if velocity improves after reducing interruptions.

This organization provides a clear view of both the issues and strategies involved in reducing context-switching for developers, helping to maintain productivity and code quality.

1. Deepseek API's
2. ChatGPT for education API's
3. https://www.khanmigo.ai/

• DeepSeek API: We can use the DeepSeek LLM Chat 67B and DeepSeek-V3 models within Together AI. For other models, we need to create an account on DeepSeek and purchase the API separately.

• ChatGPT for Education API: This API is designed for large organizations, such as universities, and uses GPT-4. Pricing is available upon request, but GPT-4 can also be accessed through Together AI.

• Khanmigo: Khanmigo is a SaaS product focused on educational support and is not suitable for large-scale API integrations or embedding.

Khanmigo, developed by Khan Academy, is an AI tutor focused on helping students across various subjects. While it provides educational support and guidance, it is not designed for business or advanced AI embedding use cases like those of DeepSeek or ChatGPT Education.

Upgrading Your Kubernetes Cluster

Upgrading your cluster involves updating kubeadm, applying the upgrade to the control plane, and ensuring nodes and components align with the new version. Below are the detailed steps:

Steps to Upgrade the Cluster

1. Check the Nodes in the Cluster:

    kubectl get nodes
   

   This command lists all nodes in the cluster and their current status.

2. Update the System Package Index:

    sudo apt update
   

3. Check Available Versions of kubeadm:

    sudo apt-cache madison kubeadm
   

   Identify the version of kubeadm you want to install. Replace 1.30.x with the desired version.

4. Install the New Version of kubeadm:

    sudo apt-mark unhold kubeadm && \
    sudo apt-get update && sudo apt-get install -y kubeadm=1.30.x-* && \
    sudo apt-mark hold kubeadm
   

5. Verify the Installed kubeadm Version:

    kubeadm version
   

6. Plan the Upgrade:

    sudo kubeadm upgrade plan
   

   This command shows the current cluster state, available upgrades, and a step-by-step guide for applying the upgrade.

7. Apply the Upgrade:

    sudo kubeadm upgrade apply v1.30.x
   

   Replace v1.30.x with the target version. This updates the control plane components.

8. Upgrade the Nodes: After upgrading the control plane, update the nodes by following similar steps, ensuring kubelet and kubectl versions match the control plane.

Backing Up Your Kubernetes Cluster

Reliable backups are critical for disaster recovery and cluster restoration. Here are two popular backup methods:

1. Built-in ETCD Backup

ETCD is the primary datastore for Kubernetes and stores all cluster state information. To back it up:

1. Use etcdctl for Backup:

    ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/server.crt \
      --key=/etc/kubernetes/pki/etcd/server.key \
      snapshot save /path/to/backup/etcd-snapshot.db
   

   Replace /path/to/backup/etcd-snapshot.db with the desired backup location. Ensure you provide the correct certificate paths (usually located in /etc/kubernetes/pki/etcd/).

2. Verify the Backup:

    ETCDCTL_API=3 etcdctl snapshot status /path/to/backup/etcd-snapshot.db
   

2. Velero for Production Backups

Velero is a widely-used third-party tool for backing up and restoring Kubernetes clusters. It is particularly useful for production environments.

1. Install Velero: Follow the official Velero documentation to install it in your cluster.

2. Create a Backup:

    velero backup create <backup-name> --include-namespaces=<namespace>
   

   Replace <backup-name> with a descriptive name and <namespace> with the desired namespace (or use --all-namespaces).

3. Verify Backups:

    velero backup get
   

4. Restore from Backup:

    velero restore create --from-backup <backup-name>
   

Conclusion

Regularly upgrading and backing up your Kubernetes cluster ensures stability, security, and disaster recovery readiness.

Key Notes:

• Always test upgrades in a staging environment before applying them to production.

• For built-in ETCD backups, validate the snapshot's integrity.

• Velero provides a flexible, production-ready solution with cloud storage support.

By following the above methods, you can confidently maintain your Kubernetes infrastructure and mitigate risks effectively.

• Helm: Kubernetes Package Manager

• YAML Validation and Best Practices

• Monitoring Kubernetes Clusters

• Enhancing Cluster Security

1. Helm: Simplifying Kubernetes Package Management

What is Helm?

Helm is a package manager for Kubernetes that makes deploying and managing applications easier by using charts—a collection of pre-configured Kubernetes resources. Instead of writing complex YAML files for deployments, Helm allows you to deploy applications like Apache servers or Prometheus in minutes.

Installing Helm

To get started with Helm, follow these steps:

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null  
sudo apt-get install apt-transport-https --yes  
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list  
sudo apt-get update  
sudo apt-get install helm

Using Helm Charts

Helm charts simplify deployments:

1. Search for a chart:

    helm search hub apache
   

2. View chart details:

    helm show chart <chart-name>
   

3. Install a chart (e.g., Apache server):

    helm install my-apache bitnami/apache
   

4. Customize a deployment using your values file:

    helm install my-apache bitnami/apache --values apache-custom.yaml
   

5. List installed releases:

    helm ls
   

6. Uninstall a release:

    helm uninstall my-apache
   

Deploying Prometheus and Grafana with Helm

Let’s deploy a monitoring stack with Helm:

Step 1: Add the Helm Repository

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update

Step 2: Install Prometheus-Grafana Stack

kubectl create ns monitoring  
helm install prometheus --namespace monitoring prometheus-community/kube-prometheus-stack

Step 3: Access the Grafana Dashboard

1. Check running pods and services:

    kubectl get pods -n monitoring  
    kubectl get svc -n monitoring
   

2. Port-forward Grafana for local access:

    kubectl port-forward -n monitoring service/prometheus-grafana 3000:80
   

3. Access Grafana in your browser:

   • URL: http://localhost:3000

2. Validating YAML Files in Kubernetes

Why Validate YAML?

A minor syntax error can break your Kubernetes deployment. Tools like kubeval and kube-score ensure your YAML files are correctly configured and optimized.

YAML Validation Tools

1. kubeval:

    kubeval deployment.yaml
   

2. kube-score:

    kube-score score deployment.yaml
   

Using Environment Variables in YAML

You can use tools like envsubst to inject variables into your YAML files dynamically:

export APP_NAME=my-app  
envsubst < deployment-template.yaml > deployment.yaml

3. Multi-Cluster Management and Security

Multi-Cluster Deployment

Helm supports deploying to multiple clusters by configuring kubeconfig files and specifying the target cluster:

export KUBECONFIG=/path/to/kubeconfig  
kubectl config use-context <cluster-name>

Ingress in Kubernetes

Ingress resources expose HTTP and HTTPS routes from outside the cluster to services within it. A sample ingress YAML:

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: example-ingress  
spec:  
  rules:  
    - host: example.com  
      http:  
        paths:  
          - path: /  
            pathType: Prefix  
            backend:  
              service:  
                name: example-service  
                port:  
                  number: 80

4. Enhancing Security in Kubernetes

Cluster Scanning with Kubescape

Kubescape is a Kubernetes-native tool for scanning clusters for vulnerabilities:

kubescape scan --include-namespace dev

Decode Kubernetes Secrets

Secrets in Kubernetes are base64-encoded. To decode them:

kubectl get secret <secret-name> -n <namespace> -o jsonpath='{.data.<key>}' | base64 --decode

5. Upgrading Kubernetes Clusters

Upgrading clusters ensures you get the latest features and security patches. General steps:

1. Upgrade the control plane components (e.g., kube-apiserver, kube-scheduler).

2. Upgrade node components (e.g., kubelet, kubectl).

3. Verify cluster functionality post-upgrade.

Conclusion

Helm simplifies Kubernetes deployments, YAML validation ensures robustness, and monitoring and security tools help maintain a healthy cluster. Mastering these tools will empower you to manage Kubernetes environments effectively.

Happy K8s journey!

What is RBAC?

RBAC allows administrators to assign specific permissions to users or groups. This ensures users only have access to the resources they need, limiting potential security risks. Here’s a breakdown:

1. Role: Defines permissions for specific resources in a namespace.
   Example: A role allowing a user to create and delete pods in the dev namespace.

2. ClusterRole: Similar to a Role but not namespace-specific, granting access to resources cluster-wide.

3. RoleBinding: Associates a Role with a user or group within a namespace.

4. ClusterRoleBinding: Associates a ClusterRole with a user or group across the cluster.

RBAC Workflow Example

We’ll demonstrate how to create a user named Hassan, set up their credentials, and assign them a role with limited permissions in the dev namespace.

Step 1: User Creates an OpenSSL Key and CSR

On Hassan's workstation, generate a private key and a certificate signing request (CSR).

# Generate a private key
openssl genrsa -out user.key 2048

# Create a CSR (replace "username" with the actual username)
openssl req -new -key user.key -out user.csr -subj "/CN=hassan"

Step 2: Submit CSR to the Manager

Hassan submits the key and CSR to the manager (or CA).

# Transfer files to the manager
scp user.key user.csr login@manager:

Step 3: Manager Issues a Certificate

The manager (Root CA) signs the CSR and sends the certificate back to Hassan.

# Sign the CSR with the Kubernetes Root CA
openssl x509 -req -in user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial -out user.crt -days 365

# Return the certificate to Hassan
scp user.crt login@workstation:

Step 4: Set Up Kubernetes Configuration on User Workstation

Hassan creates a .kube directory and configures kubectl.

1. Create the configuration directory:

    mkdir -p ~/.kube
   

2. Copy the necessary config file from the manager (without root credentials).

3. Install kubectl on the workstation:

    sudo snap install kubectl --classic
   

4. Set user credentials in the Kubernetes context:

    kubectl config set-credentials hassan --client-certificate=user.crt --client-key=user.key
    kubectl config set-context hassan-context --cluster=kubernetes --namespace=dev --user=hassan
   

Step 5: Assign a Role to the User

Role Example: Allow Pod Management in the dev Namespace

1. Create a YAML file defining the Role:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: dev
      name: pod-manager
    rules:
    - apiGroups: [""] # "" indicates the core API group
      resources: ["pods"]
      verbs: ["create", "delete"]
   

2. Apply the Role:

    kubectl apply -f role.yaml
   

Step 6: Bind the Role to the User

Create a RoleBinding to associate Hassan with the pod-manager Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-hassan
  namespace: dev
subjects:
- kind: User
  name: hassan
  apiGroup: ""
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: ""

Apply the RoleBinding:

kubectl apply -f rolebinding.yaml

Step 7: Verify Permissions

Hassan can check their permissions using:

# Check if Hassan can delete pods in the `test` namespace
kubectl auth can-i delete pods -n test

Managers can verify Hassan's permissions:

# Verify as Hassan
kubectl auth can-i delete pods --as hassan -n dev

# List roles in the `dev` namespace
kubectl get roles -n dev

Important Notes

1. Kubeconfig for Users: Avoid sharing kubeconfig files with root credentials. Create a dedicated configuration for each user with minimal permissions.

2. Root Access: Assigning a user to the cluster-admin role grants unrestricted access. Use it cautiously.

3. Advanced Environments: In larger setups, integrate Kubernetes with services like Active Directory for streamlined authentication.

Conclusion

RBAC is an essential security practice for Kubernetes clusters, ensuring users and applications only access what they need. By following the steps and examples above, you can implement RBAC effectively in your organization.

What Are Kubernetes Secrets?

Secrets in Kubernetes are used to store sensitive and confidential information such as passwords, API keys, and SSH keys. They prevent sensitive data from being hardcoded into your application or configuration files.

Key Characteristics:

• Encoded, not encrypted: Secrets are base64-encoded, not encrypted by default. While encoding helps obfuscate data, it doesn't protect it from being exposed.

• Data in etcd: By default, secrets are stored in etcd as plaintext, meaning data at rest isn't encrypted unless you enable encryption at the etcd layer.

Examples of Sensitive Data for Secrets:

• SSH keys

• Database usernames and passwords

• API tokens

Difference Between Encoding and Encryption:

• Encoding: Transforms data into a different format (e.g., base64) for transmission or storage but is reversible without a key.

• Encryption: Secures data using algorithms and requires a key to decrypt.

Creating and Using Secrets

Secrets can be created using imperative or declarative methods.

1. Imperative Method

kubectl create secret generic my-secret \
  --from-literal=username=admin \
  --from-literal=password=secret123

2. Declarative Method (YAML)

Define a Secret in a YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4= # Base64-encoded value of 'admin'
  password: c2VjcmV0MTIz # Base64-encoded value of 'secret123'

Apply the configuration:

kubectl apply -f secret.yaml

Using Secrets in a Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx
        env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password

What Are ConfigMaps?

ConfigMaps store non-sensitive data in key-value pairs or configuration files. They allow you to decouple configuration details from your application code.

Key Use Cases:

• Application configuration files (e.g., httpd.conf for Apache).

• Environment-specific variables to control application behavior.

Creating and Using ConfigMaps

1. Imperative Method

kubectl create configmap devapache --from-file=httpd.conf

2. Declarative Method (YAML)

Define a ConfigMap in a YAML file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: devapache
data:
  httpd.conf: |
    ServerName localhost
    Listen 8080

Using ConfigMaps in a Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache-app
  template:
    metadata:
      labels:
        app: apache-app
    spec:
      containers:
      - name: apache-container
        image: httpd
        volumeMounts:
        - name: config-volume
          mountPath: /usr/local/apache2/conf
          subPath: httpd.conf
      volumes:
      - name: config-volume
        configMap:
          name: devapache

Important Note: In the volumeMounts section:

• Use the directory name (not the filename) in the mountPath where the ConfigMap data should be placed inside the container.

Comparison: Secrets vs. ConfigMaps

Conclusion

Secrets and ConfigMaps are essential tools for managing configuration and sensitive data in Kubernetes. While Secrets provide an additional layer of security through obfuscation, ConfigMaps allow seamless application configuration. Remember to:

1. Enable encryption at rest for etcd to secure Secrets.

2. Avoid embedding sensitive data directly into YAML files.

3. Use declarative approaches for better version control.

By combining these resources effectively, you can build a secure and configurable Kubernetes-based application.