DEV Community: Ritesh Singh

🚀 AWS Multi-Region Disaster Recovery Architecture (Production-Grade)

Ritesh Singh — Thu, 22 Jan 2026 19:23:40 +0000

📌 Overview

In real-world systems, downtime is not an option. Cloud applications must survive instance failures, service outages, and even full regional failures.

In this blog, I’ll walk you through a hands-on AWS Multi-Region Disaster Recovery (DR) architecture that automatically shifts traffic to a secondary region without manual intervention.

This project simulates how enterprise systems survive regional outages.

🏗️ Architecture Diagram

🔧 Architecture Components

Primary Region (ap-south-1)

Application Load Balancer (ALB)
Auto Scaling Group (EC2 instances from AMI)
Amazon RDS (Primary)
Amazon EFS (Shared storage)

Disaster Recovery Region (us-east-1)

Application Load Balancer (ALB)
Auto Scaling Group (EC2 from copied AMI)
Amazon RDS Read Replica
Amazon EFS backup / replicated data

Global Services

Amazon Route 53 (DNS Failover & Health Checks) ## 🔄 Disaster Recovery Flow

User traffic enters through Amazon Route 53
Route 53 routes traffic to Primary ALB (ap-south-1)
Health checks continuously monitor application health
On failure detection:
- Route 53 redirects traffic to DR ALB (us-east-1)
- Auto Scaling launches EC2 instances from copied AMI
- RDS Read Replica is promoted to Primary
Application becomes available from DR region without manual intervention

📂 Implementation Details

Detailed, step-by-step implementation guides with screenshots and diagrams
are available in the /steps directory:

EC2 & AMI creation
ALB & Auto Scaling setup
Route 53 DNS failover
RDS cross-region replication & promotion
EFS backup strategy

Step 1: EC2 & AMI Setup (Primary Region)

In this step, we launch an EC2 instance in the primary region
(ap-south-1) and deploy an NGINX application.

Objective

Launch an EC2 instance and prepare a reusable AMI for Auto Scaling and DR.

Why This Step?

EC2 hosts the application
AMI ensures consistent server configuration
Enables fast recovery in another region

Services Used

EC2
AMI
Security Groups

Implementation Steps

1️⃣ Launch EC2

Region: ap-south-1
AMI: Amazon Linux 2
Instance type: t2.micro
Security Group:
- SSH (22)
- HTTP (80)

2️⃣ Install Application

sudo yum install nginx -y
sudo systemctl start nginx

Verify Application

Open browser

http://<ec2-public-ip>

Create AMI

EC2--> Action --> Create Image
Name: primary-app-ami

OUTCOME

Application is running
AMI created for auto scalling and DR region

Step 2: ALB & Auto Scaling Setup

Objective

Ensure high availability and self-healing EC2 infrastructure.

Why This Step?

ALB distributes traffic
Auto Scaling replaces failed instances automatically

Services Used

ALB
Target Group
Auto Scaling Group
Launch Template

Implementation Steps

1️⃣ Create Target Group

Type: Instance
Protocol: HTTP
Health check path: / git pull --rebase origin main

2️⃣ Create Application Load Balancer

Internet-facing
Select ALL AZs (Best Practice)
Attach target group

3️⃣ Create Launch Template

Use AMI from Step 1
Select correct VPC Security Group

4️⃣ Create Auto Scaling Group

Desired: 2
Min: 1
Max: 4
Attach ALB

Outcome

EC2 instances auto-heal
Application always available

Step 3: Route 53 Failover Routing

Route 53 continuously monitors the health of the primary ALB
and redirects traffic to the DR region during failure.

Objective

Automatically route traffic to DR region during failure.

Why This Step?

DNS-based failover
No manual intervention needed

Services Used

Route 53
Health Checks
ALB

Implementation Steps

1️⃣ Create Hosted Zone

Domain:
riteshdev.me

2️⃣ Create Health Check

Endpoint: Primary ALB
Path: /
Failure threshold: 3

3️⃣ Create DNS Records

Primary Record

Routing: Failover (Primary)
Alias → Primary ALB
Evaluate target health: Yes

Secondary Record

Routing: Failover (Secondary)
Alias → DR ALB

Outcome

Traffic shifts automatically on failure

Step 4: RDS Disaster Recover

A cross-region read replica is maintained and promoted during
regional failure.

Objective

Protect application data using cross-region replication.

Why This Step?

EC2 is stateless
Database must survive region failure

Services Used

RDS
Cross-Region Read Replica

Implementation Steps

1️⃣ Create Primary RDS

Region: ap-south-1
Engine: MySQL
Optional: Multi-AZ

2️⃣ Create Read Replica

Region: us-east-1
Continuous replication

3️⃣ Promote Replica (DR Test)

RDS → Promote read replica

Outcome

Near-zero data loss
Production-ready DR database

🎯 Key Objectives

Build highly available infrastructure across multiple Availability Zones and Regions
Implement automatic DNS-based failover
Enable stateless application recovery using AMIs and Auto Scaling
Protect stateful data (RDS & EFS) against regional failures
Validate DR using real failure simulations

🛠️ AWS Services Used

Category	Services
Compute	EC2, AMI, Auto Scaling
Networking	VPC, ALB, Route 53
Storage	EBS Snapshots, EFS
Database	RDS (Primary + Cross-Region Read Replica)
Security	IAM, Security Groups
Monitoring	Route 53 Health Checks

🌍 Regions Used

Primary Region: ap-south-1
Disaster Recovery Region: us-east-1

📁 Project Structure

aws-multi-region-dr/
│
├── architecture/
│   └── dr-architecture.png
│
├── steps/
│   ├── ec2-setup.md
│   ├── alb-asg.md
│   ├── route53.md
│   └── rds-dr.md
│
├── screenshots/
│
└── README.md

🔄 Disaster Recovery Flow

User traffic enters through Route 53
Primary Application Load Balancer (ALB) serves traffic from ap-south-1
Route 53 continuously monitors application health
On failure:
- Traffic is automatically routed to the DR region
- Auto Scaling launches EC2 instances from the copied AMI
- RDS Read Replica is promoted to primary database

✅ No manual intervention required

🧪 Failure Scenarios Tested

Primary EC2 instance stopped
Application (NGINX) service stopped
Auto Scaling instance termination
Route 53 failover validation
RDS Read Replica promotion

➡ Result: Application remained accessible via the DR region

📊 RTO & RPO (Design Targets)

Metric	Value
RTO (Recovery Time Objective)	~1–2 minutes
RPO (Recovery Point Objective)	Seconds (replication lag)

💡 Why This Project Stands Out

Real production-style disaster recovery design
Hands-on failure testing (not just theoretical concepts)
Clean and modular documentation
Covers both stateless (EC2) and stateful (RDS, EFS) components
Strong interview-ready cloud project

This project simulates how enterprise systems survive regional outages.

🧠 Key Learnings

Difference between EC2 failover vs RDS failover
DNS-based failover using Route 53
Importance of AMI-based recovery
Cross-region replication trade-offs
Auto Scaling behavior during instance and service failures

🚀 Future Enhancements

Infrastructure automation using Terraform
CI/CD pipeline integration
CloudWatch alarms and notifications
Centralized AWS Backup policies
S3 cross-region replication

📣 About the Author

Ritesh

Aspiring Cloud & DevOps Engineer

Focused on building resilient, scalable, and secure AWS architectures

⭐ For Recruiters

This repository demonstrates:

Cloud architecture design skills
Disaster recovery planning and execution
Operational and troubleshooting mindset
Strong technical documentation practices

📌 Please explore the **/steps directory

🔥 10+ End-to-End DevOps Projects — Docker, AWS, Jenkins, Terraform, Ansible & More

Ritesh Singh — Tue, 02 Dec 2025 13:25:27 +0000

🚀 My Complete DevOps Projects Collection – From Beginner to Advanced (All in One Place)

Over the last few months, I’ve been learning DevOps deeply and building real-world projects using tools like Docker, Jenkins, AWS, GitHub Actions, Ansible, Terraform, Lambda, MongoDB, CloudFront, Prometheus, Grafana, and more.

To organize everything, I created a single repository called DevOps_Projects, where I have added all my DevOps, Cloud, and CI/CD projects, each inside its own folder.

This blog is a complete guide to my journey — what I built, what tools I used, and what I learned from each project.

Whether you're a beginner or someone preparing for DevOps interviews, this collection will help you understand real DevOps concepts with practical implementation.

🎯 Why I Created This Repository

As a fresher, one thing became clear:

Companies don’t want just theoretical knowledge — they want proof of hands-on experience.

So instead of building random mini projects, I decided to learn DevOps properly and build real-world, practical, production-like projects.

This repository is the outcome of that journey.

And I will keep adding more advanced projects as I grow.

📂 What’s Inside This Repository?

Each project has its own folder, containing:

Complete project code
Dockerfiles
CI/CD workflows
Configuration files
Project-specific README
Architecture diagrams (for some projects)

Below is the complete list of projects included so far:

🧩 Project Overview

📁 PROJECT-1 — Dockerized Flask App PROJECT-1

A beginner-friendly app containerized using Docker.

What I learned:

Creating Dockerfiles
Building/running containers
Exposing ports

📁 PROJECT-2 — Node.js + MongoDB App with Docker Compose PROJECT-2

A multi-container app using Docker Compose.

Key Learnings:

Container networking
Volumes
Service orchestration

📁 PROJECT-3 — Jenkins CI/CD Pipeline with Docker & Node.js PROJECT-3

Automated CI/CD workflow using Jenkins.

Key Learnings:

Jenkinsfile stages
Automated build → test → deploy
Docker integration

📁 PROJECT-4 — AWS CI/CD Pipeline (Node.js → EC2) PROJECT-4

A production-ready AWS CI/CD pipeline.

AWS Services Used:

CodePipeline
CodeBuild
CodeDeploy
EC2

📁 PROJECT-5 — CI/CD Pipeline for Web App PROJECT-5

A simple but complete CI/CD pipeline demonstrating core DevOps concepts.

📁 PROJECT-6 — Static Website Hosting (S3 + CloudFront + CI/CD)PROJECT-6

A global static website hosted on AWS.

What I learned:

Hosting using S3
CDN with CloudFront
Automated deployment using GitHub Actions

📁 PROJECT-7 — Flask + AWS DynamoDB CRUD App PROJECT-7

A cloud backend performing CRUD operations on DynamoDB.
Key Learnings:

Boto3 integration
NoSQL CRUD
Deploying Flask + AWS SDK inside Docker

📁 PROJECT-8 — Serverless CI/CD Pipeline PROJECT-8

A complete serverless pipeline using AWS.
AWS Services Used:

Lambda
API Gateway
S3
CodePipeline
CodeBuild

📁 PROJECT-9 — Full-Stack DevOps AutomationPROJECT-9

A large-scale app combining frontend, backend, cloud, monitoring, and CI/CD.

Tech Used:

Next.js
Docker
GitHub Actions
AWS
Prometheus & Grafana
Route 53

Key Learnings:

Observability
Automation workflows
Production-like infrastructure

📁 PROJECT-10 — DevSecOps PipelinePROJECT-10

A complete DevSecOps pipeline integrating CI/CD with security checks.

Tools Used:

Jenkins
Terraform
Ansible (with Ansible Vault)
Docker
Trivy
AWS

Key Learnings:

Infrastructure provisioning with Terraform
Secure configuration management
Vulnerability scanning
Secure CI/CD pipelines

🛠 Tech Stack Covered (So Far)

CI/CD

Jenkins
GitHub Actions
AWS Developer Tools

Containerization

Docker
Docker Compose

Cloud

AWS (EC2, Lambda, S3, CloudFront, Route53, DynamoDB)

IaC & Automation

Terraform
Ansible

Security

Trivy
IAM

Monitoring

Prometheus
Grafana

🔥 What’s Coming Next?

I will continue expanding this repository with:

Kubernetes Projects
EKS Deployment
Helm Charts
Multi-Region Terraform Architecture
Microservices with Lambda + API Gateway
ELK / Loki Log Stack
GitOps with ArgoCD

🌟 Final Words

This repository reflects my journey from beginner to someone who can design real-world DevOps systems.

If you're also learning DevOps, this repo can help you understand:

Real CI/CD pipelines
Docker in production
AWS workflow integration
How DevOps engineers think and solve problems

If you find it helpful, feel free to ⭐ star the repository — it motivates me to build more.

👨‍💻 Author

Ritesh Singh

🌐 LinkedIn

📝 Hashnode

💻GitHub

🌐 LinkedIn

🚀AWS & DevOps Project : 🚀 Building a Serverless CI/CD Pipeline with AWS Lambda, CodePipeline, and GitHub

Ritesh Singh — Mon, 10 Nov 2025 08:00:48 +0000

🚀 Building a Serverless CI/CD Pipeline with AWS Lambda, CodePipeline, and GitHub

Author: Ritesh

Introduction

In this blog, I’ll walk you through how I built a fully serverless CI/CD pipeline using AWS services — no EC2, no Jenkins, no manual intervention.

This project automatically deploys my application to Amazon S3 + CloudFront whenever I push code to GitHub, leveraging Lambda, API Gateway, CodePipeline, and CodeBuild.

Along the way, I’ll also share the difficulties I faced (like API Gateway setup and IAM permissions) and how I solved them.

Project Goal

“Automate code deployment from GitHub → AWS → CloudFront using only serverless services.”

Architecture Overview

Service used

Service	Role
GitHub	Code repository & webhook trigger
API Gateway	Receives webhook requests
AWS Lambda	Starts CodePipeline
AWS CodePipeline	Automates build and deploy stages
AWS CodeBuild	Builds and tests the application
Amazon S3	Hosts static website
Amazon CloudFront	Delivers the website globally
Amazon CloudWatch	Logs & monitors activity
AWS IAM	Manages permissions securely

Step-by-Step Implementation

Step 1: Create and Push Code to GitHub

Create a new repository — e.g. serverless-ci-cd-pipeline.
Add your frontend or simple app files (HTML/CSS/JS).
Push your code to GitHub:

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

Step 2: Create an AWS CodePipeline

Go to AWS CodePipeline → Create pipeline

Source stage:

Provider: GitHub

Connect your repo and branch

Build stage:

Provider: AWS CodeBuild

Create a new CodeBuild project

Deploy stage:

Provider: Amazon S3
Select your target S3 bucket

Now your pipeline can build and deploy manually — next we’ll automate it using webhooks.

Step 3: Create an API Gateway Endpoint

Open Amazon API Gateway → Create API

Choose HTTP API → Click Build
Under “Integrations,” choose Lambda function (we’ll create it in the next step).
Click Create

Copy the Invoke URL (you’ll use this in your GitHub webhook).

Step 4: Create AWS Lambda Function

Go to Lambda → Create function
Runtime: Python 3.9
Function name: trigger-codepipeline

Paste this code:

import boto3
import json

def lambda_handler(event, context):
    pipeline_name = "your-pipeline-name"
    codepipeline = boto3.client('codepipeline')

    response = codepipeline.start_pipeline_execution(name=pipeline_name)

    return {
        'statusCode': 200,
        'body': json.dumps('Pipeline triggered successfully!')
    }

Go to Configuration → Permissions → Execution Role

Attach policy: AWSCodePipelineFullAccess
Attach policy: CloudWatchLogsFullAccess

Deploy your Lambda function.

✅ Now Lambda can trigger your CodePipeline programmatically.

Step 5: Connect Lambda to API Gateway

In API Gateway → Integrations, select your Lambda function.

Deploy the API.

Test it by sending a POST request using:

curl -X POST https://<your-api-id>.execute-api.us-east-1.amazonaws.com

Step 6: Add GitHub Webhook

Go to your GitHub Repo → Settings → Webhooks → Add Webhook

Payload URL = your API Gateway Invoke URL
Content type = application/json

Select event: Just the push event

6 .Click Add Webhook

Now, every time you push code to GitHub, it automatically triggers the pipeline!

Testing the Pipeline

Make a small code change and push it:

git add .
git commit -m "update UI"
git push

Go to AWS CodePipeline, and you’ll see the pipeline running automatically.
After a few minutes, your updated code will be deployed to S3 and available via CloudFront URL.

Common Issues I Faced (and Solved)

Issue	Cause	Solution
❌ AccessDenied in S3	Missing IAM permissions	Attached `AmazonS3FullAccess` to CodePipeline role
❌ Lambda failed to trigger pipeline	No permission to start pipeline	Added `AWSCodePipelineFullAccess` policy to Lambda role
❌ Webhook not triggering	API Gateway method not deployed	Re-deployed the API after integration
❌ Internal server error (500)	JSON format mismatch	Validated payload from GitHub with test event

Security Best Practices

Use IAM least privilege roles (don’t overgrant permissions).
Always use HTTPS for API Gateway.
If using GitHub tokens, rotate them regularly.
Log all actions with CloudTrail (optional).

Final Outcome

Fully automated, serverless CI/CD pipeline
No EC2 or Jenkins — pay only for what you use
Deployment happens instantly on every GitHub push

Architecture Summary:

GitHub → API Gateway → Lambda → CodePipeline → CodeBuild → S3 → CloudFront

Key Learnings

How to integrate GitHub Webhooks with AWS Lambda
Event-driven DevOps design
Secure IAM role management
- Real-world CI/CD automation using AWS native tools

Conclusion

This project helped me understand the power of Serverless DevOps — simple, scalable, and cost-efficient.

It’s a perfect real-world example of how CI/CD can be built entirely with AWS services — a valuable step in my DevOps learning journey.

If you’re getting started in DevOps or AWS, try building this — you’ll learn Lambda, API Gateway, and CodePipeline in action.

Project Links

GitHub: https://github.com/ritesh355/serverless-ci-cd-demo/settings/hooks

📢 Connect With Me

💼 LinkedIn
📝 Hashnode Blog
💻 GitHub

From Beginner to Pro: The Ultimate Docker Command Cheatsheet 🐳📘

Ritesh Singh — Sun, 09 Nov 2025 09:36:37 +0000

Docker Basic Commands

Today, we focused on mastering essential Docker housekeeping commands to manage containers, images, volumes, and perform clean-up tasks effectively.

🧠 Concepts Covered

Listing running and stopped containers
Removing stopped containers and unused images
Managing Docker volumes
Executing commands inside running containers
Understanding how Docker resources accumulate over time and how to keep your environment clean

🔧 Docker Commands Practiced

CONTAINER

🔍 List Containers

docker ps              # Lists only running containers
docker ps -a           # Lists all containers (including stopped ones)

🧹 Remove Containers

docker rm <container_id>   # Removes a specific container by ID or name

💡 Tip: Use docker ps -a to find stopped containers you no longer need.

Create & Run a New Container

docker run <image_name>

If the image is not available locally, it’ll be downloaded from Docker Hub.

Run Container in Background

docker run -d <image_name>

Run Container with Custom Name

docker run --name <container_name> <image_name>

IMAGES

📦 List Docker Images

docker images

🧽 Remove Docker Images

docker rmi <image_id>      # Removes an image by its ID

💡 Useful for deleting old or unused images to free up disk space.

Remove Unused Images

docker image prune

Build an Image from a Dockerfile

docker build -t <image_name>:<version> .  # Version is optional
docker build -t <image_name>:<version> . --no-cache  # Build without cache

Port Binding in Container

docker run -p<host_port>:<container_port> <image_name>

Set Environment Variables in a Container

docker run -e <var_name>=<var_value> <container_name>  # Or <container_id>

Start or Stop an Existing Container

docker start|stop <container_name>  # Or <container_id>

Inspect a Running Container

docker inspect <container_name>  # Or <container_id>

TROUBLESHOOT

Fetch Logs of a Container

docker logs <container_name>  # Or <container_id>

Open Shell Inside Running Container

docker exec -it <container_name> /bin/bash
docker exec -it <container_name> sh

DOCKER HUB

Pull an Image from Docker Hub

docker pull <image_name>

Publish an Image to Docker Hub

docker push <username>/<image_name>

Login to Docker Hub

docker login -u <image_name>
# Or
docker login

Use docker logout to remove credentials.

Search for an Image on Docker Hub

docker search <image_name>

VOLUME

📋 List All Volumes

docker volume ls

🆕 Create a New Named Volume

docker volume create <volume_name>

❌ Delete a Named Volume

docker volume rm <volume_name>

📂 Mounting Volumes

🔗 Mount a Named Volume to a Running Container

docker run --volume <volume_name>:<mount_path>
# Or using --mount
docker run --mount type=volume,src=<volume_name>,dst=<mount_path>

❓ Mount an Anonymous Volume with Running Container

docker run --volume <mount_path>

📎 Create a Bind Mount

docker run --volume <host_path>:<container_path>
# Or using --mount
docker run --mount type=bind,src=<host_path>,dst=<container_path>

🧹 Remove Unused Local Volumes

docker volume prune

📝 Note: Use this to remove anonymous volumes that are no longer used.

🌐 Docker Networks – Quick Reference

📋 List All Networks

docker network ls

🛠️ Create a Network

docker network create <network_name>

❌ Remove a Network

docker network rm <network_name>

Remove All Unused Networks

docker network prune

⚠️ Warning: This will remove all unused networks. Ensure no containers depend on them.

🔗 Connect with Me

💼 LinkedIn – Ritesh Singh
💻 GitHub – ritesh355

Dockerfile A to Z: A Beginner’s Guide to Writing Dockerfiles the Easy Way

Ritesh Singh — Fri, 07 Nov 2025 12:19:17 +0000

🐳 What is a Dockerfile?

A Dockerfile is a 📜 plain text file with instructions to build a Docker image — think of it as a recipe for your app’s environment. When Docker reads it, it executes each step to create a lightweight, portable image for your application. 🚀

📘 Dockerfile Structure: Detailed Breakdown

Here’s how a Dockerfile works, broken down into its key components with examples and best practices. 🌟

1. FROM — Base Image 🏗️

FROM node:18

Purpose: Defines the starting point by pulling a base image from Docker Hub (e.g., node, python, ubuntu).
Why use it? Saves time by inheriting an existing environment (e.g., Node.js pre-installed).
✅ Best Practice: Always specify a version (e.g., node:18 instead of node:latest) to avoid surprises from updates.

2. WORKDIR — Working Directory 📂

WORKDIR /app

Purpose: Sets the directory for all subsequent commands. Creates /app if it doesn’t exist.
Why use it? Keeps your code organized and simplifies file paths (no need to write /app/server.js repeatedly).
✅ Best Practice: Use one WORKDIR per image unless you need to switch contexts.

3. COPY — Copy Files into the Image 📦

COPY . .

Format: COPY <source> <destination>
- Copies files from your local folder to the container’s /app directory.
Example:

  COPY package.json /app/

Why use it? Adds your app’s code or dependencies to the image.
✅ Best Practice: Use a .dockerignore file to exclude unnecessary files like node_modules or .git.

4. RUN — Execute Commands During Build ⚙️

RUN npm install

Purpose: Runs commands during the image build process. Results are cached for efficiency.
Why use it? Installs dependencies or sets up your app before it runs.
✅ Tip: Combine commands for caching (e.g., RUN apt update && apt install -y python), but keep them readable.

5. EXPOSE — Document the Port 🌐

EXPOSE 3000

Purpose: Informs Docker (and users) which port the app uses inside the container.
Important: This doesn’t publish the port. Use docker run -p to map ports.
Example:

  docker run -p 8080:3000 my-image

Maps container’s port 3000 to host’s port 8080.

✅ Best Practice: Always document the port your app uses.

6. CMD — Default Command to Run ▶️

Shell Format:

  CMD npm start

Runs via a shell. Simple but less efficient.
- Exec Format (recommended):

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

More precise, avoids extra shell processes.
- Why use it? Specifies the command to launch your app when the container starts.
- ✅ Best Practice: Use exec format and ensure only one CMD per Dockerfile (last one wins).

🛠️ Sample Dockerfile: Node.js App Example

Here’s a complete Dockerfile for a Node.js app, combining all the pieces. 🚀

# Step 1: Base image
FROM node:18

# Step 2: Set working directory
WORKDIR /app

# Step 3: Copy dependency files first
COPY package*.json ./

# Step 4: Install dependencies
RUN npm install

# Step 5: Copy the rest of the app
COPY . .

# Step 6: Expose port
EXPOSE 3000

# Step 7: Default command
CMD ["node", "index.js"]

⚡ Dockerfile Mastery Tips

Layers 🥞: Each instruction creates a cached layer. Order matters for efficient builds.
.dockerignore 🚫: Exclude unneeded files (node_modules, logs, .git) to keep images lean.
Order Matters 🔄: Place less-changing instructions (e.g., COPY package.json) early to maximize caching.
Security 🔒: Never hardcode passwords or secrets in Dockerfiles. Use environment variables or secrets management.

🌈 Happy Dockerizing! Build lightweight, reproducible images and ship your apps with confidence! 🚢

🛠️ General Best Practice: Three-Step Build Strategy

This industry-standard approach applies to nearly any language project, optimizing Docker builds for speed, efficiency, and scalability. 🚀

📋 Three-Step Build Strategy

1. Copy Dependency Files First 📦

Dependency files change less often, so copying them first maximizes Docker’s layer caching.

# Node.js
COPY package*.json ./

# Python
COPY requirements.txt ./

# Java (Maven)
COPY pom.xml ./

# Go
COPY go.mod go.sum ./

Why? Ensures dependency installation only runs when these files change.

2. Install Dependencies ⚙️

This step is time-consuming, so isolating it prevents unnecessary re-runs.

# Node.js
RUN npm install

# Python
RUN pip install -r requirements.txt

# Java (Maven)
RUN mvn dependency:resolve

# Go
RUN go mod download

Why? Caches dependencies separately, speeding up builds when only code changes.

3. Copy the Rest of the Application 📂

Add source files and configurations last, as they change most frequently.

COPY . .

Why? Isolates frequent code changes to a single layer, avoiding redundant dependency installs.

📦 Minimal Dockerfile Examples by Language

Node.js

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

Python

FROM python:3.11
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

Java (Maven)

FROM maven:3.9.4-eclipse-temurin-17
WORKDIR /app
COPY pom.xml ./
RUN mvn dependency:resolve
COPY . .
RUN mvn package
CMD ["java", "-jar", "target/app.jar"]

Go (Golang)

FROM golang:1.21
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o myapp
CMD ["./myapp"]

🎯 Why This Pattern Works

Step	Benefits
Copy dependencies first	Rarely changes, maximizes Docker layer cache for faster builds.
Install dependencies	Avoids re-running on every rebuild, saving time and resources.
Copy app code last	Isolates frequent code changes, preventing unnecessary dependency re-installs.

🧠 Summary

The three-step build strategy is the best approach because it:

🧱 Leverages Docker’s caching for faster, efficient builds.
⚡ Speeds up CI/CD pipelines (Jenkins, GitHub Actions, GitLab CI).
🧼 Keeps builds clean by separating dependencies from code.
📦 Works across all languages (Node.js, Python, Java, Go, etc.).
☁️ Scales well for production-grade pipelines.

✅ Why This Is the Best Approach

Feature	Why It Matters
🧱 Layered Build	Docker caches each instruction, so stable layers (e.g., `package.json`) save time.
⚡ Faster Rebuilds	Only rebuild changed layers, critical for rapid development and CI/CD.
🧼 Clean Separation	Dependencies and app logic are isolated, simplifying debugging and testing.
📦 Language-Agnostic	Works for Node.js, Python, Java, Go, and more — just swap the tools.
☁️ CI/CD Friendly	Optimized for tools like Jenkins, GitHub Actions, and GitLab CI that rely on caching.

🌈 Build smarter, ship faster! 🚢

THE BEST TABLE

Language	Base Image	Dependency File(s)	Run Command	CMD to Start App
Node.js	`node:18`	`package*.json`	`npm install`	`["node", "app.js"]`
Python	`python:3.11`	`requirements.txt`	`pip install -r requirements.txt`	`["python", "app.py"]`
Java (Maven)	`maven:3.9.4-eclipse-temurin-17`	`pom.xml`	`mvn dependency:resolve`	`["java", "-jar", "target/app.jar"]`
Go (Golang)	`golang:1.21`	`go.mod`, `go.sum`	`go mod download`	`["./myapp"]`
Ruby	`ruby:3.2`	`Gemfile`, `Gemfile.lock`	`bundle install`	`["rails", "server", "-b", "0.0.0.0"]`
PHP	`php:8.2-fpm`	`composer.json`, `composer.lock`	`composer install`	`["php-fpm"]`
C# (.NET)	`mcr.microsoft.com/dotnet/sdk:8.0`	`*.csproj`	`dotnet restore`	`["dotnet", "run", "--project", "app.csproj"]`

c# (.net)

FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /app
COPY *.csproj ./
RUN dotnet restore
COPY . .
RUN dotnet build
CMD ["dotnet", "run", "--project", "app.csproj"]

PHP

FROM php:8.2-fpm
WORKDIR /var/www
COPY composer.json composer.lock ./
RUN composer install
COPY . .
EXPOSE 9000
CMD ["php-fpm"]

👨‍💻 Author

Ritesh Singh

🌐 LinkedIn | 📝 Hashnode | GITHUB

Ansible for Beginners: Ansible Passwordless SSH Setup on AWS EC2 (Step-by-Step for Beginners)

Ritesh Singh — Thu, 06 Nov 2025 12:28:36 +0000

🧠 Ansible Setup with Passwordless SSH (Private Key Method)

This guide walks you through a clean Ansible setup using a dedicated ansible user, passwordless sudo, and private key authentication (no password prompt).

This setup allows your control node to manage multiple EC2 instances without entering passwords every time, making automation smooth and efficient. Perfect for beginners wanting hands-on practice with Ansible and AWS

🚀 Architecture Overview

Role	OS	Description
Control Node	Amazon Linux	Runs Ansible and manages other nodes
Managed Nodes	Amazon Linux / Ubuntu	Machines managed by Ansible

🧩 Step 1 — Create Ansible User on All Nodes

On each node (Control + Managed):

sudo adduser ansible
sudo passwd ansible

Add `ansible` to sudoers:

sudo visudo

ansible ALL=(ALL) NOPASSWD:ALL

Add this line at the end: After adding press ctrl+o then enter then ctrl+x

💡 This gives passwordless sudo access to the ansible user.

🔐 Step 2 — Configure SSH on (Managed+ controle) Nodes

Edit /etc/ssh/sshd_config on each managed node:

sudo vi /etc/ssh/sshd_config

Uncomment or add the following lines:

PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Then restart SSH:

On Amazon Linux:

  sudo systemctl restart sshd

On Ubuntu:

  sudo systemctl restart ssh

🧰 Step 4 — Install Ansible (Control Node Only)

On control node (Amazon Linux):

sudo yum install python3-pip -y

sudo pip3 install ansible

ansible --version

Verify:

ansible --version

🔑 Step 5 — Generate SSH Key Pair on Control Node

Switch to ansible user on control node:

sudo su - ansible

Generate SSH keys:

ssh-keygen -t rsa -b 2048

Press Enter for all prompts to accept defaults (no passphrase).

You’ll get:

/home/ansible/.ssh/id_rsa      (private key)
 /home/ansible/.ssh/id_rsa.pub  (public key)

📤 Step 6 — Copy SSH Key to Managed Nodes (Passwordless Setup)

Use this command on the control node:

ssh-copy-id ansible@<managed_node_private_ip>

You’ll enter the password of the ansible user only once.

Repeat for each managed node.

Example:

ssh-copy-id ansible@172.31.29.148
ssh-copy-id ansible@172.31.18.225

✅ Now test:

ssh ansible@172.31.29.148

If it logs in without asking password, passwordless SSH is working perfectly.

🧭 Step 7 — Verify Setup with Ansible Ping

Create an inventory file /home/ansible/hosts:

use this command under /home/ansible directory

sudo vi hosts

[web]
172.31.29.148 

[dev]
172.31.18.225

Now test connection:

ansible all -i hosts -m ping

Expected output:

172.31.29.148 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
172.31.18.225 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

✅ Verification Checklist

Step	Check
`ansible` user exists on all nodes	✅
Passwordless sudo enabled	✅
SSH passwordless login (private key) works	✅
`/etc/ssh/sshd_config` updated and SSH restarted	✅
Ansible ping successful	✅

🧩 Bonus Tip — Test with Ad Hoc Command

ansible all -i hosts -m shell -a "hostname"
ansible all -i hosts -m shell -a "uptime"

If you see hostnames and uptime output — congratulations 🎉
Your Ansible setup with private key passwordless access is ready!

🧾 Notes

Private key (id_rsa) always stays on the control node
Public key (id_rsa.pub) is copied to managed nodes’ ~/.ssh/authorized_keys
Never share or upload your private key to any other system...

❤️ Follow My DevOps Journey

Ritesh Singh

🌐 LinkedIn | 📝 Hashnode | GITHUB

🌐DevOps and Cloud Project: Static Website Hosting with AWS S3 + CloudFront + CI/CD

Ritesh Singh — Thu, 06 Nov 2025 05:48:26 +0000

PROJECT OVERVIEW

This project demonstrates how to host a static website on Amazon S3, deliver it globally with CloudFront CDN, and automate deployments using GitHub Actions.

🚀 Features

✅ Static website hosting on Amazon S3
✅ CloudFront CDN for global fast delivery + HTTPS
✅ CI/CD pipeline with GitHub Actions (auto-deploy on push)
✅ Cache invalidation so updates are live instantly
✅ Secure Origin Access Control (OAC) → S3 is private, only CloudFront can access

🏗️ Architecture Workflow

🔹 Request Flow

User → CloudFront (Edge Cache) → [If cache miss] → S3 Bucket → CloudFront → User

🔹 Deployment Flow

Developer → GitHub Repo → GitHub Actions → S3 Bucket → CloudFront → End User

⚙️ Setup Instructions

1️⃣ Create S3 Bucket

Go to AWS S3 Console
Create a bucket (region example: ap-south-1)
Keep Block Public Access = ON
Upload your static website files (index.html, CSS, JS, images, etc.)

2️⃣ Create CloudFront Distribution

Open CloudFront Console → Create Distribution
Origin = your S3 bucket
Use Origin Access Control (OAC) (so only CloudFront can read from S3)
Copy the CloudFront domain (e.g., d1234abcd.cloudfront.net)

3️⃣ Configure GitHub Actions

🔑 Secrets Setup in GitHub

Go to GitHub Repo → Settings → Secrets and variables → Actions → New repository secret

Add:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

🌍 Access Your Website

Default → (your CloudFront domain)

Optional → Add Route 53 + ACM SSL to use a custom domain

📌 Future Improvements

Add CloudWatch monitoring & logging

Add Route 53 + SSL certificate for a custom domain

Extend pipeline with tests before deployment

🏆 Learning Outcome

By completing this project, I learned:

How to use AWS S3 for static hosting

How CloudFront works as a CDN with OAC

How to build a CI/CD pipeline with GitHub Actions

How to automate deployments and cache invalidations

🔗 Keywords: AWS, S3, CloudFront, GitHub Actions, CI/CD, DevOps, Cloud
🚀Github

⚡ Now, every time I push code to GitHub, my website auto-deploys to AWS with CloudFront CDN 🚀

AWS CI/CD Node.js Application using AWS CodePipeline, CodeBuild and CodeDeploy

Ritesh Singh — Tue, 28 Oct 2025 14:57:16 +0000

Welcome to the AWS CI/CD Node.js Application repository! This project showcases a production-ready Node.js application deployed on AWS EC2 using a fully automated CI/CD pipeline with AWS CodePipeline, CodeBuild, and CodeDeploy. Integrated with GitHub for seamless source control, this pipeline automates building and deploying the application.

🚀 Project Overview

This repository hosts a Node.js application (my-app) that serves a "Hello from AWS CI/CD!" message on port 3000. Deployed on an AWS EC2 instance (ip-172-31-19-118), it leverages a robust CI/CD pipeline to demonstrate modern DevOps practices and cloud infrastructure management.

Purpose: Showcase expertise in building, testing, and deploying a Node.js application using AWS services.
Technologies: Node.js, AWS CodePipeline, CodeBuild, CodeDeploy, EC2, GitHub.
Key Achievement: Resolved deployment issues (e.g., ScriptFailed error with EACCES permissions) to achieve a stable, automated pipeline.

🛠️ Features

Node.js Application: Lightweight Express.js server running on port 3000.
Automated CI/CD Pipeline:
- Source: GitHub repository (ritesh/my-aws-cicd-app, main branch).
- Build: AWS CodeBuild generates build-artifact.zip.
- Deploy: AWS CodeDeploy deploys to EC2 (MyAppDeploy, ProductionGroup).
Error Handling: Fixed permissions issues with npm install by optimizing buildspec.yml and install_deps.sh.
Scalability: Ready for scaling with additional EC2 instances or load balancers.
Monitoring: Application logs (app.log) for debugging and verification.

📁 Repository Structure

🛠️ Setup and Deployment

Prerequisites

AWS Account: Permissions for CodePipeline, CodeBuild, CodeDeploy, EC2, and S3.
GitHub Account: Repository ritesh/my-aws-cicd-app with push access.
Node.js: Version 20.19.5 (with npm 10.8.2).

- EC2 Instance: Ubuntu with CodeDeploy agent installed.

Local Setup

Clone the Repository:

   git clone https://github.com/ritesh/my-aws-cicd-app.git
   cd my-aws-cicd-app

Install dependencies:

   npm install

Run Locally::

   node index.js

Access at http://localhost:3000.

AWS CI/CD Pipeline Setup

Step 1: Create the S3 Bucket for Artifacts

aws s3 mb s3://myapp-cicd-artifacts-123 --region us-east-1

how to create s3 bucket CLICK
This bucket stores build-artifact.zip generated by CodeBuild.

Step 2: Launch EC2 Instance & Install CodeDeploy Agent

Launch EC2 (Ubuntu 22.04, t3.micro, us-east-1)
Security Group: Allow inbound:
- SSH (22)
- HTTP (3000)

CLICK-HERE

Install CodeDeploy Agent:

sudo apt update && sudo apt install ruby wget -y
wget https://aws-codedeploy-us-east-1.s3.amazonaws.com/latest/install
chmod +x install
sudo ./install auto
sudo systemctl status codedeploy-agent

Tip: Verify agent is running: sudo systemctl status codedeploy-agent

Step 3: Create IAM Roles

IAM roles are critical for secure communication between AWS services. Below are the four roles created with trust policies and permissions.

1. EC2 Instance Role (`EC2CodeDeployRole`)

Purpose: Allows EC2 to download artifacts from S3 and communicate with CodeDeploy.

Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policies

AmazonS3ReadOnlyAccess → To download build-artifact.zip
AWSCodeDeployRole → For CodeDeploy operations

Attach this role to your EC2 instance via AWS Console → EC2 → Actions → Security → Modify IAM role.

2. CodeBuild Service Role (CodeBuildServiceRole)

Purpose: Allows CodeBuild to read source, write artifacts to S3, and log.

Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "codebuild.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policies

AWSCodeBuildAdminAccess
AmazonS3FullAccess → Required to upload build-artifact.zip to s3://myapp-cicd-artifacts-123

3. CodeDeploy Service Role (CodeDeployServiceRole)

Purpose: Allows CodeDeploy to manage deployments on EC2.

Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "codedeploy.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policy

AWSCodeDeployRole → Predefined AWS managed policy

4. CodePipeline Service Role (CodePipelineServiceRole)

Purpose: Orchestrates Source, Build, and Deploy stages.

Trust Policy


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "codepipeline.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attached Policies

AWSCodePipelineFullAccess
AWSCodeBuildAdminAccess
AWSCodeDeployFullAccess
AmazonS3FullAccess

Step 4: GitHub Repository Setup

git init
git remote add origin https://github.com/ritesh/my-aws-cicd-app.git

.gitignore:

node_modules/
package-lock.json

Why? Prevents EACCES errors by excluding locked files from artifacts.

Step 5: buildspec.yml — Build Configuration

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 18
    commands:
      - npm install
  build:
    commands:
      - echo "Build completed"
      - rm -rf node_modules package-lock.json
artifacts:
  files:
    - appspec.yml
    - index.js
    - package.json
    - scripts/**/*
  discard-paths: no

Critical Fix: rm -rf node_modules package-lock.json avoids permission conflicts.

Step 6: appspec.yml — Deployment Steps

version: 0.1
os: linux
files:
  - source: /
    destination: /home/ubuntu/my-app
hooks:
  AfterInstall:
    - location: scripts/install_deps.sh
      timeout: 300
      runas: ubuntu

Runs install_deps.sh as ubuntu user to avoid root permission issues.

Step 7: scripts/install_deps.sh — Fix Permissions

#!/bin/bash
cd /home/ubuntu/my-app
rm -rf node_modules package-lock.json
npm install --cache /home/ubuntu/.npm --no-audit
chmod -R u+w node_modules package-lock.json 2>/dev/null || true

Key Fixes:

Clears old node_modules
Uses custom npm cache
Fixes write permissions

Step 8: AWS CodeBuild Project (MyAppBuild)

Field	Value
Source	GitHub (`ritesh/my-aws-cicd-app`)
Environment	Ubuntu, Node.js 18
Buildspec	`buildspec.yml`
Artifact	S3 → `myapp-cicd-artifacts-123`
Service Role	`CodeBuildServiceRole`

Step 9: AWS CodeDeploy Application (MyAppDeploy)

Application Name: MyAppDeploy
Compute Platform: EC2/On-Premises
Deployment Group: ProductionGroup
- Tag: Name=MyAppServer
- Instance: ip-172-31-19-118
Service Role: CodeDeployServiceRole

step 10 AWS CodePipeline (`MyAppPipeline`)

Stage	Provider	Configuration
Source	GitHub (v2)	`MyAppGitHubConnection`, `main` branch
Build	CodeBuild	`MyAppBuild`
Deploy	CodeDeploy	`MyAppDeploy`, `ProductionGroup`

🐞 Troubleshooting

Common Issue:

ScriptFailed error (exit code 243) due to EACCES permissions.

Solution:

Ensured buildspec.yml excludes node_modules/ and package-lock.json; install_deps.sh clears residuals and sets permissions.

Logs:

bash sudo tail -n 100 /var/log/aws/codedeploy-agent/codedeploy-agent.log
cat /home/ubuntu/.npm/_logs/*.log

Why This Project Stands Out

DevOps Expertise: End-to-end CI/CD pipeline with AWS services.
Problem-Solving: Resolved complex permissions issues (EACCES on node_modules/.package-lock.json).
Automation: Fully automated deployments with GitHub webhooks.
Clean Code: Well-structured repository with clear configurations.

📬 Contact

👨‍💻 Author

Ritesh Singh

🌐 LinkedIn
|
📝 Hashnode
|
💻GitHub

Feel free to explore, fork, or contribute to this project! 🚀

DevSecOps Pipeline | Jenkins, Terraform, Docker, Trivy, AWS

Ritesh Singh — Sun, 19 Oct 2025 07:10:45 +0000

DevSecOps CI/CD Project

Project goal: Build a full DevSecOps pipeline that builds, scans, pushes and deploys a Flask app using Docker, stores images in AWS ECR, provisions infrastructure with Terraform, configures servers with Ansible, secures pipeline with Trivy & Ansible Vault, and monitors with Prometheus + Grafana. This README documents everything you used and every step needed to reproduce, maintain and secure the workflow.

Project overview & architecture
Folder structure (recommended)
Prerequisites (local & cloud)
Terraform — provision EC2 + IAM + security groups (step-by-step)
Ansible — configure servers & deploy containers (roles & playbooks)
Jenkins pipeline — build, scan, push, deploy (Jenkinsfile)
Security: Trivy, SonarQube (optional), Ansible Vault, Jenkins credentials, IAM least privilege
Monitoring: Prometheus + Grafana + Node Exporter + Jenkins metrics plugin
Correct workflow (step-by-step) + mermaid diagram for workflow image
Troubleshooting & common pitfalls
Useful commands & snippets
Next improvements & checklist

1 — Project overview & architecture

High-level components:

GitHub: source repo (your app + infra + ansible)
Jenkins: CI server (build image, run security scans, push to ECR, trigger Ansible deploy)
Docker: containerize Flask app
AWS ECR: Docker registry for images
Terraform: create EC2 instances, security groups, IAM roles/profiles
Ansible: install runtime components on EC2 and run deploy tasks
Trivy: container image vulnerability scanner integrated in pipeline
Ansible Vault: secrets management for playbooks
Prometheus + Grafana: monitoring & dashboards (Prometheus scrapes Node Exporter + app metrics, Grafana visualizes)
Jenkins Prometheus plugin: optional for Jenkins metrics
Optional: SonarQube for code quality (can be Dockerized or external)

2 — Recommended folder structure

devsecops-pipeline-with-ansible-terraform/
├── app/
│   ├── Dockerfile
│   ├── app.py
│   └── requirements.txt
├── ansible/
│   ├── inventory.ini
│   ├── playbook.yml
│   ├── group_vars/
│   └── roles/
│       ├── flask_app/
│       │   ├── tasks/main.yml
│       │   └── templates/
│       ├── jenkins_setup/
│       └── monitoring/
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   ├── provider.tf
│   └── outputs.tf
├── Jenkinsfile
├── README.md
└── docs/
    └── workflow-mermaid.txt

3 — Prerequisites

Local dev machine (Jenkins host or where you run CI):

Git, Docker, Python3, pip, Ansible, aws-cli v2, Trivy, ngrok (optional)
Jenkins (installed either on a VM/container or as a system package)
Jenkins user added to Docker group: sudo usermod -aG docker jenkins (then restart/relauch session)

AWS:

AWS account with ECR & EC2 ability
An IAM user (for CI) with minimal policies for ECR push (AmazonEC2ContainerRegistryPowerUser or fine-grained)
Key pair (private .pem) you downloaded and will map to Terraform key_name.

Security:

Don’t commit private keys or AWS secrets. Use Jenkins credentials & Ansible Vault.

4 — Terraform: Provision EC2, SG, IAM (step-by-step)

Goals: create three EC2 (flask, jenkins, monitoring) t3.micro (free-tier where available), create security group, IAM role/profile for ECR read/pull.

Basic pieces

Provider.tf

outputs.tf

main.tf

Notes & tips:

Always use key_name that matches an existing EC2 key pair (you create the key in AWS console once and reference its name).
Lock SSH (22) to your IP via CIDR for production safety.
Avoid user_data for complex provisioning if you use Ansible to configure servers — keep Terraform for infra only.

5 — Ansible: configure servers & deploy containers

Inventory (ansible/inventory.ini) example:

[flask_server]
34.238.165.116 ansible_user=ubuntu

[jenkins_server]
18.207.168.154 ansible_user=ubuntu

[monitoring_server]
10.0.1.163 ansible_user=ubuntu

Playbook (ansible/playbook.yml)

---
- hosts: flask_server
  become: yes
  roles:
    - flask_app

- hosts: jenkins_server
  become: yes
  roles:
    - jenkins_setup

- hosts: monitoring_server
  become: yes
  roles:
    - monitoring

Role flask_app/tasks/main.yml (example):
flask_app_role

jenkins_setup role

- name: Install Docker & AWS CLI v2
  apt:
    name: ['docker.io', 'unzip', 'python3-pip']
    update_cache: yes
    state: present

- name: Ensure docker started
  systemd:
    name: docker
    state: started
    enabled: yes

- name: Install AWS CLI v2 (if not present) - script tasks...
- name: Log in to ECR
  shell: |
    aws ecr get-login-password --region {{ aws_region }} | docker login --username AWS --password-stdin {{ ecr_repo_domain }}
  environment: { AWS_ACCESS_KEY_ID: "{{ lookup('env','AWS_ACCESS_KEY_ID') }}" }
  args: { warn: false }
  register: login_result
  failed_when: login_result.rc != 0 and ('Unable to locate credentials' in login_result.stderr == False)

- name: Pull image
  docker_image:
    name: "{{ ecr_repo }}:{{ image_tag }}"
    source: pull

Tips:

Use docker_image module where possible.
For ECR login, run with IAM role (preferred) or provide credentials via env/credentials file on host. If the EC2 has the appropriate IAM instance profile (ECR pull policy), you do not need to store AWS keys on the host.
Use become: yes for system-level tasks.
Avoid referencing local PEM path in inventory.ini — use Jenkins sshagent to provide keys at runtime. Inventory entries should be ansible_user=ubuntu.

6 — Jenkinsfile (CI pipeline — build, scan, push, deploy)

Key points:

Use Jenkins credentials:
- aws-credentials (AWS access key + secret) or use IAM role for Jenkins agent.
- ansible-ec2-key (SSH private key)
Ensure trivy is installed or install in pipeline before using it.

Example Jenkinsfile:

pipeline {
  agent any
  environment {
    AWS_REGION = 'us-east-1'
    ECR_REPO = '772954893641.dkr.ecr.us-east-1.amazonaws.com/flask-app'
    IMAGE_TAG = "build-${BUILD_NUMBER}"
  }
  stages {
    stage('Checkout') { steps { git url: 'https://github.com/ritesh355/devsecops-pipeline-with-ansible-terraform.git', branch:'main' } }
    stage('Install Trivy if needed') {
      steps {
        sh '''
          if ! command -v trivy >/dev/null 2>&1; then
            curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sudo sh -s -- -b /usr/local/bin
          fi
          trivy --version
        '''
      }
    }
    stage('Build') {
      steps { script { sh "docker build -t ${ECR_REPO}:${IMAGE_TAG} ." } }
    }
    stage('Scan') {
      steps {
        sh "trivy image --exit-code 1 --severity HIGH,CRITICAL ${ECR_REPO}:${IMAGE_TAG} || true"
      }
    }
    stage('Push to ECR') {
      steps {
        withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'aws-credentials']]) {
          sh '''
            aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ECR_REPO}
            docker push ${ECR_REPO}:${IMAGE_TAG}
          '''
        }
      }
    }
    stage('Deploy via Ansible') {
      steps {
        sshagent (credentials: ['ansible-ec2-key']) {
          sh '''
           cd ansible
           ansible-playbook -i inventory.ini playbook.yml --limit flask_server -e "image_tag=${IMAGE_TAG}" 
          '''
        }
      }
    }
  }
  post {
    always { cleanWs() }
  }
}

output of CICD pipeline

Notes:

Pass variables image_tag and ecr_repo to Ansible using -e.
Use sshagent Jenkins plugin and SSH credential type for the private key; ensure the credential ID matches.

7 — Security: Trivy, SonarQube, Ansible Vault, IAM best practices

Trivy

Integrate Trivy scan in pipeline. Fail builds for HIGH/CRITICAL if policy requires.
Keep a policy: fail when critical vuln found, allow medium/low with warnings.

SonarQube

Optional code-quality & SAST. Could be run in Jenkins stage. Use Sonarqube scanner plugin.

Ansible Vault

Store sensitive variables (e.g., DB passwords) in group_vars/.../vault.yml encrypted with ansible-vault.

  ansible-playbook -i inventory.ini playbook.yml --ask-vault-pass

Use ansible-vault encrypt_string or ansible-vault create.
In Jenkins, store the vault password in credentials and pass with --vault-password-file or --vault-id securely.

these are the commands which i used

Run playbook with the encrypted inventory file

ansible-playbook -i inventory.ini playbook.yml --ask-vault-pass

Edit the encrypted inventory later

ansible-vault edit inventory.ini

Decrypt if needed

   ansible-vault decrypt inventory.ini

Jenkins credentials

Use Jenkins Credentials store (AWS keys, SSH keys, GitHub token). Never commit secrets.
Use sshagent plugin to make SSH keys available to the build agent for the duration of the block.

IAM roles & policies

Use least-privilege:
- ECR push/pull: AmazonEC2ContainerRegistryPowerUser or custom policy limited to the repo.

EC2 instance profile for servers that will docker pull to fetch images should have ECR read access or use AmazonEC2ContainerRegistryReadOnly.
Prefer instance profiles over hardcoded AWS keys on hosts.

8 — Monitoring: Prometheus + Grafana + Node Exporter + Jenkins plugin

Prometheus

Add scrape targets:
- Node Exporter on EC2 instances: <ec2_private_ip>:9100
- Flask app (if instrumented): <flask_ip>:5000/metrics (use prometheus_flask_exporter)
- Jenkins: metrics_path: '/prometheus' (requires Prometheus plugin)

Grafana

Add Prometheus datasource: URL http://<prometheus_host>:9090
Import dashboards:

Node Exporter Full (ID 1860)

Docker Monitoring → Dashboard ID: 12227

Prometheus 2.0 Stats → Dashboard ID: 3662

Set up Alerting in Grafana

9 — Correct workflow (step-by-step) + diagram

High-level workflow

Developer pushes code to GitHub.
Jenkins job triggers on git push.
Jenkins pulls code, builds Docker image.
Jenkins runs Trivy scan.

If Trivy finds critical issues → fail the build.
1. If scan passes → Jenkins logs in to ECR and pushes the image with tag (build-N).
2. Jenkins calls Ansible (via sshagent) passing image_tag.
3. Ansible logs into target EC2 (using Ansible role with proper IAM or ECR login) and pulls the pushed image, stops old container and spins up a new one (docker run).
4. Prometheus scrapes Node Exporter and application metrics; Grafana visualizes and triggers alerts.

10 — Troubleshooting & common pitfalls

Ansible SSH fails: make sure Jenkins loads private key via sshagent and inventory does NOT hardcode ansible_ssh_private_key_file pointing to a path that doesn’t exist on Jenkins agent. Use ansible_user=ubuntu in inventory and sshagent to supply key.
ECR login failing: ensure Jenkins has AWS credentials or EC2 instance running Ansible has IAM instance profile for ECR. Also use aws ecr get-login-password | docker login.
Docker permission denied: ensure Jenkins user in docker group or run docker commands via sudo; prefer adding user to group and restarting session.
Prometheus YAML errors: YAML is whitespace-sensitive. Use 2-space indentation and validate with docker run --rm -v /path/prom.yml:/etc/prometheus/prometheus.yml prom/prometheus --config.file=/etc/prometheus/prometheus.yml to see parse errors.
Prometheus target 404: target reachable but wrong path. For Jenkins use /prometheus (plugin). For Node Exporter use /metrics on port 9100.
Trivy not found in Jenkins: install Trivy system-wide or add an Install Trivy stage in Jenkinsfile.
Ansible variable recursion: always pass required variables (image_tag, ecr_repo) from pipeline into Ansible (-e "image_tag=${IMAGE_TAG} ecr_repo=${ECR_REPO}").

11 — Useful commands & snippets

Docker run Prometheus (host-mounted config):

docker run -d --name prometheus -p 9090:9090 -v /home/ubuntu/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

Start Node Exporter:

docker run -d --name node_exporter -p 9100:9100 prom/node-exporter

ECR login & push (shell):

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 772954893641.dkr.ecr.us-east-1.amazonaws.com
docker tag local-image:latest 772954893641.dkr.ecr.us-east-1.amazonaws.com/flask-app:build-1
docker push 772954893641.dkr.ecr.us-east-1.amazonaws.com/flask-app:build-1

Ansible run (manual):

ansible-playbook -i ansible/inventory.ini ansible/playbook.yml --limit flask_server -e "image_tag=build-1"

Validate Prometheus yaml (debug):

docker run --rm -v /home/ubuntu/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus --config.file=/etc/prometheus/prometheus.yml --log.level=debug

Final notes & tips

Don’t store secrets in repo. Use Jenkins credentials and Ansible Vault.
Use IAM roles for EC2 instances that need to pull images from ECR — avoids storing keys on servers.
Test individual steps locally first (Docker build & run, Ansible tasks to install Docker & pull image).
Keep your prometheus.yml simple and validate YAML syntax when editing.

👨‍💻 Author

Ritesh Singh

🌐 LinkedIn

📝 Hashnode

💻GitHub

🌐 LinkedIn

DevOps project: 🚀 Jenkins CI/CD Pipeline with Docker & Node.js

Ritesh Singh — Mon, 06 Oct 2025 14:01:07 +0000

🚀 Jenkins CI/CD Pipeline with Docker & Node.js

This project demonstrates a Jenkins CI/CD pipeline running on AWS EC2, which builds and deploys a simple Node.js app inside a Docker container, and pushes the image to Docker Hub.

📌 Features

Node.js sample app (Hello from Jenkins CI/CD + Docker + Node.js!)
Jenkins pipeline using Jenkinsfile
Automated build & deployment with Docker
Push Docker images to Docker Hub
GitHub Webhook integration for auto builds

🛠️ Tech Stack

Node.js – Application
Docker – Containerization
Jenkins – CI/CD pipeline
AWS EC2 – Jenkins & Docker host
Docker Hub – Image registry
GitHub – Source code repository

First Setting Up Jenkins on an AWS EC2 Instance

This guide provides step-by-step instructions to launch an AWS EC2 instance, install Jenkins, and access the Jenkins server. Follow these steps to set up a Jenkins server using Amazon Linux 2 on a t2.micro instance.

Prerequisites

An AWS account with appropriate permissions.
Basic knowledge of SSH and terminal commands.
A web browser to access the Jenkins dashboard.

Step 1: Log in to an AWS Account

Navigate to the AWS Management Console.
Log in with your AWS credentials (username, password, and MFA if enabled).
In the AWS Console, locate the EC2 service under the "Compute" section or use the search bar to find "EC2."
Click EC2 to access the EC2 Dashboard.

Step 2: Navigate to EC2 Dashboard

In the EC2 Dashboard, select Instances from the left-hand menu.
Click Launch instances to start creating a new EC2 instance. 3.

Step 3: Launch Instance

In the "Launch an instance" wizard, configure the following:
- Name: Enter my_jenkins_server.
- Number of instances: Set to 1.
- Amazon Machine Image (AMI): Choose Amazon Linux 2 AMI (HVM), SSD Volume Type (select the latest version available in your region).
- Architecture: Select 64-bit (x86).
Proceed to configure instance details.

Step 4: Configure Instance

Instance Type: Select t2.micro (Free Tier eligible, 1 vCPU, 1 GiB memory).
Key Pair:
- If you have an existing key pair, select it from the dropdown.
- If not, click Create new key pair, name it (e.g., jenkins-key), choose RSA and .pem format, and download the key pair. Store it securely.
Leave default settings for storage unless specific requirements exist.
Proceed to configure network settings.

Step 5: Configure Network Security Groups

In the Network settings section:
- Choose Create security group or select an existing one.
- Add the following inbound rules:
  - Type: HTTP, Protocol: TCP, Port Range: 8080, Source: Anywhere (0.0.0.0/0) for Jenkins web access.
  - Type: SSH, Protocol: TCP, Port Range: 22, Source: Your IP or Anywhere (0.0.0.0/0) for SSH access.
- Security Note: Allowing all traffic (0.0.0.0/0) for all ports is insecure. For production, restrict SSH to your IP and limit other traffic.
Ensure port 8080 (Jenkins) and port 22 (SSH) are open.

Step 6: Review and Launch Instance

Review the configuration (instance type, AMI, key pair, security group).
Click Launch instance to provision the instance.
Note the instance ID from the confirmation message.

Step 7: Connect to EC2 Instance

In the EC2 Dashboard, go to Instances and wait for the instance to reach the Running state (verify "Status Checks" pass).
Select the instance (my_jenkins_server) and click Connect.

In the Connect to instance window, select the SSH client tab.

Use the provided SSH command, e.g.:

   ssh -i "jenkins-key.pem" ec2-user@<Public_IP_or_DNS>

Replace with the instance’s public IP or DNS (found in instance details).
Ensure the .pem file permissions are restricted:

Step 8: Install Jenkins

Connect to the instance via SSH, then run:

Update

sudo apt update -y

Install Java (Jenkins needs Java)

sudo apt install openjdk-17-jdk -y

Add Jenkins repository

curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

- Install Jenkins
sudo apt update -y
sudo apt install jenkins -y

Start Jenkins

sudo systemctl start jenkins
sudo systemctl enable jenkins

👉 Jenkins runs on http://:8080

Step 9: Configure Jenkins

Open browser → http://:8080

Get initial password:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Paste password in Jenkins UI.
Install suggested plugins.

Create admin user.

instance configuration

jenkins is ready now

Step 5: Install Docker on EC2

sudo apt install docker.io -y

👉 Restart Jenkins so it can use Docker:

sudo usermod -aG docker jenkins
sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl restart jenkins

## Create a GitHub Repository
### Folder structure

Docker-Jenkins-app/
│-- app.js
│-- package.json
│-- Dockerfile
│-- Jenkinsfile
│-- README.md

Configure Jenkins Pipeline

Push your Docker-Jenkins-app repo to GitHub.
In Jenkins UI:
- New Item → Name: docker-pipeline-ec2 → Select Pipeline

In Pipeline → Select Pipeline script from SCM

SCM: Git
Repo URL: https://github.com/ritesh355/Docker-Jenkins-app.git
Branch: main

Setup GitHub Webhook

Go to your repo → Settings → Webhooks → Add webhook.

Payload URL:

http://<EC2-Public-IP>:8080/github-webhook/

Content type: application/json
Event: Just the push event

save

Add Docker Hub Credentials in Jenkins

Open Jenkins Dashboard → Manage Jenkins → Credentials.

Click System → Global credentials (unrestricted) → Add Credentials.

Select Kind = Username with password.

Username = Your Docker Hub username
- Password = Your Docker Hub password or personal access token how to create docker hub tokens

ID = dockerhub-creds (you will use this ID in Jenkinsfile)
Description = Docker Hub Credentials

Test

Commit & push a small change to your repo (e.g., update app.js message).
GitHub → Sends webhook → Jenkins job auto-triggers.
Jenkins builds Docker image + runs container on EC2 And push the image into the docker hub

Access app at:

http://<EC2-Public-IP>:4000

✅ Now you’ll have a fully automated CI/CD pipeline on EC2 with webhooks.

📢 Follow My Journey

github

linkdin

DevOps project:Mounting an EBS Volume on EC2

Ritesh Singh — Fri, 03 Oct 2025 11:06:44 +0000

How to Attach and Mount Extra EBS Volume to Linux EC2 in AWS | Mounting EBS Volume

🎯 Objective

Learn how to attach, mount, and use an EBS volume with an EC2 instance for persistent storage in AWS.

🛠️ AWS Services Used

EC2 (Elastic Compute Cloud): Instance to attach volume
EBS (Elastic Block Store): Persistent block storage
IAM: Proper permissions for EC2 access

📋 Steps

1. Create an EBS Volume

Go to AWS Console → EC2 → Elastic Block Store → Volumes → Create Volume
Choose Volume type (e.g., General Purpose SSD gp3)
Set Size (e.g., 1 GB for testing)
Select the same Availability Zone as your EC2 instance
Click Create Volume

2. Attach Volume to EC2

firstly launce an ec2 instance in same availability zone

Select the volume → Actions → Attach Volume
Choose the EC2 instance
Click Attach

3. Connect to EC2 & Mount Volume

SSH into your EC2 instance:

ssh -i mykey.pem ec2-user@<EC2-Public-IP>

2 . After ssh switch into root user

sudo su -

3 . use command

df -h

4 . Format the Volume (if needed)

Check if filesystem exists:

sudo file -s /dev/nvme1n1

If output shows data, format it:

sudo mkfs -t ext4 /dev/nvme1n1

Note —> replace with your disk name like /dev/xvdf in my case it is not xvdf it is nvme1n1

4. Mount the Volume

Create a mount point:

sudo mkdir /mnt/myvolume

Mount it:

sudo mount /dev/nvme1n1 /mnt/myvolume

Verify:

    df -h

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759419506610/7160c0f9-5438-429f-8f06-4e43d488d0ae.png )

## 🌐 Connect With Me

💻 GitHub: ritesh355
📝 Blog: ritesh-devops.hashnode.dev
💼 LinkedIn: Ritesh Singh

🚀 Building & Deploying My Next.js Portfolio with Docker, AWS, CI/CD and monitoring with Promithius and Grafana"

Ritesh Singh — Mon, 22 Sep 2025 16:03:17 +0000

🚀 Next.js Portfolio – DevOps Ready

This is Personal Portfolio Project built with Next.js, containerized using Docker, deployed on AWS EC2 (Free Tier), and distributed globally via AWS CloudFront CDN.

The deployment pipeline is fully automated using GitHub Actions (CI/CD) — from building the Docker image to pushing it to Docker Hub and deploying it on EC2.

For performance and container health monitoring, the project integrates a Monitoring Stack using Prometheus, Grafana, and cAdvisor, all connected through a shared Docker network.

It demonstrates both frontend skills (React/Next.js) and DevOps practices (CI/CD, Docker, DockerHub ,aws ,cloudfront, promithius and grafana).

⚡ Workflow

DevOps Workflow

📸 Screenshots

about

skills

✨ Features

⚛️ Modern portfolio built with Next.js (SSR + React 18).
📱 Responsive design for desktop & mobile.
🐳 Fully Dockerized (multi-stage build, production optimized).
☁️ Deployed on AWS EC2 Free Tier.
🔄 Automated CI/CD pipeline with GitHub Actions:
- Runs tests (npm run build).
- Builds and pushes Docker image to DockerHub.
- SSH into EC2 and redeploys automatically.
📜 .

🛠️ Tech Stack

Frontend: Next.js, React, Tailwind CSS
Containerization: Docker, DockerHub
CI/CD: GitHub Actions
Cloud: AWS EC2 (Ubuntu 22.04, Free Tier)
IaC: Terraform

📂 Project Structure

💻 Run Locally

Clone the repo:

git clone git@github.com:ritesh355/portfolio.git
cd portfolio

Install dependencies:

npm install

Run dev server:

npm run dev

then visit http://localhost:3000

📦 Docker Setup

Build the image:

docker build -t ritesh355/nextjs-portfolio:latest .

run the container:

docker run -d -p 3000:3000 ritesh355/nextjs-portfolio:latest

then visit http://localhost:3000

☁️ Deployment on AWS EC2

1.Launch Ubuntu EC2 Free Tier.

2.after connetint that ec2 Install Docker:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker ubuntu

Pull and run image:

  docker pull ritesh355/nextjs-portfolio:latest
docker run -d -p 80:3000 ritesh355/nextjs-portfolio:latest

4.Visit http://EC2-Public-IP

🤖 GitHub Actions CI/CD

Located in .github/workflows/main.yml:

Runs tests (npm run build).
Builds & pushes image to DockerHub.
SSH into EC2, pulls new image, restarts container.

Example Workflow

name: Build, Push & Deploy with Rollback

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
    # 1. Checkout repo
    - name: Checkout code
      uses: actions/checkout@v3

    # 2. Setup Node.js
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    # 3. Install dependencies
    - name: Install dependencies
      run: npm install --legacy-peer-deps

    # 4. Run build
    - name: Build project
      run: npm run build

    # 5. Log in to Docker Hub
    - name: Log in to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    # 6. Build Docker image
    - name: Build Docker image
      run: |
        docker build -t ritesh355/nextjs-portfolio:latest \
                     -t ritesh355/nextjs-portfolio:v1 \
                     -t ritesh355/nextjs-portfolio:v1.0.0 .

    # 7. Push Docker image
    - name: Push Docker image
      run: |
        docker push ritesh355/nextjs-portfolio:latest
        docker push ritesh355/nextjs-portfolio:v1
        docker push ritesh355/nextjs-portfolio:v1.0.0

    # 8. Deploy to EC2 with rollback
    - name: Deploy to EC2
      uses: appleboy/ssh-action@v0.1.9
      with:
        host: ${{ secrets.EC2_HOST }}
        username: ${{ secrets.EC2_USER }}
        key: ${{ secrets.EC2_SSH_KEY }}
        script: |
          echo "Pulling latest Docker image..."
          docker pull ritesh355/nextjs-portfolio:latest

          # Backup old container if exists
          if docker ps -a --format '{{.Names}}' | grep -Eq "^nextjs-portfolio\$"; then
            echo "Backing up current container..."
            docker rename nextjs-portfolio nextjs-portfolio-backup
          fi

          # Run new container
          echo "Starting new container..."
          docker run -d --name nextjs-portfolio -p 80:3000 ritesh355/nextjs-portfolio:latest

          # Check if container is running
          sleep 5
          if ! docker ps --format '{{.Names}}' | grep -Eq "^nextjs-portfolio\$"; then
            echo "New container failed! Rolling back..."
            docker rm nextjs-portfolio || true
            docker rename nextjs-portfolio-backup nextjs-portfolio || true
            docker start nextjs-portfolio || true
          else
            echo "Deployment successful! Removing backup..."
            docker rm -f nextjs-portfolio-backup || true
          fi

📊 Monitoring Stack

To monitor the Next.js portfolio container, I implemented a full container monitoring setup using Prometheus, Grafana, and cAdvisor.

Steps Implemented

Run cAdvisor container to collect metrics:

docker run -d \
  --name=cadvisor \
  --network=monitoring \
  -p 8080:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:v0.47.2

Run Prometheus container with cAdvisor target:

docker run -d \
  --name=prometheus \
  --network=monitoring \
  -p 9090:9090 \
  -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

Prometheus configuration (/etc/prometheus/prometheus.yml):

global:
  scrape_interval: 5s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

Run Grafana container

docker run -d \
  --name=grafana \
  --network=monitoring \
  -p 3001:3000 \
  grafana/grafana

👨‍💻 Author

Ritesh Singh

🌐 LinkedIn |
📝 Hashnode |
💻GitHub

⚡ Built with ❤️ using Next.js + Docker + AWS + DevOps

DEV Community: Ritesh Singh

🚀 AWS Multi-Region Disaster Recovery Architecture (Production-Grade)

📌 Overview

This project simulates how enterprise systems survive regional outages.

🏗️ Architecture Diagram

🔧 Architecture Components

📂 Implementation Details

Step 1: EC2 & AMI Setup (Primary Region)

Objective

Why This Step?

Services Used

Implementation Steps

1️⃣ Launch EC2

- HTTP (80)

2️⃣ Install Application

Verify Application

Create AMI

OUTCOME

Step 2: ALB & Auto Scaling Setup

Objective

Why This Step?

Services Used

Implementation Steps

1️⃣ Create Target Group

2️⃣ Create Application Load Balancer

3️⃣ Create Launch Template

4️⃣ Create Auto Scaling Group

Outcome

Step 3: Route 53 Failover Routing

Objective

Why This Step?

Services Used

Implementation Steps

1️⃣ Create Hosted Zone

2️⃣ Create Health Check

3️⃣ Create DNS Records

Primary Record

Secondary Record

Outcome

Step 4: RDS Disaster Recover

Objective

Why This Step?

Services Used

Implementation Steps

1️⃣ Create Primary RDS

2️⃣ Create Read Replica

3️⃣ Promote Replica (DR Test)

Outcome

🎯 Key Objectives

🛠️ AWS Services Used

🌍 Regions Used

📁 Project Structure

🔄 Disaster Recovery Flow

🧪 Failure Scenarios Tested

➡ Result: Application remained accessible via the DR region

📊 RTO & RPO (Design Targets)

💡 Why This Project Stands Out

🧠 Key Learnings

🚀 Future Enhancements

📣 About the Author

⭐ For Recruiters

🔥 10+ End-to-End DevOps Projects — Docker, AWS, Jenkins, Terraform, Ansible & More

🚀 My Complete DevOps Projects Collection – From Beginner to Advanced (All in One Place)

🎯 Why I Created This Repository

📂 What’s Inside This Repository?

🧩 Project Overview

📁 PROJECT-1 — Dockerized Flask App PROJECT-1

📁 PROJECT-2 — Node.js + MongoDB App with Docker Compose PROJECT-2

📁 PROJECT-3 — Jenkins CI/CD Pipeline with Docker & Node.js PROJECT-3

📁 PROJECT-4 — AWS CI/CD Pipeline (Node.js → EC2) PROJECT-4

📁 PROJECT-5 — CI/CD Pipeline for Web App PROJECT-5

📁 PROJECT-6 — Static Website Hosting (S3 + CloudFront + CI/CD)PROJECT-6

📁 PROJECT-7 — Flask + AWS DynamoDB CRUD App PROJECT-7

📁 PROJECT-8 — Serverless CI/CD Pipeline PROJECT-8

📁 PROJECT-9 — Full-Stack DevOps AutomationPROJECT-9

📁 PROJECT-10 — DevSecOps PipelinePROJECT-10

🛠 Tech Stack Covered (So Far)

CI/CD

Containerization

Cloud