Day 18 DevOps Journey: Debugging Deployment Issues with Jenkins and Docker

Midway through a 7-day DevOps build, and one thing is already clear: Most of the real learning does not come from things working. It comes from things breaking. I have been putting in 7 to 8 hours daily, and almost every meaningful insight has come from debugging something that should have worked, but did not. A few observations from the process: • Kubernetes networking is easy to misunderstand until you are forced to debug it Understanding ClusterIP, NodePort, and Ingress conceptually is one thing. Troubleshooting why a service is not reachable is something else entirely. What helped most was stepping inside the cluster and testing from within. That is where things started to make sense. • Writing deployment configs from scratch exposes every gap Copying YAML is fast, but fragile. Small misconfigurations break everything. Fixing them forces you to understand how Kubernetes is actually managing workloads, not just applying configs. • Containerization is more than just “it runs” Image optimization and proper environment handling made a noticeable difference. Reliability becomes a real concern very quickly when things are not perfect. Currently working on: • Clean service exposure using Ingress • Preparing to move this setup toward cloud infrastructure using Terraform This approach is slower than following tutorials. But it builds something tutorials don’t i.e. clarity under failure. Curious how others approach debugging Kubernetes networking issues or structuring Terraform setups cleanly. Always open to learning from different perspectives. #DevOps #Kubernetes #Terraform #Docker #SRE #InfrastructureAsCode #CloudEngineering #PlatformEngineering #K8s #DevOpsCommunity

Most DevOps confusion starts earlier than people think. Not with Kubernetes. Not with Terraform. Not with Prometheus. It starts when someone still is not fully comfortable with: - images - containers - Dockerfiles - Docker Compose - the difference between "the app" and "the environment" So I created something different from the rest of the series: A Beginner's Guide to Containerisation Book 00 - the free foundation book for How To DevOps ... And I'm giving it away for completely FREE. It is designed to remove the friction at the bottom of the stack so the rest of the series becomes easier to absorb. What it gives you: - a plain-English mental model for containers - your first real Docker workflow - Dockerfiles from first principles - networking, volumes, and Compose - a full-stack multi-container project - the bridge into the main How To DevOps books If you have ever felt like every DevOps tutorial assumes Docker knowledge without actually teaching it properly, this book is for you. No fluff. No cloud bills. Just a practical foundation you can run on your own laptop. Link in comments. #Docker #Containers #DevOps #SoftwareEngineering #PlatformEngineering

While learning DevOps, one tool that keeps coming up again and again is Docker — and now I understand why it’s so important. Docker helps you package an application with everything it needs (code, dependencies, environment) so it runs the same everywhere — no more “it works on my machine” problem. Why Docker Matters: Consistent environments across development, testing, and production Lightweight and fast compared to virtual machines Easy to deploy and scale applications Works perfectly with CI/CD pipelines Makes collaboration between teams much smoother Key Topics to Learn in Docker: Docker basics (images, containers) Writing Dockerfile Docker Compose (multi-container apps) Image optimization & best practices Volumes & networking Docker Hub / container registries Basic troubleshooting & debugging My Thought: Docker feels like a foundation skill for DevOps. Without it, managing environments and deployments becomes messy and time-consuming. Still learning, but understanding Docker is already making things much clearer #Docker #DevOps #Cloud #Containerization #LearningJourney

🚀 What happens when you stop watching tutorials… and start building every single day? I’ve been learning DevOps for a while now — AWS, Docker, CI/CD. But at some point, I realized something: Understanding concepts is easy. Building real systems consistently? That’s the real challenge. So I decided to test myself. For the next 30 days, I’m committing to working on one real-world DevOps task every single day — and sharing everything publicly. Not just what works… but also what doesn’t. This journey will cover: 🔹 AWS infrastructure & real deployments 🔹 Docker and containerized applications 🔹 CI/CD pipelines 🔹 Monitoring and observability 🔹 System design and scalability But I’m not doing this just to complete tasks. I’ll also be: • Breaking down how real systems are designed • Understanding failure scenarios and root causes • Thinking in terms of scalability and production systems Each day, I’ll share: • The problem I worked on • How I approached it • Tools and architecture used • Key learnings and challenges The goal is simple — to move from “I know DevOps tools” to “I can actually build and explain real systems.” Let’s see how far consistency can take this 🚀 If you want to follow along or refer to the work, here’s my GitHub: 🔗 https://lnkd.in/giUt8m-q #DevOps #AWS #CloudComputing #LearningInPublic #SystemDesign #30DaysChallenge

🚀 Day 14 of My DevOps Journey — A Small Docker Mistake That Can Break Everything I made a mistake that many beginners make. 👉 I relied on the "latest" tag. At first, everything worked fine. Until I had to fix something in production. 🔹 What Happened: - I deployed a new version of my app - Something broke - I tried to rollback ❌ But I couldn’t figure out which version was actually running 🔹 The Problem with "latest": Using "latest" means: ❌ No version tracking ❌ No rollback clarity ❌ No deployment history 🔹 What I Changed: ✔ Started using version tags ("v1", "v2", "build-1") ✔ Tagged every image properly ✔ Made rollback fast and predictable 🔹 Real Impact: Now if something breaks: 👉 I can instantly rollback to a stable version 👉 No confusion 👉 No guesswork 💡 Key Learning: “Convenience in development can become chaos in production.” If you're using Docker, stop relying only on "latest". Version your images — your future self will thank you. Let’s grow together 🤝 #DevOps #Docker #CICD #BestPractices #Cloud #LearningInPublic #BuildInPublic

The first time I used Docker, I felt unstoppable. Until… production broke. I still remember typing random commands, hoping something would work: `docker ps`… `docker logs`… `docker restart`… Nothing felt structured. It was just trial and error. That’s when I realized: Docker isn’t hard. Not knowing the right commands at the right time is. Over time, a pattern emerged: 🔹 Build → `docker build` 🔹 Run → `docker run` 🔹 Observe → `docker ps`, `docker logs`, `docker stats` 🔹 Debug → `docker exec`, `docker inspect` 🔹 Clean → `docker system prune` And suddenly… chaos turned into control. Most engineers try to memorize all commands. But the pros? They understand the lifecycle of a container. Because in real-world incidents, you don’t need 30 commands. You need the right 5 at the right moment. If you’re learning Docker, don’t overwhelm yourself. Start here: 👉 Run a container 👉 Check logs 👉 Exec into it 👉 Restart it 👉 Clean up That alone will solve 80% of your problems. Master the basics. The rest becomes muscle memory. Follow Ramses Fouda for more insights on DevOps, Cloud, and AI 🚀 Docker, Inc #docker #commands #cloud #devops #containers

I haven’t written a line of code in over three months, at least not in the traditional sense. I’ve used GitHub Copilot to write nearly everything. Early on, it wasn’t pretty. Getting from “working” to “production-ready” required a lot of refactoring and a lot of hands-on correction. It saved time in bursts, but it wasn’t consistent. A few weeks ago, I shifted to Claude Opus 4.6 (and I’m looking forward to 4.7). I also invested time upfront creating detailed instructions and patterns for Copilot to follow. Something surprising happened. According to Azure DevOps, my productivity jumped 80% last month compared to my yearly average. I’ve sanity-checked that number. Could my story points be inflated? Possibly. I’m watching that closely. But even accounting for that, the speed difference feels real. What’s changed isn’t just faster output. It’s the quality curve. The gap between “first draft” and “production-ready” is shrinking. Features that used to take two weeks are now being implemented in 1-2 days, with far less rework. The biggest shift? Writing code is no longer the bottleneck. Having solid requirements, thinking clearly, and writing good prompts are. It’s still early. I’m still cautiously optimistic. But I’m increasingly impressed.

🚀 I Built a Production-Style AWS EKS Cluster Using Terraform — And It Broke More Than I Expected Most DevOps tutorials end at: 👉 “terraform apply succeeded.” That’s not where real work ends. That’s where problems begin. So I decided to go beyond tutorials and build an AWS EKS cluster from scratch — fixing real issues along the way. 🧠 What I Built ✔️ Amazon EKS (Kubernetes 1.29) ✔️ Custom VPC with public & private subnets ✔️ NAT Gateway for private networking ✔️ Managed Node Groups ✔️ IAM Roles with IRSA (OIDC) ⚠️ Real Issues I Faced ❌ Unsupported Kubernetes version → AWS silently drops old versions ❌ Terraform provider conflicts → Module ≠ provider mismatch breaks everything ❌ Git mistakes → Almost pushed sensitive Terraform state files 💡 What This Taught Me “Working infra” ≠ “Production-ready infra” Version compatibility can break everything Git hygiene is critical in DevOps Debugging is the real skill — not deployment 📊 Outcome ✔️ Fully working EKS cluster ✔️ Nodes accessible via kubectl ✔️ Clean repo with proper workflow 🚀 What’s Next Remote Terraform state (S3 + DynamoDB) CI/CD pipeline (GitHub Actions) Deploy real applications on EKS Monitoring (Prometheus + Grafana) 🔗 Full Project Breakdown 👉 Read here: https://lnkd.in/gVn5M9gB 💬 Final Thought: Anyone can deploy infrastructure. But debugging failures, fixing them, and preventing them again — That’s what makes you a real DevOps engineer.

🚀 My 7-Day Journey: Mastering Docker (and why you should too!)  I’ve decided to start a series. Why? Because in DevOps, if you don't understand the "Box," you can't manage the "Ship." 📦🚢 Over the next 7 days, I’m going to break down Docker from the absolute basics to the point where we are ready for Kubernetes. No heavy jargon—just simple analogies and real-world logic. Day 1: What is Docker, anyway? Think of a Shipping Container. Before they existed, loading a ship was pure chaos. Bags of flour, fragile electronics, and barrels of oil were all loose. Things broke. Things leaked. Then came the standard metal box. The ship doesn't care what's inside; it just knows how to carry the box. Docker is that box for your code. It wraps your app, your libraries, and your specific settings into one neat package. It runs the same on my laptop as it does on a massive Cloud server. "It works on my machine" is officially a thing of the past. 🚫 I’m committing to posting every day this week to master the fundamentals before we move into Kubernetes next week. Who’s coming along for the ride? Let’s learn together! 🤝 #DevOpsEngineer #SRE #PlatformEngineering #CloudNative #InfrastructureAsCode #CICD #LearningInPublic #WeeklyDevOps #TechSimplified #DevOpsCommunity #DevOps #Docker #LearningInPublic #TechSimplified #CloudComputing

The first time I used Docker, I felt unstoppable. Until… production broke. I still remember typing random commands, hoping something would work: `docker ps`… `docker logs`… `docker restart`… Nothing felt structured. It was just trial and error. That’s when I realized: Docker isn’t hard. Not knowing the right commands at the right time is. Over time, a pattern emerged: 🔹 Build → `docker build` 🔹 Run → `docker run` 🔹 Observe → `docker ps`, `docker logs`, `docker stats` 🔹 Debug → `docker exec`, `docker inspect` 🔹 Clean → `docker system prune` And suddenly… chaos turned into control. Most engineers try to memorize all commands. But the pros? They understand the lifecycle of a container. Because in real-world incidents, you don’t need 30 commands. You need the right 5 at the right moment. If you’re learning Docker, don’t overwhelm yourself. Start here: 👉 Run a container 👉 Check logs 👉 Exec into it 👉 Restart it 👉 Clean up That alone will solve 80% of your problems. Master the basics. The rest becomes muscle memory. Follow Neel Shah for more insights on DevOps, Cloud, and AI 🚀 Docker, Inc #docker #commands #cloud #devops #containers