Lessons learned in DevOps: Docker, Kubernetes, Jenkins, and Git

Most CI/CD pipelines fail for the same reason — no clear stages. After 4 years in DevOps, here's the multi-stage GitHub Actions pipeline I recommend to every engineer on my team: ━━━━━━━━━━━━━━━━━━━ Stage 1 → Test Stage 2 → Build & tag Docker image Stage 3 → Deploy to Staging Stage 4 → Deploy to Production (with manual approval) ━━━━━━━━━━━━━━━━━━━ 3 things that make this bulletproof: 1️⃣ Use needs: to chain jobs — if tests fail, nothing else runs 2️⃣ Tag images with github.sha — every build is fully traceable 3️⃣ Use GitHub Environments for prod — enforces human approval before anything goes live You don't need a complex tool to do this. A single YAML file in .github/workflows/ is enough to build a production-grade pipeline. Save this post for when you set yours up. What does your CI/CD stack look like? Drop it in the comments 👇 #DevOps #GitHubActions #CICD #Docker #Kubernetes #CloudNative #DevOpsEngineer #SoftwareEngineering

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

While learning, I discovered that as a DevOps engineer, Git is not only where code lives. It is where: • Infrastructure configurations are stored • Terraform files are versioned • CI/CD pipelines are managed • Bash and PowerShell scripts are tracked • Teams collaborate without overwriting each other’s work The beauty of Git is that it gives you history. If something breaks, you can trace what changed. If you make a mistake, you can roll back. If multiple people are working together, everyone can contribute without chaos. Concepts that once sounded confusing are now starting to make sense: • git clone → bring a project from the remote repository to your local machine • git add . → prepare your changes • git commit -m "message" → save a snapshot of those changes • git push → send your changes to the remote repository • git pull → get the latest updates from others I now see Git as the memory of a project. Without it, DevOps would feel like trying to build a house with no blueprint and no record of what has changed. What Git command or concept took you the longest to understand? #Git #DevOps #CloudComputing #VersionControl #LearningInPublic #TechJourney #CI_CD

🚀 Day 17 of My DevOps Journey — 3 Jenkins Mistakes I Made (So You Don’t Have To) While building my CI/CD pipeline, Jenkins taught me one thing: 👉 It doesn’t fail randomly… it fails for a reason. Here are 3 mistakes I made (and how I fixed them): 🔹 1. Pipeline Failing Due to Docker Permission Issue ❌ Error: "permission denied /var/run/docker.sock" 👉 What was wrong: Jenkins didn’t have permission to access Docker ✔ Fix: Added Jenkins user to Docker group / configured Docker socket properly 🔹 2. “No valid crumb” (403 Error) ❌ Jenkins UI/config changes failing 👉 What was wrong: CSRF protection issue ✔ Fix: Adjusted Jenkins security settings / handled crumb properly 🔹 3. Pipeline Not Triggering Automatically ❌ Webhook not working 👉 What was wrong: Incorrect webhook URL / missing trigger config ✔ Fix: Verified GitHub webhook + enabled trigger in Jenkins 🔹 What I Learned: ✔ Always check logs carefully ✔ Most errors are configuration-related ✔ Debugging is a core DevOps skill 💡 Key Learning: “Jenkins doesn’t test your patience — it tests your understanding.” These mistakes helped me understand CI/CD at a much deeper level. If you're learning Jenkins, expect failures — that’s where real learning happens. Let’s grow together 🤝 #DevOps #Jenkins #CICD #Automation #Debugging #Cloud #LearningInPublic

My "Indentation vs. Reality" DevOps Moment If you’ve ever spent an hour fighting a single space in a text file, you’re officially a DevOps Engineer. Today wasn't just about writing YAML; it was about the moment I realized that GitHub Actions isn't magic—it’s just a fresh, empty computer waiting for instructions. The "Ghost" Repository 👻 My first run failed. Why? Because I forgot the checkout step. I was staring at the logs thinking, "I pushed the code, why can't the runner see it?" That was my first big realization: The runner is a blank slate. It’s a brand-new Ubuntu machine that has never seen my code. Unless I explicitly tell it to "checkout" my repo, it’s just sitting there in an empty room. Breaking Things (The Real Learning) I hit a Command not found (exit code 127). The Culprit: A tiny syntax error in my echo command. The Lesson: In DevOps, a single misplaced space doesn't just look messy—it breaks the entire factory line. My "Aha!" Moments: Ephemeral Power: The runner lives, executes my steps, and then "dies." It’s fresh every single time. Shared Memory: I created a test.txt in Step 1 and successfully read it in Step 4. Seeing that persistence across steps made the "environment" concept click. The Hidden World: Running ls -la and seeing the .git folder inside the runner made me realize: "Okay, my code is actually physically here now." The Verdict Real learning isn't copying a perfect YAML template from a tutorial. It’s about breaking the pipeline, digging through the logs, and finally seeing that green checkmark appear. DevOps is 10% writing code and 90% understanding exactly why that code failed. Next up: Figuring out Environment Variables and Secrets. Let's see what I break tomorrow! 🛠️ #DevOps #GitHubActions #CICD #LearningInPublic #Cloud #Automation #Linux #TechJourney #BuildInPublic #DevOpsEngineer

🚀 If you're new to DevOps pipelines, here's the simplest way to understand how these 3 tools work together: 🔧 𝐒𝐭𝐞𝐩 1 — 𝐉𝐞𝐧𝐤𝐢𝐧𝐬 (𝐂𝐈) Jenkins watches your Git repo. The moment you push code, it: → Pulls the latest changes → Runs unit tests & security scans → Triggers the next stage automatically No manual clicks. No missed builds. 🐳 𝐒𝐭𝐞𝐩 2 — 𝐃𝐨𝐜𝐤𝐞𝐫 (𝐁𝐮𝐢𝐥𝐝) Jenkins calls Docker to: → Build a container image from your Dockerfile → Tag it with a version (e.g. app:v1.0.3) → Push it to a container registry (AWS ECR, DockerHub) Your app is now portable. Runs the same everywhere. ⎈ 𝐒𝐭𝐞𝐩 3 — 𝐇𝐞𝐥𝐦 (𝐂𝐃) Helm takes that image and deploys it to Kubernetes: → Uses templated charts (no copy-pasting YAML!) → Tracks release versions → Rollback in one command if something breaks Together they form a complete pipeline: 𝑪𝒐𝒅𝒆 → 𝑻𝒆𝒔𝒕 → 𝑩𝒖𝒊𝒍𝒅 → 𝑷𝒂𝒄𝒌𝒂𝒈𝒆 → 𝑫𝒆𝒑𝒍𝒐𝒚 This is the foundation of every modern DevOps workflow — whether you're at a startup or a bank. #Jenkins #Docker #Helm #Kubernetes #CICD #DevOps #CloudNative #DevSecOps #PipelineAutomation #SoftwareEngineering

🚀 41 seconds. From Git push to live Docker image on Docker Hub. I just built and automated a complete CI/CD workflow using GitHub Actions + Docker — and it took exactly 30 lines of YAML. Here's what happens every time I push to main: ✅ Code is checked out automatically ✅ Docker image builds in seconds   ✅ Health checks run before anything goes live ✅ Image pushes to Docker Hub with zero manual steps No SSH. No "docker build" on my laptop. No human error. Slide 5 shows the image auto-pushed to Docker Hub. Fully automated. Zero manual intervention. The lesson? If you're still deploying manually, you're not doing DevOps — you're doing repetitive work that a 30-line script can handle for free. This is the kind of automation I bring to engineering teams. 🔹 Tech stack: Docker, GitHub Actions, CI/CD, YAML If your team needs someone who ships automation-first, let's talk. 👇 What does your deployment pipeline look like? Drop a comment — I read every one. #OpenToWork #DevOps #GitHubActions #Docker #CICD #CloudEngineering #SRE #InfrastructureAsCode #PakistanTech #HiringDevOps #RemoteWork #TechJobs #DevOpsEngineer #Automation #LinkedIn 💾 Save this post if you're learning CI/CD. 🔄 Share it with someone still deploying manually.

I built my first CI/CD pipeline. It failed 20 times before it worked. And I learned more from those failures than any tutorial could teach me. I'm making a career change into DevOps. I have a family counting on me to make this work. Every evening after my full-time job, every weekend, I sit down and push through the TechWorld with Nana bootcamp. This week was Jenkins. The task sounded straightforward: build a pipeline that automatically tests a NodeJS app, packages it into a Docker image, pushes it to Docker Hub, and commits the new version back to GitLab. Full automation. No manual steps. Reality hit different. First wall: GitLab authentication. My password had special characters that broke the git URL inside the pipeline. Jenkins injected the password into the URL and the special characters mangled it completely. The fix was simple once I understood it — use a Personal Access Token instead of a password. Tokens don't have special characters. Lesson learned: never use raw passwords in CI/CD pipelines. Tokens exist for a reason. Second wall: Docker permission denied. Jenkins runs inside a Docker container. To build Docker images, it needs access to the host's Docker socket. I mounted the socket correctly, but Jenkins runs as a non-root user — it didn't have permission to use it. One chmod command fixed it. But understanding WHY it failed taught me about Docker socket permissions, user contexts inside containers, and the concept of Docker-outside-of-Docker. The pipeline I built: • Stage 1: Automatically increments the app version using npm • Stage 2: Runs tests — if they fail, everything stops. No broken code gets deployed • Stage 3: Builds a Docker image tagged with the new version • Stage 4: Pushes the image to Docker Hub • Stage 5: Commits the version bump back to GitLab One click triggers all five stages. That's CI/CD in action. The Dockerfile, the Jenkinsfile, the credential management, the Docker-in-Docker setup — none of it made sense until it broke. Then it all clicked. I'm not where I want to be yet. But I'm nowhere near where I started. #DevOps #Jenkins #CICD #Docker #Pipeline #GitLab #Automation #LearningInPublic #CareerChange #TechWorldWithNana

🚀 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

🚀 Day 6 of My DevOps Journey — Jenkins + CI/CD (Automation Begins) Until now, I was building and running things manually. Today, I automated it. 👉 This is where DevOps truly starts. 🔹 What I Practiced: ➡️ Installing & running Jenkins (Docker setup) ➡️ Creating a pipeline job ➡️ Writing a basic Jenkinsfile ➡️ Understanding CI/CD workflow 🔹 Mini Project: I built my first CI/CD pipeline: ✔ Stage 1: Verify files ✔ Stage 2: Build Docker image ✔ Stage 3: Run container ✔ Stage 4: Smoke test using "curl" Everything triggered from Jenkins 🔥 🔹 Real Issues I Faced: ❌ docker: 'compose' is not a docker command inside Jenkins ❌ Pipeline failing due to environment issues 🔹 How I Fixed It: ✔ Installed required plugins / ensured Docker access ✔ Used correct shell syntax (sh '''...''') to avoid Groovy errors ✔ Debugged step-by-step using logs 💡 Key Learning: “CI/CD is not about tools — it’s about trust in automation.” Now I understand: ▪️ How code moves from commit → deployment ▪️ How pipelines reduce manual effort ▪️ Why automation is critical in DevOps Next → GitHub Webhooks (trigger builds automatically ⚡) If you're learning DevOps or working with CI/CD, let’s connect 🤝 #DevOps #Jenkins #CICD #Automation #Docker #Cloud #LearningInPublic