Md Masud Rana’s Post

🔧 Lab Title: 9 - Deploy to EC2 server from Jenkins Pipeline - CI/CD Part 2 ☁️🐳 Project Steps PDF Your Easy-to-Follow Guide :https://lnkd.in/gvnEqDBH 🔗 GitLab Repo Code:https:https://lnkd.in/g-uhEZyw 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I automated multi-container deployments using Jenkins, Docker Compose, and AWS EC2. I built a CI/CD pipeline that leverages parameterized environment variables for dynamic Docker image deployment, allowing flexible and repeatable builds. The pipeline used Jenkins Shared Libraries and secure SSH scripts to deploy a Java Maven app and PostgreSQL database to EC2. Tools Used:  🔧 Jenkins: Orchestrated CI/CD with parameterized pipelines.  🐳 Docker & Docker Compose: Built images & deployed multi-container apps.  ☁️ AWS EC2: Hosted deployed containers securely.  📦 Maven: Built Java apps inside Jenkins. Skills Gained:  ✅ Dynamic Deployments: Used env vars in Docker Compose for flexible configurations.  ✅ Modular Pipelines: Implemented Jenkins Shared Libraries for DRY automation.  ✅ Secure Remote Ops: Automated EC2 deployments via SSH and Jenkins agents. Challenges Faced:  🔐 Remote File Transfers: Fixed SCP permission issues by adjusting SSH key configs.  ⚙ Service Coordination: Resolved container startup order with Docker Compose dependencies. Why It Matters:  This lab proves how modern DevOps pipelines can deploy full-stack apps (Java + Postgres) dynamically. Mastering Jenkins, Docker Compose, and EC2 automation is vital for scaling microservices and enabling efficient infrastructure management in real-world production. 📌 hashtag#DevOps hashtag#Jenkins hashtag#DockerCompose hashtag#AWS hashtag#CI_CD hashtag#Automation hashtag#CloudNative hashtag#TechLearning 🚀 Stay tuned!  Next up: Project 10 - Deploy to EC2 server from Jenkins Pipeline - CI/CD Part 3 🔥

🚀 Built a Production-Ready Terraform Project on AWS (Real DevOps Implementation) As part of strengthening my DevOps expertise, I designed and deployed a modular Terraform project to provision AWS infrastructure — following real-world practices used in organizations. Instead of writing everything in a single file, I implemented a scalable and reusable architecture using Terraform modules 👇 🏗️ What I built: ✔️ VPC with public subnet ✔️ Internet Gateway & Route Table configuration ✔️ Security Group (SSH & HTTP access) ✔️ EC2 instance deployment 📁 Project Approach (Industry-Level): 🔹 Separate modules for VPC and EC2 🔹 Environment-based structure (dev) 🔹 Clean and maintainable code design 💡 Real Challenges I Solved (Hands-on Debugging): 🔸 Fixed invalid AMI issue (region-specific problem) 🔸 Resolved instance type restriction (Free Tier eligibility) 🔸 Handled Git large file error by cleaning .terraform and using .gitignore 👉 These are the exact issues you face in real production environments. 📌 Key Learnings: ✔ Modular Terraform = scalable infrastructure ✔ Proper Git practices are critical in DevOps ✔ Debugging skills matter more than just writing code 🔗 GitHub Project Link: https://lnkd.in/d4JKWgGE #DevOps #Terraform #AWS #InfrastructureAsCode #CloudEngineering #SRE #GitHub #LearningInPublic

𝗣𝗵𝗮𝘀𝗲 𝟮 𝗶𝘀 𝗱𝗼𝗻𝗲. 𝗠𝘆 𝗘𝗖𝗦 𝗙𝗮𝗿𝗴𝗮𝘁𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗹𝗶𝘃𝗲. 𝐖𝐡𝐚𝐭 𝐈 𝐛𝐮𝐢𝐥𝐭: → ECS cluster with Container Insights for real-time metrics (CloudWatch) → Application Load Balancer in public subnets, listening on HTTP → Target group with health checks routing to my tasks → 2 ECS tasks running nginx in private subnets, auto-registered to the target group → IAM execution role scoped to pull images and write logs → CloudWatch log group capturing container output 𝐖𝐡𝐚𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐰𝐞𝐧𝐭 𝐰𝐫𝐨𝐧𝐠 (𝐭𝐡𝐞 𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠): The biggest lesson today: read your terraform plan before applying. I changed app_port from 8080 to 80, which forced the target group to be replaced. Terraform wanted to destroy the old one first, but the listener was still using it so you can't destroy a resource that's referenced. It failed mid-apply. The fix: use `name_prefix` instead of fixed names, plus `lifecycle { create_before_destroy = true }`. Now Terraform creates the new target group first (with a random suffix), swaps the listener to it, then safely destroys the old one. Zero-downtime replacement. All Terraform code, all reproducible. 𝐍𝐞𝐱𝐭: 𝐏𝐡𝐚𝐬𝐞 𝟑 𝐢𝐬 𝐑𝐃𝐒. 𝐓𝐡𝐞 𝐝𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐥𝐚𝐲𝐞𝐫. https://lnkd.in/e4szupXp #AWS #ECS #Terraform #DevOps #CloudEngineering

🚀 CI/CD Pipeline for Automated Portfolio Deployment (GitHub Actions + AWS S3) I built and implemented a CI/CD pipeline to automate the deployment of my personal portfolio website. With every push to my GitHub repository, a GitHub Actions workflow automatically builds and deploys the latest changes to an AWS S3 bucket hosting my static website. ⚙️ Tech Stack: GitHub Actions | AWS S3 | IAM Roles | GitHub Secrets | HTML/CSS/JavaScript 📌 What I Demonstrated: • CI/CD pipeline automation using GitHub Actions • AWS S3 static website hosting & deployment • Secure credential management using IAM & GitHub Secrets • End-to-end DevOps workflow understanding 🎯 Impact: This project helped me gain hands-on experience in building real-world deployment pipelines and strengthened my understanding of DevOps automation on AWS. I am continuously improving my skills in AWS, DevOps, and Infrastructure Automation. 🔗 Project Repository: https://lnkd.in/gMdFK-mq 👨💻 GitHub Profile: https://lnkd.in/gqG_G7Me ⭐ Feel free to follow my GitHub for more DevOps & cloud projects — more coming soon! #DevOps #AWS #GitHubActions #CICD #CloudComputing #AWSDevOps #Automation

🚀 New Project: Multi-Environment Terraform Deployment with GitLab CI/CD One thing every DevOps engineer encounters early on: how do you manage dev, staging, and prod infrastructure without duplicating code or risking state conflicts? Here's what I built to solve exactly that What the project does: A fully automated IaC pipeline that provisions isolated AWS environments (develop + prod) from a single Terraform codebase, triggered automatically by GitLab CI/CD on every push. How it works: → Push to develop → pipeline runs → staging EC2 deployed (manual approval required) → Merge to main → pipeline runs → prod EC2 deployed (automatic) → Each environment gets its own isolated Terraform state in S3 → State locking prevents concurrent pipeline runs from corrupting infrastructure Stack: • Terraform Workspaces: one codebase, multiple isolated environments • AWS S3: remote backend for shared, versioned state storage • GitLab CI/CD: 3-stage pipeline: validate → plan → apply • AWS EC2 + Security Groups: environment-tagged resources • IAM: least-privilege service account for the pipeline Key lessons learned: • TF_WORKSPACE is a reserved Terraform variable, naming your CI variable the same breaks workspace selection silently (fun one to debug 🙃) • GitLab Protected variables are only injected into protected branches, unprotect them if your pipeline runs on feature/develop branches • Terraform 1.10+ native S3 locking (use_lockfile) replaces the DynamoDB dependency, simpler and cleaner • Manual approval gates in CI aren't just a safety net, they're standard practice in real teams Why this matters for interviews: Remote state, workspace isolation, and branch-based deployment strategies are questions I now get asked about, and can answer from real hands-on experience, not just theory. Full project with README guide on GitHub: https://lnkd.in/dgNT_NTe #DevOps #Terraform #GitLabCI #AWS #InfrastructureAsCode #CloudEngineering #IaC #Berlin #OpenToWork

From zero to a production-grade Kubernetes platform on AWS, built in a single day. I recently completed an end-to-end cloud infrastructure project where the goal wasn’t just to deploy an application, but to design and operate it the way a real production system would be built. Starting from a containerised stack (React, Flask, PostgreSQL), I provisioned and deployed a highly available, secure, and fully automated platform using Infrastructure as Code and GitOps principles. Key components of the system: • Multi-AZ AWS infrastructure provisioned with Terraform (VPC, segmented subnets, per-AZ NAT Gateways, Route53 DNS) • Private Kubernetes cluster built with Kops (3 control plane nodes and 3 worker nodes across availability zones, no public node exposure) • Application workloads deployed with proper scaling, health checks, and persistent storage (PostgreSQL on encrypted EBS, replicated API and frontend layers) • TLS and ingress management using NGINX Ingress Controller with cert-manager (automated certificate issuance and renewal) • Network segmentation using Calico with explicit NetworkPolicies (default deny with controlled service-to-service communication) • GitOps workflow implemented with ArgoCD (automated reconciliation, self-healing, and elimination of configuration drift) • Security best practices applied across layers (non-root containers, encrypted storage, IAM least privilege, no secrets in source control) What made this project valuable was not the individual tools, but the system design decisions: – Designing for high availability across availability zones – Enforcing private networking as a default – Treating Git as the single source of truth for deployments – Building with security and immutability from the start A few practical lessons reinforced along the way: • DNS delegation and propagation can become a critical path if not handled early • Running workloads as non-root affects service design and port management • GitOps significantly reduces operational overhead and configuration drift • Separating infrastructure and application concerns improves maintainability The platform is live: 🌐 https://lnkd.in/eQnDYmyY 🔎 https://lnkd.in/ez37P225 This project reflects how I approach cloud infrastructure: reliable by design, secure by default, and fully automated. Open to connecting with teams working on cloud-native platforms, DevOps, or infrastructure engineering.

Building a Scalable CI/CD Environment on AWS with Terraform, Jenkins, and S3 Building a modern AWS CI/CD pipeline requires the right combination of tools and infrastructure to handle growing development teams and complex deployment needs. This guide walks DevOps engineers, cloud architects, and development teams through creating a scalable CI/CD environment using Terraform infrastructure as code, Jenkins on AWS, and AWS S3 artifact storage. https://lnkd.in/ghZy7qCG Amazon Web Services (AWS) #AWS, #AWSCloud, #AmazonWebServices, #CloudComputing, #CloudConsulting, #CloudMigration, #CloudStrategy, #CloudSecurity, #businesscompassllc, #ITStrategy, #ITConsulting, #viral, #goviral, #viralvideo, #foryoupage, #foryou, #fyp, #digital, #transformation, #genai, #al, #aiml, #generativeai, #chatgpt, #openai, #deepseek, #claude, #anthropic, #trinium, #databricks, #snowflake, #wordpress, #drupal, #joomla, #tomcat, #apache, #php, #database, #server, #oracle, #mysql, #postgres, #datawarehouse, #windows, #linux, #docker, #Kubernetes, #server, #database, #container, #CICD, #migration, #cloud, #firewall, #datapipeline, #backup, #recovery, #cloudcost, #log, #powerbi, #qlik, #tableau, #ec2, #rds, #s3, #quicksight, #cloudfront, #redshift, #FM, #RAG

I was recently assigned a task to set up a dedicated Jenkins instance for a project and hand it over to the client, along with proper documentation. While working on it, I had to piece things together across different docs and plugin configurations, especially with Jenkins where multiple plugins come into play depending on the use case. To make things clearer for the client and to have a single reference, I documented the steps and setup, from installation to CI CD pipeline configuration and multi server deployment. With AI making quick answers easily accessible, this is for anyone who prefers a structured guide without hopping between multiple sources. 🔗: https://lnkd.in/dh6-Yifq #Jenkins #AWS #DevOps #CICD

Built and deployed a 3-tier AWS architecture using Terraform that runs a containerized application in a production-style setup. The real challenge wasn’t writing Terraform. It was understanding how all the pieces fit together in a real system. So I designed an architecture where infrastructure doesn’t just exist, it actually runs and serves an application. 🔧 What’s included: - Frontend & backend on Auto Scaling groups (private subnets) - External and internal load balancing - High availability database layer - EC2 instances pulling Docker images from ECR at boot No manual deployment. Every new instance comes up, pulls the container, and starts serving traffic automatically. Biggest takeaway: Understanding how components connect > just knowing how to create them. Next step: adding CI/CD to make deployments fully automated. GitHub: https://lnkd.in/g9wnQPVB #terraform #aws #devops #cloud #infrastructureascode