Automating CI/CD with Docker & GitHub Actions

🚨 Debugging a Maven Deployment Failure (401 Unauthorized) This week I ran into a real CI/CD failure while trying to deploy a Java application using Apache Maven → Sonatype Nexus Repository. At first, everything looked correct… until deployment failed. 🔴 The Problem Running: mvn deploy Result: [ERROR] status code: 401, Unauthorized ✔ Build succeeded ❌ Deployment to Nexus failed 🔍 What I Checked I initially investigated: - Nexus repository permissions - Credentials configuration - Repository setup in pom.xml - Local Maven configuration Everything appeared correct on the surface. 🧠 Root Cause The issue turned out to be client-side configuration conflicts, not server-side permissions. Specifically: 👉 Corrupted / conflicting settings.xml files - An unexpected XML config existed in the project directory - My local ~/.m2/settings.xml was also misconfigured As a result, Maven authentication was failing silently. 🛠️ Fix I reset the Maven configuration to eliminate inconsistencies: 1️⃣ Remove local settings file rm ~/.m2/settings.xml 2️⃣ Recreate clean configuration nano ~/.m2/settings.xml 3️⃣ Add correct Nexus credentials <settings> <servers> <server> <id>nexus-snapshots</id> <username>my-username</username> <password>my-password</password> </server> </servers> </settings> 4️⃣ Retry deployment mvn clean deploy ✔ Deployment successful 💡 Key Lesson A 401 Unauthorized in CI/CD is not always a permissions issue. It can also be caused by: - broken client configuration - conflicting settings files - incorrect local environment setup 👉 In this case, Maven authentication was broken before the request even reached Nexus. 🔧 Improvement Going Forward - Keep ~/.m2/settings.xml clean and controlled - Avoid placing duplicate config files inside projects - Use mvn help:effective-settings for debugging faster - Treat build configuration as part of the application itself 📌 Final Thought This felt like a simple deployment error at first — but it reinforced a core DevOps lesson: 👉 Failures are often caused by configuration, not code. Understanding where the failure originates (build, config, auth, or network) is what separates running pipelines from reliable CI/CD systems. #DevOps #Maven #Nexus #CICD #Automation #Debugging #CloudEngineering

🚀 Just finished the Docker course on Boot.dev! 🚀 I’m excited to share that I’ve learned the fundamentals of Docker—a key technology in modern DevOps and CI/CD pipelines. Docker makes it simple and fast to deploy new versions of code by packaging applications and their dependencies into preconfigured environments. This not only speeds up deployment, but also reduces overhead and eliminates the “it works on my machine” problem. Docker is a core part of the CI/CD (Continuous Integration/Continuous Deployment) process, enabling teams to deliver software quickly and reliably. Here’s a high-level overview of a typical CI/CD deployment process: The Deployment Process: 1. The developer (you) writes some new code 2. The developer commits the code to Git 3. The developer pushes a new branch to GitHub 4. The developer opens a pull request to the main branch 5. A teammate reviews the PR and approves it (if it looks good) 6. The developer merges the pull request 7. Upon merging, an automated script, perhaps a GitHub action, is started 8. The script builds the code (if it's a compiled language) 9. The script builds a new docker image with the latest program 10. The script pushes the new image to Docker Hub 11. The server that runs the containers, perhaps a Kubernetes cluster, is told there is a new version 12. The k8s cluster pulls down the latest image 13. The k8s cluster shuts down old containers as it spins up new containers of the latest image This process ensures that new features and fixes can be delivered to users quickly, safely, and consistently. image credit: Boot.dev Docker course #docker #cicd #devops #softwaredevelopment #bootdev #learning

From GitHub → Jenkins → Docker → Kubernetes - complete DevOps workflow. Many people learn DevOps tools individually. But the real value comes from understanding how these tools work together in a real pipeline. Here’s a simplified breakdown of the 𝐞𝐧𝐝-𝐭𝐨-𝐞𝐧𝐝 𝐂𝐈/𝐂𝐃 𝐟𝐥𝐨𝐰 shown in the diagram 𝐂𝐈 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 (𝐁𝐮𝐢𝐥𝐝 & 𝐒𝐜𝐚𝐧) ‣ Developer pushes code to GitHub ‣ Jenkins CI pulls the code and triggers the pipeline ‣ OWASP Dependency Check scans for vulnerable libraries ‣ SonarQube performs code quality & security analysis ‣ Docker builds the image ‣ Trivy scans the image for vulnerabilities ‣ Image is pushed to the registry 𝐂𝐃 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 (𝐃𝐞𝐩𝐥𝐨𝐲) ‣ Jenkins CD updates the image version ‣ Changes pushed back to GitHub ‣ ArgoCD pulls the latest changes ‣ Deploys application to Kubernetes 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 & 𝐀𝐥𝐞𝐫𝐭𝐬 ‣ Prometheus collects metrics ‣ Grafana visualizes dashboards ‣ Email notifications for pipeline status 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐰𝐡𝐚𝐭 𝐜𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 𝐞𝐱𝐩𝐞𝐜𝐭 𝐲𝐨𝐮 𝐭𝐨 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝: ‣ CI (build + scan) ‣ CD (deploy + automate) ‣ Security (shift-left approach) ‣ Monitoring (production visibility) #Kubernetes #Helm #DevOps #CloudNative #Containers #Pod #YAML #Kubernetes #ZeroToOne #Git #GitHub #Linux #VersionControl #Linux #CICD #Docker #Terraform #Script #AWS #GCP #Azure #SDLC #DevOpsLife #SRE #DevOpsEngineer #jenkins #devops #cicd #automation

From GitHub → Jenkins → Docker → Kubernetes - complete DevOps workflow. Many people learn DevOps tools individually. But the real value comes from understanding how these tools work together in a real pipeline. Here’s a simplified breakdown of the 𝐞𝐧𝐝-𝐭𝐨-𝐞𝐧𝐝 𝐂𝐈/𝐂𝐃 𝐟𝐥𝐨𝐰 shown in the diagram 𝐂𝐈 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 (𝐁𝐮𝐢𝐥𝐝 & 𝐒𝐜𝐚𝐧) ‣ Developer pushes code to GitHub ‣ Jenkins CI pulls the code and triggers the pipeline ‣ OWASP Dependency Check scans for vulnerable libraries ‣ SonarQube performs code quality & security analysis ‣ Docker builds the image ‣ Trivy scans the image for vulnerabilities ‣ Image is pushed to the registry 𝐂𝐃 𝐏𝐢𝐩𝐞𝐥𝐢𝐧𝐞 (𝐃𝐞𝐩𝐥𝐨𝐲) ‣ Jenkins CD updates the image version ‣ Changes pushed back to GitHub ‣ ArgoCD pulls the latest changes ‣ Deploys application to Kubernetes 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 & 𝐀𝐥𝐞𝐫𝐭𝐬 ‣ Prometheus collects metrics ‣ Grafana visualizes dashboards ‣ Email notifications for pipeline status 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐰𝐡𝐚𝐭 𝐜𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 𝐞𝐱𝐩𝐞𝐜𝐭 𝐲𝐨𝐮 𝐭𝐨 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝: ‣ CI (build + scan) ‣ CD (deploy + automate) ‣ Security (shift-left approach) ‣ Monitoring (production visibility) #Kubernetes #Helm #DevOps #CloudNative #Containers #Pod #YAML #Kubernetes #ZeroToOne #Git #GitHub #Linux #VersionControl #Linux #CICD #Docker #Terraform #Script #AWS #GCP #Azure #SDLC #DevOpsLife #SRE #DevOpsEngineer #jenkins #devops #cicd #automation

I broke my own server… just by deploying code 😅 That’s when I realized — I don’t actually understand deployment. Before this, my “CI/CD pipeline” was: ssh → git pull → npm install → pm2 restart …and pray nothing breaks 🙏 Works fine… until it doesn’t. One wrong env, one missed step, one failed install — and production is down. So I decided to fix this properly. Started from basics: 📦 Used "scp" to push builds manually 🔑 Used "ssh" to run commands on VPS ⚙️ Wrote small bash scripts to automate steps Felt powerful… but still risky. Because I was the pipeline. Then I moved to GitHub Actions. Now every push to main: • builds the project • securely connects to VPS • deploys code • restarts services No manual login. No “did I run that command?” No panic. But here’s what actually changed my thinking: «CI/CD is not about saving time. It’s about removing human mistakes from production.» Also learned the hard way: • Always test scripts on staging first • Make deployments idempotent • Never trust ".env" blindly • Logs > assumptions Now deployment feels less like a risk… and more like a system. Still learning DevOps. But at least now — pushing code doesn’t feel like gambling 🎯 What’s the worst thing you’ve broken while deploying? 😄 #CICD #DevOps #GitHubActions #VPS #BackendEngineering #Automation #DeveloperLife

This week I ran into a classic DevOps issue while working with Jenkins and Docker. I had a Jenkins pipeline that builds and pushes a Docker image. It was working perfectly before — same code, same Dockerfile, same pipeline. Then suddenly the build failed. The error: "npm ERR! Cannot find module 'promise-retry'" At first, it didn’t make sense. I hadn’t changed anything in the code or Dockerfile. After digging deeper, I realized the real issue: Even though my Dockerfile didn’t change, this line was the culprit: FROM node:22-alpine3.22 This is a mutable tag. Which means: Docker pulled a newer version of the base image That image had updated npm behavior My step npm install -g npm@latest broke due to incompatibility. 💡 Key Lesson: Docker builds are NOT deterministic unless you pin versions. ✅ Fix I applied: Removed npm install -g npm@latest Switched to a stable base image (node:20-alpine) (Optional) Pinned npm to a specific version 🚀 Takeaways: Avoid using latest (for Node, npm, or anything) Always pin versions in production systems CI/CD failures are often caused by environment changes, not code changes Jenkins may expose issues that don’t appear locally due to caching This was a great reminder that in DevOps: 👉 “If it’s not pinned, it’s not predictable.” #DevOps #Docker #Jenkins #CI_CD #Learning #Debugging

🚀 3 Kubernetes Errors I Faced While Building My CI/CD Pipeline (and How I Fixed Them) While building my Docker → Jenkins → Kubernetes CI/CD project, deployment didn’t work perfectly at first. I ran into several Kubernetes errors and had to debug them step by step. Here are 3 issues I faced and what helped me solve them 👇 🐞 1. ErrImagePull / ImagePullBackOff Issue: Kubernetes failed to pull my Docker image. 🔎 Debugging kubectl describe pod <pod-name> Root Cause The image name in my deployment YAML didn’t match the image pushed to Docker Hub. ✅ Fix Corrected the image name and redeployed the deployment. 🐞 2. Pod Running but Application Not Accessible Issue: Pod status was Running, but I couldn’t access the application in the browser. 🔎 Debugging kubectl get svc Root Cause Mismatch between containerPort and targetPort. ✅ Fix Updated the service configuration so Kubernetes could correctly route traffic to the container. 🐞 3. Service Not Accessible from Browser Issue: Application still not reachable externally. 🔎 Debugging kubectl get nodes -o wide Root Cause I was using the wrong NodePort URL. ✅ Fix Accessed the application using: <NodeIP>:<NodePort> 💡 Biggest Lesson Building the pipeline was straightforward. But debugging Kubernetes errors taught me far more about how things actually work under the hood. Still learning and exploring more around Kubernetes, CI/CD pipelines, and DevOps practices. #DevOps #Kubernetes #Docker #Jenkins #CICD #LearningInPublic #DevOpsJourney

Why does Git remain the undisputed standard for version control 20 years later? Key Points to Watch: -Distributed Power: Every developer has the entire history, eliminating the "server is down" bottleneck. -Integrity: The use of SHA-1 hashing ensures that what you commit is exactly what gets deployed. -Branching Efficiency: In Git, a branch is just a pointer to a commit, making "feature branching" nearly instant and zero-cost. The Engine of Distributed Truth Headline: Why Git is the "Mission Control" of Modern Engineering Before we had automated pipelines and cloud-native deployments, we had a massive problem: Collaboration at Scale. In 2005, the Linux kernel team faced a crisis that forced a total rethink of how we handle code. The result was Git—a tool built by Linus Torvalds in just two weeks that fundamentally changed how the world builds software. The "Architect" View on Git: -Zero Single Point of Failure: Unlike older centralized systems (SVN/CVS), Git is distributed. Every clone is a full backup. If the main server goes dark, the project lives on every engineer's machine. -Immutable History: Every commit is cryptographically hashed. In a DevOps pipeline, this is your "Chain of Custody"—you know exactly which lines of code triggered which deployment. -Branching as a Strategy: Git made branching "cheap." This allowed us to move away from "all hands on one file" to isolated feature development, which is the heartbeat of CI/CD. Whether I'm managing a complex GitHub Enterprise migration or spinning up a new microservice, Git isn't just a "save button." It is the source of truth that triggers the entire automation lifecycle. Quick Poll for the Devs: When you're in the terminal, are you a git rebase perfectionist or a git merge traditionalist? #Git #DevOps #VersionControl #OpenSource #SoftwareArchitecture #CloudEngineering #GitHub #TechHistory #7EagleGroup #7EagleAcademy Jordie Kern , Adam Peters, Brad Lawson, M.S., Donavan Maldonado-Fashina

Hey Techies 👋, DevOps Reality Check When even GitHub becomes unreachable.... Today’s task looked simple push code, trigger my Jenkins pipeline, and continue working on my Docker setup. But instead, I hit this: 👉 fatal: unable to access 'https://github.com/...' 👉 Could not resolve host: github.com At first, it felt like a blocker. But in DevOps, these “small” errors often teach the biggest lessons. After digging deeper, I realized the issue wasn’t with Git or Jenkins it was a DNS/network issue on my remote server (via SSH). How I solved it: - Checked internet connectivity on the remote machine - Verified DNS configuration in /etc/resolv.conf - Restarted network services - Ensured proper nameserver (like 8.8.8.8) was set - Re-tested using ping github.com And finally… connection restored, code pushed, pipeline back on track Key takeaway: 𝐍𝐨 𝐦𝐚𝐭𝐭𝐞𝐫 𝐡𝐨𝐰 𝐚𝐝𝐯𝐚𝐧𝐜𝐞𝐝 𝐲𝐨𝐮𝐫 𝐂𝐈/𝐂𝐃 𝐩𝐢𝐩𝐞𝐥𝐢𝐧𝐞 𝐢𝐬, 𝐞𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 𝐝𝐞𝐩𝐞𝐧𝐝𝐬 𝐨𝐧 𝐭𝐡𝐞 𝐛𝐚𝐬𝐢𝐜𝐬 𝐧𝐞𝐭𝐰𝐨𝐫𝐤𝐢𝐧𝐠 𝐚𝐧𝐝 𝐜𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐯𝐢𝐭𝐲. This was a reminder that DevOps isn’t just automation… It’s also patience, debugging, and understanding systems from the ground up. Have you ever been stuck because of something as simple as DNS? #DevOps #Jenkins #Docker #GitHub #CICD #Troubleshooting #LearningInPublic #WomenInTech #CloudComputing

🚢 Struggling with managing multiple Kubernetes YAML files? You're not alone. When I first started working with Kubernetes, handling deployments, services, configs, and updates manually felt messy and error-prone. Then I discovered Helm — and everything changed. 📦 Helm is the package manager for Kubernetes that helps you: ✔ Deploy applications with a single command ✔ Manage configurations using reusable templates ✔ Upgrade and rollback releases effortlessly Instead of maintaining dozens of YAML files, Helm lets you define everything in a clean, reusable structure called a Chart. 💡 Think of it like: npm for Node.js apt for Ubuntu ➡️ Helm for Kubernetes I’ve put together a simple, beginner-to-advanced PDF guide on Helm covering: Core concepts (Chart, Values, Release) Real-world usage Commands you actually use in DevOps Practical examples 📄 Comment “HELM” and I’ll share the PDF with you. #Kubernetes #Helm #DevOps #CloudNative #PlatformEngineering