🚀 Day 37/90 — Docker Revision Day Instead of rushing into new tools today, I did something equally important — revision. Over the past few days, I’ve been working deeply with Docker as part of my #90DaysOfDevOps journey. Today I consolidated everything I learned to make sure the fundamentals actually stick. Here’s what I revised today: 🐳 Running and managing containers 🐳 Building and tagging custom images 🐳 Writing Dockerfiles from scratch 🐳 Working with volumes and bind mounts 🐳 Container networking 🐳 Multi-container apps with Docker Compose 🐳 Multi-stage builds and pushing images to Docker Hub To make things easier for future reference, I also created a Docker Commands Cheat Sheet that covers the commands I’ll actually use while working with containers. 📌 Docker Cheat Sheet: One thing I realized today: Learning tools is easy — retaining them requires revision and practice. Also identified a couple of areas to strengthen: • Image layers & caching • CMD vs ENTRYPOINT Small steps every day → building real DevOps skills. #90DaysOfDevOps #DevOps #Docker #LearningInPublic #DevOpsJourney #TrainWithShubham #CloudComputing
Docker Revision Day: Consolidating Fundamentals
More Relevant Posts
-
𝐃𝐚𝐲 3: 𝐃𝐨𝐜𝐤𝐞𝐫𝐟𝐢𝐥𝐞𝐬 𝐄𝐱𝐩𝐥𝐚𝐢𝐧𝐞𝐝 𝐋𝐢𝐤𝐞 𝐍𝐞𝐯𝐞𝐫 𝐁𝐞𝐟𝐨𝐫𝐞 – 𝐁𝐮𝐢𝐥𝐝, 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐰𝐢𝐭𝐡 𝐌𝐮𝐥𝐭𝐢-𝐒𝐭𝐚𝐠𝐞 𝐁𝐮𝐢𝐥𝐝𝐬 & 𝐑𝐞𝐝𝐮𝐜𝐞 𝐈𝐦𝐚𝐠𝐞 𝐒𝐢𝐳𝐞 𝐛𝐲 𝐔𝐩 𝐭𝐨 70% 🐳 𝑶𝒏 𝑫𝒂𝒚 1, 𝒘𝒆 𝒓𝒂𝒏 𝒄𝒐𝒏𝒕𝒂𝒊𝒏𝒆𝒓𝒔. 𝑶𝒏 𝑫𝒂𝒚 2, 𝒘𝒆 𝒖𝒏𝒅𝒆𝒓𝒔𝒕𝒐𝒐𝒅 𝒊𝒎𝒂𝒈𝒆𝒔. But today… Everything changes. 👉 What if the exact image you need doesn’t exist? 👉 What if you want full control over your environment? That’s where Dockerfiles come in. In Day 3 of #20DaysOfDocker, we stop relying on others and start building our own images from scratch. 👉 What you’ll learn: What Dockerfiles really are (more than just a config file) All essential instructions (FROM, RUN, COPY, CMD, etc.) How to build custom images step by step Multi-stage builds (build big → ship small ) Best practices used in real production systems Optimization techniques to reduce image size dramatically 💡 The big insight: A Dockerfile is a recipe for consistency. Same code + same Dockerfile = same environment anywhere. No more “it works on my machine.” ❌ 𝐇𝐚𝐧𝐝𝐬-𝐨𝐧 (𝐫𝐞𝐚𝐥 𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠): Write your first Dockerfile Build your own image Optimize it step by step 𝐔𝐬𝐞 𝐦𝐮𝐥𝐭𝐢-𝐬𝐭𝐚𝐠𝐞 𝐛𝐮𝐢𝐥𝐝𝐬 𝐭𝐨 𝐜𝐮𝐭 𝐬𝐢𝐳𝐞 𝐛𝐲 𝐮𝐩 𝐭𝐨 70% ⚡ 𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐦𝐚𝐭𝐭𝐞𝐫𝐬: Smaller images = faster deployments Optimized builds = lower costs Clean structure = easier maintenance Real skill = real DevOps growth 𝐁𝐲 𝐭𝐡𝐞 𝐞𝐧𝐝 𝐨𝐟 𝐃𝐚𝐲 3: 𝐘𝐨𝐮’𝐫𝐞 𝐧𝐨𝐭 𝐣𝐮𝐬𝐭 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫𝐬… 𝐘𝐨𝐮’𝐫𝐞 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐭𝐡𝐞𝐦. 👉 𝐒𝐭𝐚𝐫𝐭 𝐃𝐚𝐲 3 𝐡𝐞𝐫𝐞: https://lnkd.in/dtVn3ieP Tomorrow, we go even deeper. Let’s keep building. 🐳 #Docker #DevOps #LearningInPublic #OpenSource #BackendDevelopment #CloudComputing #SoftwareEngineering #TechCommunity
To view or add a comment, sign in
-
Pushing, Pulling & Cleanup 🚀 Your image is built and tested. Time to share it — and clean up after yourself. Pushing your image: 👉 Build the image: docker build -t my-image . 👉 Log in to Docker Hub: docker login 👉 Tag the image with your username: docker tag my-image:latest pradeep/my-image:1 👉 Push to Docker Hub: docker push pradeep/my-image:1 Pulling from a private registry: 👉 Login and pull: docker logindocker pull pradeep/my-image Cleanup — keep your environment lean: 👉 Remove stopped containers: docker container prune 👉 Remove a specific image: docker rmi my-image:latest 👉 Remove unused volumes: docker volume prune 👉 Remove unused networks: docker network prune A clean Docker environment is a fast Docker environment. Make cleanup part of your regular workflow. That's a wrap on my Docker series! 🎉 From your first docker run hello-world to pushing your own image to a registry — this is everything you need to work with Docker confidently. If this series helped you, share it with someone starting their DevOps journey. Follow me — Pradeep for more hands-on content like this! 💡 #Docker #DevOps #Containerization #CloudComputing #SoftwareEngineering #TechLearning
To view or add a comment, sign in
-
🚀 Completed: 20 Days of Docker Challenge 🐳 20 days ago, I started a personal challenge to deeply understand Docker from fundamentals to real production usage. Instead of just learning commands, I focused on how Docker is actually used in real DevOps environments. Here are the key things I learned during this journey 👇 🔹 Docker Fundamentals • Containers vs Virtual Machines • Docker Architecture • Images vs Containers • Writing production-ready Dockerfiles 🔹 Container Optimization • Multi-stage builds • Image size optimization • Layer caching 🔹 Storage & Networking • Docker Volumes • Bind mounts vs volumes • Docker networking (Bridge, Host, Overlay) 🔹 Troubleshooting & Debugging • Container logs • Debugging crash loops • Resource monitoring 🔹 CI/CD Integration • Docker + Jenkins pipelines • Container registries (Docker Hub, ECR) • Automated deployments 🔹 Production Best Practices • Environment variables & secrets • Security best practices • CPU & memory resource limits • Zero-downtime deployments 🔹 Real DevOps Workflow Developer → Git → CI/CD Pipeline → Docker Image → Container Registry → Deployment → Monitoring This challenge helped me understand that: ✔️ Docker is not just about containers ✔️ It enables consistent environments ✔️ It simplifies CI/CD pipelines ✔️ It improves deployment reliability Next step in my learning journey: ➡️ Kubernetes & Cloud-native infrastructure Thanks to everyone who followed this journey and shared feedback along the way. If you're learning DevOps, I highly recommend trying a learning challenge like this. Consistency compounds over time. To Read All Blogs: https://lnkd.in/gg_N6Fda #Docker #DevOps #Containers #LearningInPublic #Cloud #CI_CD
To view or add a comment, sign in
-
-
Day 37 of #90DaysOfDevOps — Docker Revision & Cheat Sheet 🚀 Instead of just learning Docker, I wanted something I can actually use in real projects. So today I paused and revised everything from Day 29–36 and built a practical Docker Cheat Sheet. 💡 What I covered: Containers, Images, and Dockerfile basics Volumes & Bind Mounts Networking & multi-container communication Docker Compose (real-world setups) Multi-stage builds & image optimization Docker Hub (push, pull, tagging) 📌 Key realization: Learning tools is easy… Remembering and applying them is the real challenge. That’s why this cheat sheet will be my go-to reference while building projects. 🔗 Cheat Sheet: https://lnkd.in/gB5MPDAJ Would love feedback from the community 🙌 #Docker #DevOps #90DaysOfDevOps #LearnInPublic #CloudComputing #TrainWithShubham
To view or add a comment, sign in
-
-
🚀 Day 4 of My DevOps Journey — Building My First Docker Image Yesterday I ran containers. Today, I built my own. This is where Docker stopped feeling like a tool… and started feeling like power. 🔹 What I Learned: ▪️ What a Dockerfile is ▪️ How to define instructions (FROM, COPY, RUN, CMD) ▪️ How images are built layer by layer ▪️ Difference between base image and custom image 🔹 Mini Project: I created my own Docker image for a simple app: ✔ Used nginx:alpine as base image ✔ Added custom HTML page ✔ Built image using docker build ✔ Ran container using my own image ✔ Verified output in browser 🔹 Real Issue I Faced: ❌ Changes not reflecting after rebuild 🔹 What Was Wrong: Docker was using cached layers 🔹 How I Fixed It: ✔ Used --no-cache during build ✔ Understood how Docker layer caching works 💡 Key Learning: “If you don’t understand Docker layers, you don’t understand Docker.” Now I can: ▫️ Build custom images ▫️ Modify application behavior ▫️ Prepare apps for deployment Next → Docker Compose (multi-container setup 🔥) If you’re learning DevOps, let’s connect and grow together 🤝 #DevOps #Docker #Dockerfile #Containers #Cloud #LearningInPublic #BuildInPublic #CI_CD
To view or add a comment, sign in
-
93 pages of Docker and K8s in one PDF. Free. We came across this guide and honestly it's one of the better free resources we've seen in a while. Covers everything from spinning up your first container to Helm charts, RBAC, CI/CD pipelines with Jenkins and ArgoCD, even monitoring with Prometheus and Grafana. 18 chapters. Commands, YAML examples, real deployment walkthroughs. The kind of stuff you'd normally piece together from 30 different blog posts. Fair warning, we didn't write this. We also couldn't track down the original author (if you know who created it, please tag them in the comments so we can give proper credit). But it's too good not to share. Save this. Grab the link from the first comment. What's the one Docker or K8s topic you wish someone had explained to you properly when you were starting out, and how long did it take you to figure it out on your own? #Docker #Kubernetes #DevOps #K8s
To view or add a comment, sign in
-
-
Kompose converts your Docker Compose files to Kubernetes manifests in seconds. It works. BUT I'd only use it to understand what K8s expects — not as your actual deployment strategy. The problem with Kompose output in production: • No versioning or upgrade path • No rollback management • No templating or environment overrides • Every real workload ends up as a Helm chart anyway The honest path from Docker to K8s: -> Run Kompose once to see what K8s manifests look like -> Then write (or find) the proper Helm chart The conversion step is useful for learning. Not for running anything you actually care about. Gone through the Docker → K8s migration? What tripped you up most? 👇 #kubernetes #docker #devops #homelab
To view or add a comment, sign in
-
I wasted hours on Docker… because I didn’t know these 👇 If you're learning DevOps, these 5 Docker mistakes will slow you down: ❌ Using heavy base images → Slower builds, larger images ✔️ Use lightweight images like alpine ❌ Ignoring .dockerignore → Unnecessary files increase build time ✔️ Always exclude node_modules, logs, etc. ❌ Hardcoding environment variables → Breaks across environments ✔️ Use environment variables properly ❌ Running containers as root → Security risk (I learned this late) ✔️ Use non-root users in Dockerfile ❌ Not understanding Docker layers → Every change rebuilds everything ✔️ Optimize Dockerfile for caching 💡 Reality check: Docker is NOT just a tool… It’s a skill that impacts performance, security, and scalability. I learned this while building a real microservices project 👇 https://lnkd.in/gc_mxhsz If you're switching to DevOps, don’t just learn—build. Which mistake have you made (or still making)? 👇 #DevOps #Docker #TechLearning #Beginners #BuildInPublic
To view or add a comment, sign in
-
🚀 I Finally Understood CI/CD… and It Changed Everything! 👩🎓For a long time, CI/CD felt confusing. Pipelines, Docker, Kubernetes… too many tools 😵💫 But today, it finally clicked. 💡 Here’s the simplest way to understand it 👇 👨💻 You write code ⬇️ 📌 Push to GitHub (PR + Merge) ⬇️ ⚙️ GitHub Actions automatically: ✔ Builds your code ✔ Runs tests ❌ If it fails → You fix it ✅ If it passes → It moves forward ⬇️ 🐳 Your app becomes a Docker Image ⬇️ 📦 Stored in Docker Hub ⬇️ 🧪 Tested in staging ⬇️ ☸️ Deployed using Kubernetes 🔥 Now comes the REAL power: Instead of risking everything… 🚀 You release to only 10% users first using Argo Rollouts 👥 10% → New version 👥 90% → Old version 📊 Monitor with Grafana 👉 If everything is stable → Full release 👉 If something breaks → Instant rollback 🧠 Bonus: Keep your code clean with SonarQube 💬 Realization: CI/CD is not about tools… It’s about confidence in every deployment. 📚 Best Learning Path (Simple): 1️⃣ Learn Git & GitHub 2️⃣ Practice CI using GitHub Actions 3️⃣ Learn Docker basics 4️⃣ Understand Kubernetes 5️⃣ Explore monitoring + deployments 🔥 If you're in tech, don’t skip this. This is what separates beginners from professionals. 💡 Follow for more simple tech breakdowns. #DevOps #CICD #Docker #Kubernetes #Parmeshwarmetkar #Learning #SoftwareEngineering #TechCareer
To view or add a comment, sign in
-
-
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
To view or add a comment, sign in
More from this author
Explore related topics
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development