DEV Community: muhirwaJD

Snapshots

muhirwaJD — Wed, 02 Jul 2025 09:59:24 +0000

🔁 RDS Snapshot Replication Across AWS Regions

🧠 Inspiration

In real-world applications, ensuring disaster recovery and high availability across regions is a top priority. I wanted to explore how Amazon RDS Snapshots can be used to replicate database state across AWS regions, and how to do it completely using CLI and infrastructure best practices.

🛠 What I Built

I built a working solution that:

Creates a manual snapshot of a running RDS MySQL instance
Copies that snapshot securely to another AWS region using CLI
Restores the snapshot as a brand-new RDS instance in the target region
Configures EC2 to securely connect to the restored DB instance for verification

This project mimics real-world cross-region disaster recovery, entirely using AWS CLI and IAM best practices.

🧩 How It Works

✅ RDS Snapshot: I initiated a manual snapshot of my running MySQL database in eu-west-1.
🔐 Cross-Region Copy: I securely copied the snapshot to us-east-1, providing the right KMS key and permissions.
🔁 Restoration: The snapshot was restored as a new database in the destination region.
🔓 Security Group Linking: I configured the database's SG to only allow port 3306 from my EC2 instance — a critical security and connectivity setup.
🔌 Testing: I used EC2 to connect to the new database using MySQL CLI and verified everything worked.

🔍 Challenges I Faced

❌ Cross-region encryption: Required specifying a new KMS key.
⛔ IAM Denial: A Service Control Policy (SCP) was explicitly denying the snapshot copy action.
⚠️ Connectivity issues: Even with "All traffic" allowed, the DB was unreachable until I restricted access only to port 3306.
🔐 Understanding SSH & IAM policies: Took time to troubleshoot security-related errors cleanly.

✅ What I Learned

How RDS snapshots and cross-region copy logic works in detail
How to set up secure security groups for EC2-to-RDS communication
How to debug common AWS CLI and IAM permission errors
Importance of precise permissions over broad “Allow all” settings

💻 Tech Stack

Amazon RDS (MySQL)
AWS CLI
EC2 (Ubuntu)
IAM, KMS, VPC, SG
Linux terminal & MySQL client

📈 What's Next?

🧠 Automate the snapshot + copy process using AWS Lambda
🧪 Add a backup validation pipeline for real-world DR simulation
📦 Set up CloudWatch Alarms to monitor cross-region syncs

GitHub - muhirwaJD/snapshot-replication

Terraform, Ansible and Jenkins

muhirwaJD — Wed, 02 Jul 2025 09:54:52 +0000

AutoJenkins: CI/CD Deployment with Terraform & Ansible on AWS

🌍 Website / Demo

http://YOUR_EC2_PUBLIC_IP:8080 (replace with real IP)

📌 Short Description

We automated the full deployment of Jenkins on AWS using Infrastructure as Code (IaC) with Terraform and Ansible. In just one command, an EC2 instance is created, secured, configured with SSH, and provisioned with a fully working Jenkins CI server — without ever logging into the instance.

💡 Inspiration

Manually launching cloud infrastructure and setting up CI/CD tools is time-consuming and error-prone. We wanted a fully automated, repeatable solution that reflects real-world DevOps practices, using industry-standard tools like Terraform and Ansible.

🔧 What It Does

Terraform provisions:
- A new AWS EC2 Ubuntu instance
- A security group with SSH & Jenkins ports open
- An SSH key for secure access
Ansible configures the instance by:
- Installing OpenJDK 17
- Adding the Jenkins APT repo & GPG key
- Installing Jenkins
- Ensuring the Jenkins service is enabled and running

🧠 How We Built It

Used Terraform to define infrastructure as code in main.tf
Used Ansible to define the configuration in playbook.yaml
Automatically passed the EC2 public IP from Terraform to Ansible

Ran everything from a single terminal with:

terraform apply -auto-approve
ansible-playbook -i inventory playbook.yaml

Debugged service failures by parsing logs with Ansible (not SSH)

🧩 Challenges We Ran Into

Jenkins failed to start with Java 11. We read logs via journalctl using Ansible and discovered Jenkins now requires Java 17+
EC2 SSH keys had to be managed properly to avoid permission errors
Jenkins port (8080) had to be opened in the security group

✅ Accomplishments We're Proud Of

Zero SSH login required throughout the project
Clean separation of infrastructure (Terraform) and config (Ansible)
Used proper logging and error handling via Ansible
Debugged systemd failures using journalctl inside playbooks

🚀 What’s Next

Add DNS and HTTPS (via Route 53 + Let’s Encrypt)
Integrate GitHub Webhooks to trigger Jenkins jobs automatically
Use S3 and CloudWatch for backups and monitoring

📚 Built With

☁️ AWS EC2
🧱 Terraform
⚙️ Ansible
🐧 Ubuntu 22.04
💻 Jenkins

👥 Team

Muhirwa — DevOps Engineer & Builder

GitHub - muhirwaJD/Terraform-and-Ansible

Cloudwatch Monitoring

muhirwaJD — Wed, 02 Jul 2025 09:11:17 +0000

🛠️ Node.js Logging to CloudWatch from Dockerized EC2 App

🧩 Project Overview

In this project, I built a lightweight Node.js web server using Morgan middleware to log HTTP requests. I deployed it on an EC2 instance, containerized the app with Docker, and then configured AWS CloudWatch to stream logs both from a file (for traditional deployment) and directly from Docker (for container-based monitoring).

This dual setup gave me deep visibility into application traffic using two popular logging strategies—and helped me better understand how to monitor apps in cloud-native environments.

🚀 What I Built

✅ A Node.js app with HTTP request logging using Morgan
✅ Dockerized version of the app using a custom Dockerfile
✅ Deployed on an Ubuntu EC2 instance
✅ Implemented two types of logging to CloudWatch:
- File-based logging with CloudWatch Agent (for non-containerized apps)
- Docker log driver for real-time streaming (for containerized apps)

💡 Why This Matters

Logging is critical for:

📈 Monitoring traffic and diagnosing issues
🔒 Ensuring app health and security
🔍 Auditing activity for compliance or troubleshooting

This project taught me:

How to configure IAM roles securely for EC2 and CloudWatch
How to write logs to both file and console for hybrid observability
How to use Docker's native log drivers to stream data to AWS CloudWatch
The differences and use cases between classic agent-based logging vs container-native logging

🧠 Key Learnings

Docker logs can be streamed directly to CloudWatch without writing to disk
Morgan allows dual streaming (file + console), which is perfect for hybrid setups
CloudWatch Agent requires precise file paths and log group names to function
IAM roles must be attached to EC2 instances with the correct policies (CloudWatchAgentServerPolicy, AmazonSSMManagedInstanceCore)
Real-time log monitoring helps identify traffic patterns and potential issues instantly

🛠️ Tech Stack

Node.js
Express / Morgan middleware
Docker
AWS EC2 (Ubuntu)
AWS CloudWatch Logs
AWS IAM Roles
CloudWatch Agent

🔍 How to Try It Yourself

Clone the Node.js app with Morgan logging
Build the Docker image and run it
Either:
- Use CloudWatch Agent to stream from a file, or
- Use Docker's awslogs driver for direct streaming
Monitor traffic logs in CloudWatch in real time!

📸 Screenshots

Terminal output

CloudWatch Log Group + Stream

Note: You'll see the IPs hidden ofc. Sorry hackers, these IPs are not for you 🙃