DEV Community: Muhammad Kamran Kabeer

I Built a Fully Automated DevOps Workstation Using Ansible (Terraform • VirtualBox • AWS CLI)

Muhammad Kamran Kabeer — Fri, 01 May 2026 06:02:48 +0000

🚀 I Built a Fully Automated DevOps Workstation Using Ansible

I recently built a fully automated DevOps workstation setup using Ansible that provisions an entire Linux development environment in a single command.

This project is designed for DevOps learners and automation practice, and runs on a lightweight Xubuntu system (Dell Latitude E7440).

🧠 What Problem I Solved

Setting up a DevOps environment manually takes time:

Installing tools one by one
Configuring VirtualBox
Setting up Terraform, Vagrant, AWS CLI
Fixing dependencies

So I automated everything using Ansible.

⚙️ Tech Stack

Ansible (Automation Engine)
Terraform (IaC)
Vagrant (VM Automation)
VirtualBox (Virtualization)
AWS CLI (Cloud Access)
Linux (Xubuntu)

🏗️ Architecture

Host Machine → Ansible Playbook → DevOps Tools → VirtualBox VMs → Jenkins / Docker / Monitoring Stack

⚡ Features

One-command setup
Idempotent automation
Lightweight Linux optimization
Cloud-ready CLI environment
Auto dependency handling

🚀 How It Works


bash
git clone https://github.com/muhammadkamrankabeer-oss/devops-workstation-automation.git
cd devops-workstation-automation
ansible-playbook -i inventory setup.yml --ask-become-pass

📚 What I Learned
Infrastructure as Code (IaC)
Linux system automation
Real-world DevOps workflow design
GitHub Actions CI basics
Virtualization and cloud CLI setup
🔥 Future Improvements
Docker VM automation
Jenkins CI/CD pipeline
Prometheus + Grafana monitoring stack
Terraform cloud provisioning
👨‍💻 Author

Muhammad Kamran Kabeer
DevOps Learner | Linux Enthusiast | Automation Explorer

⭐ Project Link

https://github.com/muhammadkamrankabeer-oss/devops-workstation-automation

🌱 Reducing Carbon Footprint with Lightweight Docker Containers A DevOps Experiment on Image Optimization for Sustainability

Muhammad Kamran Kabeer — Fri, 17 Apr 2026 16:38:02 +0000

🧭 Introduction

In modern DevOps workflows, containerization has become a standard practice. However, most developers focus only on functionality and performance — while ignoring the hidden cost of large container images.

In this project, I explored a simple but important question:

Can we make Docker images more environmentally efficient by making them smaller?

To answer this, I built and compared two Docker images for the same application and measured the difference in size and efficiency.

🧪 Project Overview

I created a simple Flask web application and containerized it using two different approaches:

A standard Python-based Docker image
A lightweight Alpine-based Docker image

Both containers run the same application, but their internal structure is very different.

🧱 The Application

A minimal Flask app:

from flask import Flask

app = Flask(name)

@app.route("/")
def home():
return "Eco Docker Demo Running 🌱"

if name == "main":
app.run(host="0.0.0.0", port=5000)
🐳 Docker Strategy

Standard Image (Baseline) FROM python:3.10

WORKDIR /app
COPY app /app

RUN pip install flask

CMD ["python", "app.py"]

Lightweight Image (Optimized) FROM python:3.10-alpine

WORKDIR /app
COPY app /app

RUN pip install --no-cache-dir flask

CMD ["python", "app.py"]
📊 Results & Comparison

After building both images, I analyzed their sizes:

Image Type Size
Standard Python Image ~1.6 GB
Alpine Optimized Image ~97.9 MB
📉 Key Result

👉 The Alpine-based image is approximately 16x smaller

🌍 Why This Matters (The Eco Perspective)

While this may seem like a small optimization, container size directly impacts:

💾 Storage usage in registries
🌐 Bandwidth consumption during deployment
⚡ CI/CD pipeline efficiency
🔋 Indirect energy usage in cloud infrastructure

At scale, these small improvements can contribute to lower energy consumption across systems.

🚀 Running the Project

To run the optimized container:

docker run -p 5000:5000 eco-alpine

Then open:

👉 http://localhost:5000

Output:

Eco Docker Demo Running 🌱
📸 Visual Evidence (Add Your Screenshots)

Include:

Docker image size comparison
Terminal build output
Browser output of Flask app
🧠 What I Learned

This experiment helped me understand:

How base images affect container size
Why Alpine Linux is widely used in DevOps
The hidden cost of large container images
How optimization can align with sustainability goals
🔮 Final Thoughts

Optimization in DevOps is not just about speed — it's also about efficiency and responsibility.
During optimization, I explored AI-assisted suggestions (including Google Gemini) to evaluate Docker base images and improve efficiency.
Even small improvements, like switching base images, can contribute to a more sustainable digital ecosystem.

🌍 Impact

This project demonstrates how small optimizations in container design can contribute to reducing unnecessary compute usage and resource consumption in cloud environments.

View the Code on GitHub

How I Built a Self-Healing Database on a 10-Year-Old Laptop

Muhammad Kamran Kabeer — Fri, 17 Apr 2026 04:41:21 +0000

How I Built a Self-Healing Database on a 10-Year-Old Laptop (Using Docker + Ansible)

A practical experiment in resilience engineering on aging hardware—with modern DevOps tools.

🚀 Introduction

Running production-grade systems on old hardware sounds like a bad idea… until you treat it as a lab.

I set out to build a self-healing database system on a 10-year-old laptop—but this time with a more modern approach:

8 GB RAM
SSD (thankfully!)
Docker for isolation
Ansible for automation

The goal wasn’t raw performance. It was resilience, repeatability, and recovery.

🧠 What “Self-Healing” Meant in This Project

In this setup, self-healing means:

Detecting failures automatically
Restarting or replacing failed components
Recovering corrupted or lost state
Rebuilding the system with minimal manual intervention

And most importantly:

Everything should be recoverable using code.

🖥️ Why This Setup Works (Even on Old Hardware)

The SSD made a huge difference compared to traditional HDD setups:

Faster I/O → better database responsiveness
Quicker container restarts
Improved log handling and recovery

With 8 GB RAM, I had just enough room to:

Run multiple containers
Simulate primary + replica
Keep monitoring lightweight

⚙️ Architecture Overview

The system is composed of:

Primary database container
Replica database container
Monitoring container / scripts
Backup service
Ansible playbooks (control layer)

Everything runs locally but is logically separated using Docker.

🐳 Containerized Database Setup

I used Docker to run isolated database instances.

Why Docker?

Clean environment separation
Easy restarts and redeployments
Fault isolation
Reproducibility

Example (Simplified)

```yaml id="k2js9a"
version: '3'
services:
db_primary:
image: postgres:latest
ports:
- "5432:5432"

db_replica:
image: postgres:latest
ports:
- "5433:5432"




Each container behaves like an independent node.

---

## 🔁 Replication Strategy

Even on a single laptop, I implemented logical replication:

* Primary handles writes
* Replica syncs asynchronously
* Replica stays ready for failover

### Key Idea

If the primary fails:

* Promote the replica
* Spin up a new replica using automation

---

## 🤖 Automation with Ansible

This is where things got interesting.

Instead of manually fixing things, I used **Ansible playbooks** to:

* Provision containers
* Configure replication
* Restart failed services
* Rebuild broken nodes

### Example Playbook Task



```yaml id="p9dl2x"
- name: Ensure database container is running
  docker_container:
    name: db_primary
    image: postgres:latest
    state: started
    restart_policy: always

With this, recovery becomes:

Run a playbook → system fixes itself

👀 Health Monitoring

I implemented lightweight monitoring using scripts + container checks:

What I monitored:

Container health/status
Database connectivity
Replication lag
Disk usage

Basic Logic

If container stops → restart it
If DB not responding → recreate container
If replication breaks → reconfigure replica via Ansible

🔧 Self-Healing Mechanisms

Here’s how the system heals itself:

1. Container Restart (First Line of Defense)

Docker restart policies:

Automatically restart failed containers

2. Ansible Reconciliation

If something drifts from the desired state:

Re-run playbooks
Recreate containers
Reapply configs

This mimics Infrastructure as Code recovery.

3. Replica Promotion

If primary fails:

Stop primary container
Redirect traffic to replica
Promote replica to primary

4. Rebuild Failed Node

Using Ansible:

Destroy broken container
Recreate it
Resync from current primary

5. Backup + Restore

Periodic volume backups
Fast restore using Docker volumes

Even if both containers fail, recovery is still possible.

💾 Storage Strategy (SSD Advantage)

Using an SSD improved:

WAL/log write speed
Backup performance
Container startup time

Docker Volumes

Persistent storage for database data
Survives container restarts
Easily backed up

🔥 Failure Testing

I intentionally broke the system multiple times:

docker kill on primary
Deleted volumes
Simulated corruption
Stopped replication

Results

Containers restarted automatically
Ansible restored desired state quickly
Replica promotion worked reliably
Full recovery was possible from backups

📉 Trade-Offs

This setup isn’t perfect.

Downsides:

Single physical machine = single point of failure
Limited RAM → careful tuning required
SSD wear over time
Not truly “distributed”

But still valuable because:

It simulates real-world failure scenarios
Teaches recovery patterns
Builds DevOps discipline

🧩 Key Lessons

1. Docker + Ansible is a powerful combo

Docker handles runtime
Ansible handles desired state

Together, they approximate orchestration.

2. Self-healing = automation + observability

Without monitoring, automation is blind.

3. Old hardware is a great teacher

Failures happen more often → faster learning.

4. Infrastructure as Code is the real backup

If you can rebuild everything from playbooks:

You’re already halfway to self-healing.

🌱 What I’d Do Next

To push this further:

Add Prometheus + Grafana for observability
Introduce alerting (email/Slack)
Use Docker Swarm or Kubernetes
Move to multi-node setup (even with cheap machines)

🎯 Final Thoughts

This project reinforced a simple idea:

Reliability is not about powerful hardware—it’s about good design.

Even on a 10-year-old laptop, using:

Docker
Ansible
Smart recovery strategies

…you can build a system that fails gracefully and recovers automatically.

📌 GitHub Repo

https://github.com/muhammadkamrankabeer-oss/MK_Labs/tree/main/Lab4_Database

If you’ve experimented with self-healing systems or run labs on constrained hardware, I’d love to hear how you approached it!

Building a Zero-Downtime Web Cluster on a Dell Latitude

Muhammad Kamran Kabeer — Mon, 13 Apr 2026 15:45:47 +0000

The Problem: The "Single Point of Failure"
Most small businesses host their websites on a single server. If that server crashes, their business stops. In this lab, I solved that problem by building a Distributed System using Nginx and Ansible.

The Architecture: The Traffic Cop
I used a Load Balancer strategy to ensure that even if a server dies, the website stays live.

Front-End: Nginx Load Balancer (Port 8888)

Back-End: Two Nginx Workers (Ports 8081 & 8082)

Key Technical Win: Fault Tolerance
The highlight of this lab was the Chaos Test. By manually stopping one of the web server containers, I verified that the Load Balancer instantly redirected all traffic to the healthy node. The result? Zero downtime for the user.

Tools Used:
Ansible: To automate the deployment and ensure the configuration is repeatable.

Docker: To isolate the services and simulate a multi-server environment on my Dell E7440.

Check out the Standalone Code:
🔗 https://github.com/muhammadkamrankabeer-oss/MK_Labs/tree/main/Lab3_Standalone

How I Automated a Monitoring Stack on my Dell Latitude using Ansible & Docker

Muhammad Kamran Kabeer — Sun, 12 Apr 2026 09:16:23 +0000

The Vision
As part of my Technical Lab Roadmap, I am moving away from manual configurations. In the world of modern DevOps, if you have to do it twice, you should automate it. Today’s goal: Transforming my Xubuntu-powered Dell Latitude into a fully monitored node using Infrastructure as Code (IaC).

The Architecture: A Three-Tier Observability Stack
To monitor a system effectively, you need a pipeline. Data must be generated, collected, and visualized. Here is how I structured this lab:

Generation (Node Exporter): A lightweight Go-based binary that exposes hardware metrics (CPU load, RAM usage, Disk I/O) via a web endpoint.

Collection (Prometheus): The "brain" of the operation. It's a time-series database that "scrapes" the metrics from the exporter at defined intervals.

Visualization (Grafana): The "eyes." It queries Prometheus to turn raw numbers into pulsing, real-time graphs.

The "Aha!" Moment: Solving Networking Hurdles
The biggest challenge was connectivity. When running Prometheus inside a Docker container, it views localhost as itself, not my laptop.

The Solution:

The Bridge: I used the Docker Gateway IP (172.17.0.1) to allow the container to look "outside" to the host hardware.

The Guard: Xubuntu’s UFW (Uncomplicated Firewall) initially blocked these requests. I had to explicitly allow traffic on port 9100 from the Docker interface.

The Implementation: Ansible Playbook
Instead of 20 terminal commands, I consolidated the entire setup into one Ansible Playbook. This ensures Idempotency—I can run this on any machine and get the exact same result.

YAML

name: Deploy Monitoring Stack hosts: localhost connection: local become: yes

tasks:
- name: Run Node Exporter (The Sensor)
community.docker.docker_container:
name: node-exporter
image: prom/node-exporter:latest
state: started
restart_policy: always
ports:
- "9100:9100"

- name: Run Prometheus (The Brain)
  community.docker.docker_container:
    name: prometheus
    image: prom/prometheus:latest
    state: started
    recreate: yes
    volumes:
      - "./prometheus.yml:/etc/prometheus/prometheus.yml"
      - "./alert_rules.yml:/etc/prometheus/alert_rules.yml"
    ports:
      - "9091:9090"

- name: Run Grafana (The Visuals)
  community.docker.docker_container:
    name: grafana
    image: grafana/grafana:latest
    state: started
    ports:
      - "3000:3000"

Going Pro: Proactive Alerting
Monitoring is useless if you have to stare at the screen all day. I integrated Alertmanager with a custom rule:

If CPU usage exceeds 85% for more than 2 minutes, fire a CRITICAL alert.

This moves the lab from "Basic Monitoring" to "Incident Response Readiness."

Key Takeaways for Students & Peers
Infrastructure is Code: Never install manually what you can automate.

Firewalls Matter: If your data isn't flowing, check your UFW/Iptables first.

Start Small: I’m doing this on an 8GB RAM Dell laptop. You don't need a cloud budget to learn high-level DevOps.

Check out the full Source Code:
🔗 https://github.com/muhammadkamrankabeer-oss/Lab2_Monitoring_Automation

Stop Leaving Your Servers Open: Hardening Linux in 5 Minutes with Ansible

Muhammad Kamran Kabeer — Sat, 11 Apr 2026 04:40:31 +0000

Hello, World! I’m Muhammad Kamran Kabeer.

As an IT Instructor and the founder of MK EduOps Solutions, I often see students and small businesses focus on "getting things to work" while completely ignoring "getting things secured."Today, I’m sharing Lab 1 from my new series: The Hardened Gateway. We will use Ansible to automate the security of a Linux server on a Dell Latitude E7440 (or any Ubuntu/Debian machine).

🛡️ Why "Default Deny"?
Most people try to block "bad" ports. The professional way is to deny everything and only open what you need. This is the "Zero-Trust" mindset.

🛠️ The Automation Code
Here is the Ansible block I use to secure my lab environments:

YAML

name: Lab 1 - The Hardened Gateway
hosts: localhost
become: yes
tasks:
- name: Ensure UFW is installed apt: { name: ufw, state: present }
- name: Set Default Policies to DENY community.general.ufw: { state: enabled, policy: deny, direction: incoming }
- name: Allow Essential Traffic community.general.ufw: { rule: allow, port: "{{ item }}", proto: tcp } loop: ['22', '80', '443', '81'] 🚀 The Result Running this ensures that only SSH and Web traffic can enter. Everything else—unsecured databases, internal APIs, or forgotten services—is hidden from the world.

Check out the full lab repository here:https://github.com/muhammadkamrankabeer-oss/MK-EduOps-Labs

How I Automated a Self-Healing WordPress Lab using Ansible & Docker

Muhammad Kamran Kabeer — Thu, 09 Apr 2026 16:21:08 +0000

The Challenge

As an IT educator, I wanted a lab environment that was stable, professional, and "self-healing." If a student (or a bug) crashes the site, I want it back up in seconds without manual work.
The Solution

I built a stack on my Dell Latitude E7440 using:

Vagrant & Debian: To create a clean, isolated sandbox.

Ansible: To automate the configuration (Infrastructure as Code).

Docker: To run WordPress and MariaDB.

Nginx Proxy Manager: To give it a professional URL (http://wordpress.test) instead of messy IP addresses.

Why this matters

By using Docker's restart_policy: always, if the WordPress container fails, the system "heals" itself immediately.

[INSERT YOUR TWO SCREENSHOTS HERE: NPM Dashboard and WordPress Welcome Page]
Work with me!

I am a professional educator and DevOps practitioner. If you need:

Technical Writing: I can turn your complex code into clear tutorials.

Lab Setup: I can help you automate your teaching environments.

Feel free to reach out here or on LinkedIn!