Docker Best Practices for Software Engineers

Docker is the line between "it works on my machine" and "it works." One Dockerfile. One image. Runs the same everywhere. Your laptop, a server, your teammate's setup. Doesn't matter. Same result every time. That's not a convenience thing. That's the difference between a team that ships reliably and a team that spends half its time debugging environment issues. Before containers, you'd set up a server manually. Install dependencies one by one. Hope that the versions match what's running in production. If something broke, good luck figuring out what changed between environments. Docker removes all of that. You define your environment once in a Dockerfile, build an image, and every container that runs from it is identical. No guessing. No surprises. You can learn every CI/CD tool out there. But if your environments aren't consistent, none of it matters. Containers fix that at the root. #DevOps #Docker #LearningInPublic #coderco

Your Docker images don't need to be 1.2 GB. I see it constantly: teams shipping containers with build tools, dev dependencies, and entire SDK toolchains baked into production images. The fix takes five minutes. Multi-stage builds let you separate the build environment from the runtime environment. You compile in one stage, then copy only the final artifact into a minimal base image. That's it. Here's the pattern I use for every Go service we deploy: Result: ~12 MB instead of 1.2 GB. Faster pulls, smaller attack surface, cleaner CVE scans. The distroless base has no shell, no package manager — nothing an attacker can use. Three rules I follow for every Dockerfile: → Pin image tags to a digest, not latest → Order layers from least to most frequently changed → Never ship what you don't need at runtime Small images aren't just tidy. They're faster to deploy, cheaper to store, and harder to exploit. #DevOps #Docker #CloudNative #ContainerSecurity #PlatformEngineering

Production Issue: Pods Failed with ImagePullBackOff Recently, during a deployment, our pods failed with the error: ImagePullBackOff At first, it looked like a problem with the Docker image. But the real issue was something else. What We Found After checking, we discovered: The image was present in the registry The image tag was correct The issue was happening only in one specific namespace This pointed us in a different direction. Root Cause: The problem was an expired imagePullSecret in that namespace. Because of this, Kubernetes couldn’t authenticate with the container registry, so it failed to pull the image. What We Did to Fix It: Renewed the registry credentials Updated the Kubernetes Secret Restarted the affected pods After that, the deployment worked successfully Key Learnings: ImagePullBackOff doesn’t always mean the image is missing Always check namespace-level configurations Validate secrets and credentials during deployment issues Final Thought Sometimes, the issue isn’t with the application or image, it’s with access and configuration. A small expired secret can stop an entire deployment. #Kubernetes #DevOps #CloudComputing #K8s #Containers #PlatformEngineering #SRE #ProductionIssues #Troubleshooting #CloudNative

Ever had this moment where everything is running perfectly… and suddenly your Docker container just stops working? No code changes. No clear error. Just broken. Most of the time, it’s not a big failure—it’s something small hiding in the setup: Missing or incorrect environment variables A dependency not included inside the image A cached Docker layer not updating A version mismatch between services The frustrating part is Docker doesn’t always explain it clearly—it just fails quietly. So how do you actually fix it? You don’t guess—you isolate. Start with logs (docker logs <container>). Then check what’s actually inside the container using docker exec. If things still look off, rebuild without cache (--no-cache). And always verify versions and dependencies in your image. The real trick is simple: don’t look at Docker as “one system”—break it into small parts and test step by step. Once you do that, those “random issues” stop feeling random. #Docker #DevOps #Debugging #SoftwareEngineering #Containers

Most production issues I’ve seen were not caused by bad code. They were caused by inconsistent environments. The hardest bugs to fix are the ones you cannot reproduce. Development looks perfect. Production behaves differently. And suddenly you’re debugging: Different libraries Missing environment variables Runtime mismatches OS differences Not logic problems. Environment problems. This is the real reason Docker became essential. Not containers. Consistency. Docker enforces a simple engineering discipline: Build once. Package everything. Run the same everywhere. Because: Writing code is development. Making it predictable is engineering. Docker didn’t just introduce containers. It introduced reproducibility. And reproducibility is what production systems actually depend on. What deployment issue made you start using Docker? #Docker #DevOps #SoftwareEngineering #SystemDesign

The Kubernetes Debugging Cheat Sheet! Most Kubernetes outages don’t need genius debugging. They need the right command at the right time. After enough 2AM incidents, I realized: 👉 The difference between a 5-minute fix and a 2-hour outage is usually just one missed command. Here’s what consistently saves me: * kubectl describe → tells you why it failed * kubectl logs -p → tells you why it crashed (90% of people forget this) * kubectl get events → tells you what just changed * kubectl exec → lets you prove your assumptions inside the container But the real unlock is this: 🧠 Stop running commands. Start asking better questions. * What actually broke? * Where is it running? * Is this a pod issue, node issue, or config issue? Then run the ONE command that answers that. Also… 👉 Filter everything. Always. Because Kubernetes doesn’t hide problems: it buries them in noise. I turned this into a cheat sheet I wish I had on day one. Save it, your future on-call self will thank you. #kubernetes #devops #sre #cloudcomputing #platformengineering #oncall #softwareengineering #debugging #tech #programming

Most Docker tutorials stop at docker run. That’s exactly where production problems begin. I learned this the hard way. A base image CVE sitting in production, not caught by the pipeline, flagged hours later in an audit. The image had been running fine. The vulnerability hadn’t. I just didn’t know. That experience changed how I think about container delivery. It’s not enough to build an image that works. It needs to be minimal, verified, signed, and scanned, before it ever touches a registry. So I built a reference project that codifies exactly that. Here’s what I changed after that audit: Distroless final image. No shell, no package manager, ~4MB. The base image CVE that got us? No longer possible. There’s almost nothing left to exploit. Trivy scans every image before push. The pipeline fails on HIGH/CRITICAL, not a Slack notification you’ll read tomorrow. Not advisory. A hard stop. SBOM generated at build time. Image signed with cosign keyless signing. No private key to manage, signature tied to the GitHub Actions OIDC identity. You can prove exactly what was built and who built it. The CI/CD pipeline does two different things depending on context: On PRs: source scan, build amd64 locally, scan the loaded image. No registry push. No packages: write on untrusted code. On main/tags: multi-arch build, push, scan the exact digest (not the tag, tags are mutable), sign. One deliberate trade-off I documented: Release runs two builds, validation and publish. Slower. But the permission separation is clean, and clean pipelines don’t surprise you at 2am. Every decision has an ADR. Every operational scenario has a runbook entry. Because the person debugging this might be me. → https://lnkd.in/dUMiQCta If you’re building container delivery pipelines, what does your image scanning gate look like? Before push, after push, or both? #Docker #DevOps #CICD #PlatformEngineering #Security #Kubernetes

I’ve been refining my Docker skills recently, and the biggest shift for me has been seeing containers not just as packaging tools, but as infrastructure‑level abstractions that bring consistency across the entire software lifecycle. A container image is more than a bundle of code. It’s a reproducible execution contract. Same inputs, same outputs, same runtime behavior. That predictability is what makes containers so valuable for: • deterministic builds • GitOps workflows • ephemeral environments • scalable orchestration across container platforms As I’ve dug deeper, I’ve also come to understand that containers aren’t a Docker invention. Docker simply made them accessible. The real foundation comes from core Linux features that have existed for years: • namespaces — isolate processes, networking, and filesystems • cgroups — control and monitor CPU, memory, and other resources • overlayfs — enable layered filesystems for efficient, cacheable image builds. Understanding these primitives has made debugging and optimization feel far more intuitive. I’ve also been paying closer attention to writing better Dockerfiles: • smaller, minimal base images • multi‑stage builds • pinned versions • non‑root users • cache‑friendly layering Small improvements here compound into faster pipelines, smaller attack surfaces, and more reliable deployments. Docker has stopped feeling like "just a tool." It now feels like a core part of how we think about reproducibility, security, and operational clarity across environments. #DevOps #PlatformEngineering #Containers #CloudNative

Common Docker Mistakes I Made (So You Don’t Have To) 🙂 After working with Docker in real projects and VPS deployments, I realized something: Most problems were not advanced issues. They were basic mistakes repeated again and again. Here are some mistakes I made early on: 📌 1. Building images locally every time I used to build images on my laptop and push to Docker Hub. Result: • high CPU usage • slow builds • storage issues Fix: Moved builds to GitHub Actions. 📌 2. Not cleaning Docker regularly I didn’t remove unused images and containers. Result: • VPS storage filled up • server became unstable Fix: Use: docker system prune -a regularly. 📌 3. Ignoring logs When something failed, I guessed instead of checking logs. Result: • wasted time • wrong assumptions Fix: docker logs container_name Logs solve most problems. 📌 4. Hardcoding configs I sometimes put values directly in code. Result: • deployment issues • environment mismatch Fix: Use .env properly. 📌 5. No clear project structure At the beginning, everything was messy on the VPS. Result: • difficult debugging • hard to scale Fix: Use a clean docker-compose based structure. After all these mistakes, one thing became clear: Docker is simple — but discipline is required. If you follow a clean process, Docker becomes extremely powerful. Lesson: You don’t need to be perfect from the start. You just need to learn from your mistakes and improve your system. In the next post, I’ll share my complete VPS deployment architecture — how everything connects in production. #Docker #DevOps #SoftwareEngineering #VPS #BuildInPublic

🔥How to troubleshoot a Docker container that keeps restarting: ✅1. Check the logs: docker logs <container> --tail 50 ✅2. Check the exit code: docker inspect <container> | grep ExitCode Exit 0 = Clean stop Exit 1 = Application error Exit 137 = Killed (OOM or manual) Exit 139 = Segfault ✅3. Check resource limits: docker stats <container> ✅4. Run it interactively: docker run -it <image> /bin/sh Most restart loops are either OOM kills or application config errors. #DEVOPS