Forem: Azmat Ahmed

🚀 End-to-End CI/CD Pipeline with Jenkins, Docker, Kubernetes & Argo CD (GitOps)

Azmat Ahmed — Sat, 07 Feb 2026 09:58:10 +0000

In this post, I’ll walk you through a real-world CI/CD pipeline using modern DevOps tools.
This project demonstrates how Continuous Integration and GitOps-based Continuous Deployment work together in production environments.

🔗 Source Code Repository
👉 https://github.com/Azmat-Ahmed/E-Commerce-Style-App

🧠 What This Project Covers

This project implements a complete CI/CD workflow:

Node.js E-commerce style web application

Jenkins for Continuous Integration (CI)

Docker for containerization

Docker Hub as image registry

Kubernetes for orchestration

Argo CD for GitOps-based Continuous Deployment (CD)

Separate Git repositories for source code and Kubernetes manifests

🏗 Project Architecture (High Level)
Developer → GitHub (Source Repo)
→ Jenkins (CI Pipeline)
→ Docker Build & Push
→ Docker Hub
→ Argo CD Image Updater
→ GitHub (Manifest Repo)
→ Argo CD
→ Kubernetes Cluster

📦 Application Overview

The application is a Node.js Express web app with:

A clean, professional frontend

Navigation bar and product cards

Backend API serving product data

The app runs on port 3000 and is fully containerized using Docker.

🔁 Why Two Git Repositories?
1️⃣ Source Code Repository

This repo contains:

Node.js application code

Frontend assets

Dockerfile

Jenkinsfile

👉 This repo is responsible for CI (build, test, image creation).

🔗 Source Repo:
https://github.com/Azmat-Ahmed/E-Commerce-Style-App

2️⃣ Kubernetes Manifest Repository

This repo contains:

deployment.yaml

service.yaml

ingress.yaml

👉 This repo defines what runs in Kubernetes.
Argo CD continuously watches this repository.

This separation follows the GitOps principle:

Git is the single source of truth for deployments.

⚙️ CI: Jenkins Pipeline

Whenever code is pushed to GitHub:

GitHub Webhook triggers Jenkins

Jenkins pipeline runs:

Code checkout

Docker image build

Docker image push to Docker Hub

Jenkins stops if any step fails

This ensures only valid, buildable code moves forward.

🐳 Docker Image Strategy

Each Jenkins build creates a new Docker image tag (e.g. build number or version).

Example:

azmatahmed/devops-shop:12

This image is pushed to Docker Hub and becomes available for deployment.

🔄 CD with Argo CD & Image Updater (GitOps)
Argo CD Image Updater

Monitors Docker Hub for new image tags

Automatically updates the image tag in the Kubernetes manifest repo

Commits the change back to Git

Argo CD

Watches the manifest repository

Detects changes in YAML files

Automatically syncs Kubernetes cluster state with Git

⚠️ Jenkins does not deploy directly to Kubernetes
Deployment happens only via Git changes.

This is modern GitOps CD.

☸ Kubernetes Deployment

The Kubernetes setup includes:

Deployment: runs multiple replicas of the app

Service: exposes the app internally

Ingress: routes external traffic to the service

Once Argo CD syncs:

New pods are created

Old pods are terminated

Zero-downtime rolling update occurs

✅ Benefits of This Approach

Clear separation of CI and CD

No direct cluster access from Jenkins

Full deployment history in Git

Easy rollback using Git revert

Production-ready GitOps workflow

🎯 Final Thoughts

This project represents how CI/CD is implemented in modern DevOps teams:

Jenkins focuses on building and testing

Docker ensures consistency

Kubernetes manages scalability

Argo CD provides safe, auditable deployments

If you’re learning DevOps, mastering this flow will give you a strong industry-level foundation.

🔗 Useful Links

Source Code Repo:
https://github.com/Azmat-Ahmed/E-Commerce-Style-App

🚀 End-to-End DevOps Project: Deploying a Node.js App on AWS EC2 with Docker, Kubernetes & Ingress

Azmat Ahmed — Fri, 23 Jan 2026 15:15:43 +0000

Today I completed a full real-world DevOps deployment where I built, containerized, and deployed a Node.js application using Docker, Kubernetes, Minikube, Ingress, HTTPS, and RBAC, all running on AWS EC2.

This project helped me connect all core DevOps concepts into one working system.

🔧 Tech Stack Used

Node.js – Application layer

Docker (Multi-Stage Build) – Optimized container image

Docker Hub – Image registry

AWS EC2 (Linux) – Cloud infrastructure

Kubernetes (Minikube) – Container orchestration

kubectl – Cluster management

Kubernetes Deployment & Service

NodePort Service

Ingress Controller

HTTPS (TLS Certificates)

Docker Volumes & Networks

RBAC (Role & RoleBinding)

🧱 Step 1: Node.js Application

I started with a simple Node.js web application that serves a static page to confirm deployment status.

🐳 Step 2: Docker Multi-Stage Build

To keep the image lightweight and production-ready, I used a multi-stage Docker build:

FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

FROM node:18-alpine
WORKDIR /app
COPY --from=build /app .
EXPOSE 3000
CMD ["node", "app.js"]

Benefits:

Smaller image size

Faster deployments

Better security

📦 Step 3: Push Image to Docker Hub
docker build -t /devops-node .
docker login
docker push /devops-node

Now the image is accessible from anywhere, including Kubernetes.

☁️ Step 4: AWS EC2 Setup

Launched an EC2 Linux instance

Installed:

Docker

kubectl

Minikube

Ran Minikube inside EC2 to simulate a real Kubernetes environment

☸️ Step 5: Kubernetes Deployment

Created a Deployment with multiple replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
name: node-deploy
spec:
replicas: 2
selector:
matchLabels:
app: node
template:
metadata:
labels:
app: node
spec:
containers:
- name: node
image: /devops-node
ports:
- containerPort: 3000

Applied using:

kubectl apply -f deployment.yaml

🌐 Step 6: Kubernetes Service (NodePort)
apiVersion: v1
kind: Service
metadata:
name: node-service
spec:
type: NodePort
selector:
app: node
ports:

port: 80 targetPort: 3000

This exposed the app internally within the cluster.

🔀 Step 7: Ingress Controller

Enabled ingress in Minikube:

minikube addons enable ingress

Ingress configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: node-ingress
spec:
rules:

host: devops.local http: paths:
- path: / pathType: Prefix backend: service: name: node-service port: number: 80

Mapped the domain in /etc/hosts:

devops.local

🔐 Step 8: HTTPS with TLS

Generated certificates:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout key.pem -out cert.pem

Created Kubernetes TLS secret:

kubectl create secret tls node-tls --cert=cert.pem --key=key.pem

Updated ingress with TLS configuration and re-applied it.

The site now runs on HTTPS.

📦 Step 9: Docker Volumes & Network

Created Docker volume for persistent data

Used Docker networks for container communication

Ensured clean separation of concerns

🔐 Step 10: RBAC Security

Created a Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: devops-role
rules:

apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]

Bound it using RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: devops-binding
subjects:

kind: User name: devops-user roleRef: kind: Role name: devops-role apiGroup: rbac.authorization.k8s.io

This ensured least-privilege access inside the cluster.

✅ Final Outcome

✔ Node.js app running on AWS EC2
✔ Docker multi-stage image pushed to Docker Hub
✔ Kubernetes Deployment & Service
✔ Ingress routing with HTTPS
✔ Persistent storage using volumes
✔ Secure access using RBAC

🎯 What I Learned

How real DevOps components connect end-to-end

Debugging Kubernetes ImagePullBackOff issues

Difference between NodePort, Service & Ingress

HTTPS using Kubernetes TLS secrets

Importance of RBAC in production clusters

DevOps Week 16: Kubernetes RBAC Hands-On — Securing Cluster Access

Azmat Ahmed — Sat, 11 Oct 2025 17:40:38 +0000

🧩 What I Learned This Week

This week in my DevOps journey, I implemented Kubernetes RBAC (Role-Based Access Control) — a critical mechanism for securing clusters and controlling user permissions.

⚙️ Hands-on Practice

Created a developer ServiceAccount

kubectl create serviceaccount dev-user -n default

Defined read-only permissions

kind: Role
metadata:
name: pod-reader
namespace: default
rules:

apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]

Bound the Role to the developer

kind: RoleBinding
metadata:
name: read-pods
subjects:

kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

Tested access

kubectl auth can-i list pods --as=system:serviceaccount:default:dev-user -n default # yes
kubectl auth can-i delete pods --as=system:serviceaccount:default:dev-user -n default # no

🔐 Why RBAC Matters in DevOps

Prevents unauthorized resource changes

Separates developer/tester/admin access

Enhances security compliance

Protects your Kubernetes workloads

🌱 Conclusion

RBAC is not just theory — it’s a real-world Kubernetes security control.
Through this week’s practice, I learned how to:

Create roles and bindings

Apply permissions to users

Validate actions using kubectl auth can-i

A must-learn for every DevOps engineer aiming for real-world Kubernetes expertise!

My DevOps Week 15 Journey: Kubernetes Deployments, Services, and NGINX Ingress

Azmat Ahmed — Sat, 11 Oct 2025 13:26:36 +0000

Content:

This week, I focused on Kubernetes hands-on practice using Minikube. Here’s a summary of everything I learned:

Minikube Setup

Installed and configured Minikube

Set up Master and Worker Nodes

Explored master components (API Server, Scheduler, Controller Manager, etcd)

Learned how Kubelet runs containers on nodes

Deploying Applications

Deployed Nginx, Apache, and Redis via apps.yaml

Exposed apps with NodePort Services

Key commands:

kubectl get pods
kubectl describe pod
kubectl logs

Self-Healing and Scaling

Created Deployment with 3–4 replicas

Deleted a pod manually to test self-healing

Monitored pods with:

kubectl get pods -w

Kubernetes Services

ClusterIP: Internal access

NodePort: External access via :

LoadBalancer: External access in cloud setups

Services control internal/external routing

NGINX Ingress & HTTPS

Enabled NGINX Ingress in Minikube

Created Ingress YAML for custom domain routing

Secured app with TLS/HTTPS:

kubectl create secret tls -tls --cert=tls.crt --key=tls.key

Verified routing and HTTPS access

Key Learnings

Kubernetes provides high availability, self-healing, and scaling

Services + Ingress enable secure external access

Deployments and ReplicaSets ensure reliable pod management

Hands-on practice with Minikube strengthens understanding of Kubernetes architecture

# 🚀 DevOps Journey — Week 14: Kubernetes Scaling & Automation

Azmat Ahmed — Sun, 28 Sep 2025 06:55:30 +0000

In my DevOps Journey Week 14, I moved from Docker & Compose into the world of Kubernetes.

This was a huge milestone: learning how to handle scaling, automation, and thousands of users without downtime.

🔹 Step 1: Docker Networking

Before K8s, I explored Docker networking:

Bridge → local isolated communication
Host → container shares host’s network
Overlay → multi-host (Swarm, cluster setups)

🔹 Step 2: Docker Compose

Next, I practiced multi-service apps:


yaml
version: "3.9"
services:
  web:
    image: nginx
  db:
    image: mysql:5.7
With a single command:

bash
Copy code
docker-compose up -d
This was enough for small dev projects.

🔹 Step 3: Kubernetes — the Game Changer
Here’s where Week 14 really leveled up.
Kubernetes gave me:

Scaling → add more pods instantly.

Self-healing → crashed pods restart automatically.

Rolling updates → zero downtime deploys.

Load balancing → spread traffic across pods.

Commands I used:
bash
Copy code
kubectl create deployment web --image=nginx
kubectl expose deployment web --type=NodePort --port=80
kubectl scale deployment web --replicas=5
kubectl get pods
🔥 Reflection
Docker was my foundation.

Docker Compose gave me small multi-service apps.

But Kubernetes unlocked production-level orchestration.

This week felt like moving from “developer” → “DevOps engineer.”

#devops #docker #kubernetes #devto #devopsjourney

🚀 Week 13 DevOps Journey: Multi-Stage Docker Builds (From 1.2GB 3MB)

Azmat Ahmed — Tue, 16 Sep 2025 09:09:10 +0000

While working through my DevOps journey (Week 13), I deployed a Node.js app to AWS EC2 and compared single-stage vs multi-stage Docker builds.

Here’s what I learned 👇

🐳 Simple Dockerfile

Uses a full Node.js base image.

Includes build tools + dependencies.

Final size: 1.2GB.

⚡ Multi-Stage Dockerfile

Build stage: compiles and prepares app.

Run stage: copies only the essentials.

Base: distroless image.

Final size: 3MB 😍.

Why This Matters in DevOps

Production environments need lightweight images.

Faster push/pull → smoother CI/CD pipelines.

Lower resource usage on servers.

More secure (no unnecessary OS packages).

🔗 Check out my implementation here: GitHub Repo

🌐 See more about me: https://azmatahmed.netlify.app

Keywords: Docker, Multi-stage builds, Node.js Dockerfile, AWS EC2, Distroless images, DevOps best practices, Optimize Docker images, DevOps learning.

🚀 Docker in DevOps – Node.js Deployment on AWS EC2 (Week 12 Journey)

Azmat Ahmed — Mon, 08 Sep 2025 08:07:20 +0000

🚀 Docker in DevOps – Node.js Deployment on AWS EC2 (Week 12 Journey)

In Week 12 of my DevOps journey, I focused on Docker and successfully deployed a Node.js app on AWS EC2.

🔹 What I Did

Wrote a Dockerfile with Node.js as the base image.
Installed dependencies automatically with:


dockerfile
  COPY package*.json ./
  RUN npm install
Built image:

bash
Copy code
docker build -t my-node-app .
Ran container:

bash
Copy code
docker run -p 3000:3000 my-node-app
Configured AWS EC2 security groups for port 3000.

🔹 Why Docker?
Removes manual setup

Creates consistent environments

Speeds up deployments

Root tool of DevOps automation

📂 Links
👉 GitHub Repo: https://github.com/azmatahmed11/docker-push-docker
🌐 Portfolio: https://azmatahmed.netlify.app/

🔑 Keywords
Docker, DevOps, Node.js app deployment, AWS EC2, Dockerfile, containerization, automation

🚀 Week 11 of My DevOps Journey: GitHub Actions CI/CD on AWS EC2

Azmat Ahmed — Sat, 30 Aug 2025 10:36:04 +0000

This week I got hands-on with GitHub Actions and built a CI/CD pipeline to deploy my Node.js app to AWS EC2.

Unlike Jenkins, GitHub Actions doesn’t require setting up servers or webhooks manually — everything happens in the .yml workflow file. It’s a much smoother process for automation.

🔧 What I Achieved

Built and configured GitHub Actions pipeline.

Automated deployment of Node.js app to AWS EC2.

Handled multiple errors during pipeline creation.

Successfully exposed the app on port 3000 by configuring AWS EC2 security rules.

💡 Takeaway

GitHub Actions simplifies CI/CD automation, making deployment faster, easier, and fully integrated with GitHub.

devops #github #githubactions #cicd #aws #node #cloud #ec2 #automation #deployment

🚀 DevOps Journey– Week 10 (Mastering Jenkins CI/CD)

Azmat Ahmed — Wed, 20 Aug 2025 16:29:55 +0000

🔹 Recap

This week was all about Jenkins. I built multiple pipelines and deployed my Node.js app to AWS EC2 using Jenkins. Now, when I update my GitHub repo and click Build Now, Jenkins automatically updates my app on EC2.

✅ Achievements

Set up Jenkins on my server

Configured Jenkins pipeline for Node.js app

Connected GitHub → Jenkins → EC2 deployment

Used PM2 to manage and restart the Node.js app

Automated CI/CD successfully 🎉

🔹 Jenkins Pipeline Script
pipeline {
agent any
stages {
stage('Checkout') {
steps {
git branch: 'main',
url: 'https://github.com/Azmat-Ahmed/deploycicd.git'
}
}
stage('Dependencies') {
steps {
sh 'npm install'
}
}
stage('Deploy') {
steps {
sh """
ssh -o StrictHostKeyChecking=no -i /var/lib/jenkins/test.pem ubuntu@ << 'EOF'
cd /home/ubuntu/deploycicd
git pull origin main
npm install
pm2 restart app.js || pm2 start app.js
EOF
"""
}
}
}
}

🎯 What’s Next?

In the next stage of my journey, I will be exploring:

GitHub Webhooks → for fully automated Jenkins triggers

GitHub Actions → GitHub’s native CI/CD tool

But for now, I can confidently say: Week 10 = Jenkins Mastery ✅

👉 My portfolio: https://azmatahmed.netlify.app

🚀 DevOps Journey – Week 10 (Mastering Jenkins CI/CD)

Azmat Ahmed — Wed, 20 Aug 2025 16:23:25 +0000

🔹 Recap

✅ Achievements

Set up Jenkins on my server

Configured Jenkins pipeline for Node.js app

Connected GitHub → Jenkins → EC2 deployment

Used PM2 to manage and restart the Node.js app

Automated CI/CD successfully 🎉

🎯 What’s Next?

In the next stage of my journey, I will be exploring:

GitHub Webhooks → for fully automated Jenkins triggers

GitHub Actions → GitHub’s native CI/CD tool

But for now, I can confidently say: Week 10 = Jenkins Mastery ✅

👉 My portfolio: azmatahmed.netlify.app

Week 9 DevOps: Terraform on AWS — Remote State, Modular Code & Best Practices

Azmat Ahmed — Tue, 12 Aug 2025 09:11:14 +0000

Hey everyone, I’m Azmat Ahmed!

This week, my Week 9 DevOps journey focused on Terraform — provisioning AWS infrastructure using Infrastructure as Code.

Highlights:

Used Terraform commands: terraform init, plan, apply, and destroy
Set up remote state storage on AWS S3, with DynamoDB for state locking — critical for collaboration
Modularized Terraform files: split EC2, S3, DynamoDB resources into separate .tf files
Provisioned EC2 instances, created S3 buckets, and DynamoDB tables with Terraform
Followed best practices: never commit .tfstate files, use remote state, version control
Ran Terraform on Linux, practiced debugging and deployment

Why Terraform?

Terraform brings the power of Infrastructure as Code — enabling automation, consistency, and scalability for cloud infrastructure.

Sample Terraform file structure:


plaintext
main.tf
variables.tf
ec2.tf
s3.tf
dynamodb.tf
outputs.tf
terraform.tfvars
Let’s connect!
Portfolio: https://azmatahmed.netlify.app

LinkedIn: https://www.linkedin.com/in/azmat-ahmed-13610a314/

Email: ahmedawan9519@gmail.com

"DevOps Journey: Week 8 - Automating Configuration with Ansible"

Azmat Ahmed — Mon, 04 Aug 2025 03:44:48 +0000

Hey everyone! 👋

I’ve just wrapped up Week 8 of my DevOps journey, where I focused entirely on learning and applying Ansible — the powerful automation tool used widely in production environments.

🔧 What I Covered:

Installed and configured Ansible on Ubuntu
Wrote and applied Playbooks using YAML
Created and used Inventory Files (static & dynamic)
Explored Ansible Galaxy to download and reuse roles
Restarted services, installed packages, and configured remote servers

🧪 Hands-On Practice:

Real-time tasks using VMs and EC2 instances
Used SSH for secure communication
Built modular playbooks for easier reuse

📈 Progress Summary:

Task	Status
Install Ansible	✅
Inventory Files	✅
Playbooks	✅
Ansible Galaxy	✅
Multi-server Configuration	✅

🔜 What’s Next:

In Week 9, I’ll move on to Terraform to learn how to provision infrastructure as code.

🔗 Let’s Connect!

🌐 My Portfolio
🐙 GitHub
💼 LinkedIn

Forem: Azmat Ahmed

🚀 End-to-End CI/CD Pipeline with Jenkins, Docker, Kubernetes & Argo CD (GitOps)

🚀 End-to-End DevOps Project: Deploying a Node.js App on AWS EC2 with Docker, Kubernetes & Ingress

DevOps Week 16: Kubernetes RBAC Hands-On — Securing Cluster Access

My DevOps Week 15 Journey: Kubernetes Deployments, Services, and NGINX Ingress

# 🚀 DevOps Journey — Week 14: **Kubernetes Scaling & Automation**

🔹 Step 1: Docker Networking

🔹 Step 2: Docker Compose

🚀 Week 13 DevOps Journey: Multi-Stage Docker Builds (From 1.2GB 3MB)

🚀 Docker in DevOps – Node.js Deployment on AWS EC2 (Week 12 Journey)

🔹 What I Did

🚀 Week 11 of My DevOps Journey: GitHub Actions CI/CD on AWS EC2

devops #github #githubactions #cicd #aws #node #cloud #ec2 #automation #deployment

🚀 DevOps Journey– Week 10 (Mastering Jenkins CI/CD)

🚀 DevOps Journey – Week 10 (Mastering Jenkins CI/CD)

Week 9 DevOps: Terraform on AWS — Remote State, Modular Code & Best Practices

Highlights:

Why Terraform?

Sample Terraform file structure:

"DevOps Journey: Week 8 - Automating Configuration with Ansible"

🔧 What I Covered:

🧪 Hands-On Practice:

📈 Progress Summary:

🔜 What’s Next:

🔗 Let’s Connect!

# 🚀 DevOps Journey — Week 14: Kubernetes Scaling & Automation