[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":79,"_71":80,"_35":81},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":55,"_62":21,"_63":64,"_65":66,"_67":68,"_69":70},"id",50,"title","How to Use This Series","slug","docker-part-0-how-to-use-this-series","excerpt","Navigate the Docker Compendium effectively based on your goals","# Docker Compendium Part 0: How to Use This Series\n\nWelcome to the Docker Compendium - a comprehensive guide for developers who use Docker daily but want to truly understand what's happening under the hood. This isn't a beginner tutorial. We assume you can write Dockerfiles and use docker-compose. What we'll teach you is *why* things work (or don't), and how to handle Docker in production like an expert.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| **Series Size** | 20 articles, ~25,000 lines |\n| **Target Audience** | Mid to Senior developers using Docker in production |\n| **Prerequisites** | Can write Dockerfiles, use docker-compose, basic Linux knowledge |\n| **Time Investment** | 10-40 hours depending on track |\n| **Key Outcome** | Deep understanding of Docker internals + production expertise |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter completing this series, you will be able to:\n\n- **Understand internals**: Know exactly what happens when you run `docker run` or `docker build`\n- **Optimize builds**: Reduce build times from 20 minutes to 2 minutes with proper caching\n- **Debug anything**: Fix containers that crash, won't start, or behave unexpectedly\n- **Secure containers**: Harden production containers against common attack vectors\n- **Run production**: Deploy with zero-downtime, monitor effectively, and troubleshoot issues\n\n---\n\n## 🔥 Introduction: Why This Series Exists\n\n### The Docker Knowledge Gap\n\nI've been conducting technical interviews for years. The pattern I see is troubling:\n\n**Most developers use Docker. Few understand Docker.**\n\nThey can write a Dockerfile, but not explain why their image is 2GB. They use docker-compose, but don't know why services can't communicate. They run containers in production, but panic when one crashes with no logs.\n\nThis gap shows up in production:\n\n- **20-minute builds** because cache invalidates on every change\n- **Random OOM kills** because memory limits weren't understood\n- **Security vulnerabilities** from running as root with all capabilities\n- **Hours of debugging** because they don't know how to inspect a dead container\n- **Downtime during deployments** because health checks weren't configured\n\n### Real Production Impact\n\nHere are real incidents I've witnessed:\n\n**The 5GB Node.js Image**\n```\nTeam's Docker image grew to 5GB over 6 months.\nCI pipeline took 25 minutes just to push.\nDeployments timed out. Disk filled up.\nRoot cause: No .dockerignore, node_modules copied twice.\nFix: 150MB image, 3-minute builds.\n```\n\n**The Zombie Apocalypse**\n```\nProduction container accumulated 1,847 zombie processes.\nMemory usage grew until OOM killer struck.\nApplication had no graceful shutdown.\nRoot cause: Running Node.js as PID 1 without init.\nFix: Added --init flag, proper signal handling.\n```\n\n**The \"Works on My Machine\" Classic**\n```\nContainer worked perfectly in development.\nCrashed immediately in production with exit code 1.\nNo logs, no errors, just dead.\nRoot cause: Missing environment variable, app crashed before logging initialized.\nFix: Validate env vars at startup, fail fast with clear message.\n```\n\n**This series prevents these incidents.** Each article combines:\n\n- **Internals knowledge** that gives you intuition for how things work\n- **Production stories** showing what happens when things go wrong\n- **Debugging exercises** that train your troubleshooting instincts\n- **Interview questions** that prepare you for senior-level conversations\n\n---\n\n## 🧠 Mental Model: The Docker Knowledge Pyramid\n\nThink of Docker knowledge as a pyramid with three levels:\n\n```text\n ┌─────────────────────────────────┐\n │ INTERNALS │ ← Level 3: How it works inside\n │ (This Series) │ (namespaces, cgroups, layers,\n │ │ BuildKit, overlay networks)\n ├─────────────────────────────────┤\n │ PATTERNS │ ← Level 2: Best practices\n │ (Most tutorials) │ (multi-stage builds, compose,\n │ │ health checks, logging)\n ├─────────────────────────────────┤\n │ COMMANDS │ ← Level 1: How to use it\n │ (Documentation) │ (docker run, build, compose up,\n │ │ basic Dockerfile syntax)\n └─────────────────────────────────┘\n```\n\n**Level 1 (Commands)**: Most developers live here. They know `docker run -p 8080:8080`, can write a basic Dockerfile, and use docker-compose.\n\n**Level 2 (Patterns)**: Better developers reach this level. They use multi-stage builds, configure health checks, and follow security best practices.\n\n**Level 3 (Internals)**: This is where expertise lives. Understanding *why* things work lets you debug anything, optimize effectively, and make informed architectural decisions.\n\n**This series focuses on Level 3** - because understanding internals unlocks mastery of Levels 1 and 2.\n\n---\n\n## 🔬 Deep Dive: Series Structure\n\n### 20 Articles Organized by Topic\n\n| # | Category | Articles | Focus |\n|---|----------|----------|-------|\n| 0 | **Introduction** | 1 | This guide - how to navigate the series |\n| 1-4 | **Internals** | 4 | Container runtime, images, builds, networking |\n| 5-8 | **Dockerfile** | 4 | Optimization, multi-stage, base images, config |\n| 9-13 | **Runtime** | 5 | Resources, volumes, logging, security, debugging |\n| 14-16 | **Compose** | 3 | Advanced compose, dependencies, dev vs prod |\n| 17-19 | **Production** | 3 | CI/CD, deployment patterns, monitoring |\n| 20 | **Reference** | 1 | Cheatsheet and decision guide |\n\n### Article Dependencies\n\n```text\n ┌─────────────────────┐\n │ Part 0: Intro │\n └──────────┬──────────┘\n │\n ┌────────────────┼────────────────┐\n │ │ │\n ▼ ▼ ▼\n ┌─────────────────┐ ┌───────────┐ ┌─────────────────┐\n │ Part 1: │ │ Part 3: │ │ Part 4: │\n │ Internals │ │ Build │ │ Networking │\n │ (namespaces, │ │ Process │ │ (bridge, DNS) │\n │ cgroups) │ │ │ │ │\n └────────┬────────┘ └─────┬─────┘ └────────┬────────┘\n │ │ │\n ▼ ▼ │\n ┌─────────────────┐ ┌───────────┐ │\n │ Part 9: │ │ Part 5-8: │ │\n │ Resources │ │ Dockerfile│ │\n │ (memory, CPU) │ │ Mastery │ │\n └────────┬────────┘ └─────┬─────┘ │\n │ │ │\n └───────┬────────┴────────────────┘\n │\n ▼\n ┌─────────────────┐\n │ Parts 9-13: │\n │ Runtime & Ops │\n │ (volumes, logs, │\n │ security, debug)│\n └────────┬────────┘\n │\n ▼\n ┌─────────────────┐\n │ Parts 14-16: │\n │ Compose │\n └────────┬────────┘\n │\n ▼\n ┌─────────────────┐\n │ Parts 17-19: │\n │ Production │\n └────────┬────────┘\n │\n ▼\n ┌─────────────────┐\n │ Part 20: │\n │ Cheatsheet │\n └─────────────────┘\n```\n\n### Each Article Contains\n\n| Section | Purpose | Time |\n|---------|---------|------|\n| 📋 At a Glance | Quick overview, prerequisites | 30 sec |\n| 🎯 What You'll Learn | Learning objectives | 1 min |\n| 🔥 Production Story | Real-world incident that motivates the topic | 5 min |\n| 🧠 Mental Model | Visual concept explanation | 5 min |\n| 🔬 Deep Dive | Technical details with code | 20 min |\n| ⚠️ Common Mistakes | What NOT to do | 5 min |\n| 🐛 Debug This | Find-the-bug exercise | 10 min |\n| 💻 Exercises | Hands-on practice (5 exercises) | 30 min |\n| 🎤 Interview Questions | Senior-level Q&A | 10 min |\n| 📋 Quick Reference | Bookmarkable summary | 2 min |\n| 📅 Review Schedule | Spaced repetition plan | 1 min |\n\n**Total per article**: ~90 minutes for complete coverage.\n\n---\n\n## 🛤️ Learning Tracks: Choose Your Path\n\n### Track 1: Performance & Optimization (8 hours)\n\n**Goal**: Make builds faster, images smaller, containers more efficient.\n\n```text\nPart 1 (Internals) → Part 3 (Build Process) → Part 5 (Dockerfile Optimization)\n→ Part 6 (Multi-Stage) → Part 9 (Resources)\n```\n\n**You'll learn**:\n- Why builds are slow and how to fix it\n- How to reduce image size by 90%\n- Memory and CPU management for containers\n\n---\n\n### Track 2: Security Focus (6 hours)\n\n**Goal**: Harden containers for production security requirements.\n\n```text\nPart 1 (Internals) → Part 7 (Base Images) → Part 8 (Build Config)\n→ Part 12 (Security Hardening)\n```\n\n**You'll learn**:\n- Security implications of base image choices\n- How to handle secrets properly\n- Container hardening techniques\n\n---\n\n### Track 3: Production Operations (10 hours)\n\n**Goal**: Run Docker in production with confidence.\n\n```text\nPart 1 (Internals) → Part 11 (Logging) → Part 13 (Debugging)\n→ Part 15 (Dependencies) → Part 17-19 (Production)\n```\n\n**You'll learn**:\n- Logging and monitoring strategies\n- Debugging production issues\n- Zero-downtime deployments\n\n---\n\n### Track 4: Complete Deep Dive (40 hours)\n\n**Goal**: Master everything - become the Docker expert on your team.\n\n```text\nAll parts in order: 0 → 1 → 2 → ... → 20\n```\n\n**You'll learn**:\n- Everything. You'll be able to answer any Docker question.\n\n---\n\n## ⚠️ Common Mistakes (When Using This Series)\n\n### Mistake 1: Skipping the Internals\n\n**Problem**: Jumping to Dockerfile optimization without understanding layers.\n\n```text\n❌ Approach:\n\"I just want to make my build faster\"\n→ Applies random optimizations → Still slow → Frustrated\n\n✅ Better:\nPart 1 (Internals) → Part 3 (Build Process) → Part 5 (Optimization)\n→ Understands WHY → Applies correct fixes → Fast builds\n```\n\n**Why it matters**: Optimization without understanding is just cargo-culting. You need to know how layer caching works to optimize effectively.\n\n---\n\n### Mistake 2: Reading Without Practicing\n\n**Problem**: Passive reading doesn't build debugging skills.\n\n```text\n❌ \"I read about namespaces\" (can't debug namespace issues)\n✅ \"I explored namespaces with lsns and nsenter\" (can debug anything)\n```\n\n**Do the exercises.** The 🐛 Debug This sections are specifically designed to build troubleshooting instincts.\n\n---\n\n### Mistake 3: Skipping Production Stories\n\n**Problem**: Thinking \"that won't happen to me.\"\n\n```text\n❌ \"I'll skip the zombie process story, I don't run Node.js\"\n✅ \"Zombie processes can happen in any language - this is about PID 1\"\n```\n\n**Production stories teach principles**, not just specific fixes. The zombie process story teaches about PID namespaces and init responsibilities.\n\n---\n\n### Mistake 4: Not Bookmarking Quick Reference\n\n**Problem**: Re-reading entire articles when you need a reminder.\n\n```text\n❌ Re-reading Part 9 to remember memory limit flags\n✅ Checking bookmarked Quick Reference card\n```\n\n**Bookmark the 📋 Quick Reference sections.** They're designed for fast lookup.\n\n---\n\n## 🐛 Debug This: Are You Ready?\n\nBefore starting this series, you should be able to answer these questions. If you can't, that's okay - but consider reviewing basic Docker tutorials first.\n\n**Question 1**: What's the difference between `RUN`, `CMD`, and `ENTRYPOINT`?\n\n

🔍 Check Your Answer

\n\n- **RUN**: Executes during build, creates a layer\n- **CMD**: Default command when container starts, can be overridden\n- **ENTRYPOINT**: Main executable, CMD becomes its arguments\n\n```dockerfile\n# RUN: Install dependencies (build time)\nRUN apt-get update && apt-get install -y curl\n\n# ENTRYPOINT + CMD pattern\nENTRYPOINT [\"python\", \"app.py\"]\nCMD [\"--port\", \"8080\"]\n\n# docker run myapp → python app.py --port 8080\n# docker run myapp --port 9000 → python app.py --port 9000\n```\n\n

\n\n---\n\n**Question 2**: How do you expose a container's port 8080 on host port 3000?\n\n

🔍 Check Your Answer

\n\n```bash\ndocker run -p 3000:8080 myimage\n```\n\nFormat: `-p HOST:CONTAINER`\n\nThe host port (3000) is what you access from outside. The container port (8080) is what the app listens on inside.\n\n

\n\n---\n\n**Question 3**: What's the difference between `COPY` and `ADD`?\n\n

🔍 Check Your Answer

\n\n- **COPY**: Simply copies files/directories\n- **ADD**: Copies + can extract archives + can fetch URLs\n\n**Best practice**: Use `COPY` unless you specifically need ADD's features.\n\n```dockerfile\n# Prefer COPY\nCOPY package.json ./\n\n# ADD only when needed\nADD archive.tar.gz /app/ # Auto-extracts\n```\n\n

\n\n---\n\n**If you answered all three correctly**, you're ready for this series!\n\n**If you struggled**, consider reviewing:\n- Docker's official \"Get Started\" guide\n- Basic Dockerfile reference\n- docker-compose tutorial\n\nThen come back - we'll be here.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Environment Check ⭐\n\nVerify your Docker environment is ready for this series.\n\n```bash\n# Check Docker version (should be 20.10+)\ndocker version\n\n# Check Docker Compose version (should be v2+)\ndocker compose version\n\n# Check you can run containers\ndocker run --rm hello-world\n\n# Check you can build\necho \"FROM alpine\" | docker build -t test-build -\ndocker rmi test-build\n```\n\n

✅ Expected Output

\n\n```\nDocker version 24.x or higher\nDocker Compose version v2.x\nHello from Docker! (from hello-world)\nSuccessfully built (from build test)\n```\n\nIf any command fails, fix your Docker installation before continuing.\n\n

\n\n---\n\n### Exercise 2: Baseline Assessment ⭐⭐\n\nCreate a simple multi-stage Dockerfile to verify you understand basics.\n\n```dockerfile\n# Create this Dockerfile and build it\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm install\nCOPY . .\nRUN npm run build\n\nFROM nginx:alpine\nCOPY --from=builder /app/dist /usr/share/nginx/html\nEXPOSE 80\nCMD [\"nginx\", \"-g\", \"daemon off;\"]\n```\n\nQuestions to answer:\n1. How many layers does the final image have?\n2. Why use multi-stage here?\n3. What's the approximate size difference vs single-stage?\n\n

✅ Answers

\n\n1. **Layers**: The final image has layers from nginx:alpine plus one COPY layer. Node.js and build tools are NOT included.\n\n2. **Why multi-stage**:\n - Build dependencies (Node.js, npm) not needed at runtime\n - Only static files go to production image\n - Smaller image, smaller attack surface\n\n3. **Size difference**:\n - Single-stage with Node.js: ~1GB\n - Multi-stage with nginx: ~25MB\n - **~97% reduction**\n\n

\n\n---\n\n### Exercise 3: Find Your Knowledge Gaps ⭐⭐⭐\n\nAnswer these senior-level questions. Be honest - gaps are what we'll fill.\n\n1. What Linux kernel features does Docker use for isolation?\n2. Why might `docker build` be slow even when \"Using cache\" appears?\n3. What happens when a container exceeds its memory limit?\n4. How would you debug a container that exits immediately with no logs?\n5. What's the difference between `docker-compose up` and `docker compose up`?\n\n

✅ Answers

\n\n1. **Kernel features**: Namespaces (PID, NET, MNT, UTS, IPC, USER) for isolation, cgroups for resource limits, overlay filesystem for layers.\n\n2. **Slow with cache**: Usually the build context. Even with cache hits, Docker must send the entire context to the daemon. Large context = slow start.\n\n3. **Memory exceeded**: OOM killer terminates the container. Exit code 137 (128 + 9 for SIGKILL). No graceful shutdown.\n\n4. **Debug no-logs crash**:\n - `docker logs ` (might be empty)\n - `docker inspect ` (check State.ExitCode, State.Error)\n - Override entrypoint: `docker run --entrypoint sh `\n - Check events: `docker events`\n\n5. **compose difference**:\n - `docker-compose` (v1): Standalone Python tool, deprecated\n - `docker compose` (v2): Plugin integrated into Docker CLI, current standard\n\n

\n\n---\n\n## 🎤 Interview Questions\n\n### Q1: What makes someone a \"Docker expert\" vs just a \"Docker user\"?\n\n**Answer**: A Docker user can write Dockerfiles and run containers. A Docker expert understands:\n- **Internals**: Namespaces, cgroups, layer mechanics\n- **Optimization**: Why builds are slow and how to fix them\n- **Debugging**: How to investigate crashed containers, network issues\n- **Security**: Attack vectors and hardening techniques\n- **Production**: Deployment strategies, monitoring, troubleshooting\n\nThe expert can debug novel problems because they understand the underlying mechanics.\n\n---\n\n### Q2: If you had 2 hours to improve a team's Docker practices, what would you focus on?\n\n**Answer**: Three high-impact areas:\n\n1. **Add .dockerignore** (~10 min): Often missing, causes huge context uploads and cache problems\n\n2. **Fix layer ordering** (~30 min): Move dependency installation before code copy to cache effectively\n\n3. **Add health checks** (~20 min): Prevents cascading failures from unhealthy containers\n\nThese three changes typically reduce build times by 50%+ and improve reliability significantly.\n\n---\n\n### Q3: How would you explain Docker to a senior developer who's never used it?\n\n**Answer**: \"Docker lets you package your application with its entire environment - OS libraries, dependencies, configuration - into a single artifact called an image. When you run that image, you get a container, which is an isolated process that behaves identically everywhere: your laptop, CI server, or production.\n\nUnder the hood, it's not a VM - there's no hypervisor. Docker uses Linux kernel features (namespaces and cgroups) to isolate processes and limit their resources. This makes containers fast to start (milliseconds vs minutes for VMs) and efficient (no OS overhead per container).\n\nThe killer feature is reproducibility: if it works in the container locally, it works the same way in production.\"\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### What We Covered\n\n1. **Series Philosophy**: This is for practitioners who want expertise, not beginners learning basics\n2. **Knowledge Pyramid**: Commands → Patterns → Internals (we focus on internals)\n3. **Structure**: 20 articles covering internals, Dockerfiles, runtime, compose, and production\n4. **Learning Tracks**: Choose based on your goals - optimization, security, operations, or complete mastery\n\n### Key Principles\n\n- **Internals unlock everything**: Understanding how Docker works lets you debug anything\n- **Production stories teach principles**: Real incidents illustrate concepts better than abstract explanations\n- **Practice builds skill**: Reading about debugging isn't the same as debugging\n\n### Prerequisites Checklist\n\n- [ ] Can write basic Dockerfiles\n- [ ] Comfortable with docker-compose\n- [ ] Basic Linux command line knowledge\n- [ ] Docker 20.10+ installed\n- [ ] Docker Compose v2 installed\n\n---\n\n## 📋 Quick Reference\n\n### Series At a Glance\n\n| Block | Parts | Hours | Focus |\n|-------|-------|-------|-------|\n| Internals | 1-4 | 8 | How Docker really works |\n| Dockerfile | 5-8 | 6 | Build optimization & security |\n| Runtime | 9-13 | 10 | Operations & debugging |\n| Compose | 14-16 | 6 | Multi-container patterns |\n| Production | 17-19 | 6 | CI/CD & deployment |\n| Reference | 20 | 2 | Cheatsheet |\n\n### Learning Track Quick Select\n\n| Goal | Track | Parts | Hours |\n|------|-------|-------|-------|\n| Faster builds | Performance | 1,3,5,6,9 | 8 |\n| Better security | Security | 1,7,8,12 | 6 |\n| Production ops | Operations | 1,11,13,15,17-19 | 10 |\n| Everything | Complete | All | 40 |\n\n---\n\n## 📅 Review Schedule\n\nSince this is the intro article, here's how to approach the series:\n\n- **Day 1**: Read this article, complete exercises, identify your track\n- **Day 2-3**: Start Part 1 (Container Internals)\n- **Weekly**: Complete 2-3 articles per week\n- **After each article**: Do the exercises before moving on\n- **Monthly**: Review Quick Reference cards from completed articles\n\n---\n\n## 📚 Series Navigation\n\n**This is Part 0** - the series introduction.\n\n**Next**: [Part 1: Container Internals - What's Really Running](/articles/docker-part-1-container-internals)\n\n**Full Series**:\n- Part 0: How to Use This Series (You are here)\n- Part 1: Container Internals\n- Part 2: Image Anatomy\n- Part 3: Build Process Deep Dive\n- Part 4: Networking Internals\n- Part 5-8: Dockerfile Mastery\n- Part 9-13: Runtime & Operations\n- Part 14-16: Docker Compose\n- Part 17-19: Production Patterns\n- Part 20: Cheatsheet & Decision Guide\n\n---\n\n*Ready to understand Docker at a deeper level? Let's start with [Part 1: Container Internals](/articles/docker-part-1-container-internals).*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:25.364701Z","createdAt","2026-06-10T07:19:25.365210Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",13,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Devops","readingTime","seriesId","seriesOrder","author",{"_31":55,"_89":57,"_90":91,"_92":93,"_94":-5,"_95":-5,"_96":-5,"_97":-5,"_98":-5},"category",{"_31":85,"_71":59,"_35":86,"_74":87,"_88":-5},"tags",[77,78],"series",{"_31":55,"_71":72,"_35":73,"_74":75,"_76":23},"name","Docker Compendium: From Practitioner to Expert","docker-compendium","description","Master Docker internals, optimization patterns, and production best practices. For developers who use Docker daily but want deeper understanding of what's happening under the hood. Not a beginner series - we assume you can write Dockerfiles and use docker-compose. Learn what namespaces and cgroups really do, why your builds are slow, how to debug containers that crash, and how to run Docker in production like a pro.\n","isActive",{"_31":82,"_71":83,"_35":84},{"_31":79,"_71":80,"_35":81},218,"Introduction","introduction",213,"Docker","docker",7,"devops","Category for Devops","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]