[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_33":86,"_74":87,"_37":88},"articles",{"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":22,"_23":24,"_25":24,"_26":16,"_27":28},"content",[31,32],"pageable",{"_29":22,"_30":20},"totalElements",2,"totalPages",1,"size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_33":106,"_35":107,"_37":108,"_39":109,"_11":110,"_42":-5,"_43":24,"_44":28,"_45":46,"_47":111,"_49":112,"_51":52,"_53":113,"_55":113,"_56":57,"_58":59,"_60":61,"_62":113,"_63":57,"_64":114,"_66":115,"_68":116,"_70":117,"_72":118},{"_33":34,"_35":36,"_37":38,"_39":40,"_11":41,"_42":-5,"_43":24,"_44":28,"_45":46,"_47":48,"_49":50,"_51":52,"_53":54,"_55":54,"_56":57,"_58":59,"_60":61,"_62":54,"_63":57,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73},"id",55,"title","Dockerfile Optimization Patterns","slug","docker-part-5-dockerfile-optimization","excerpt","Layer ordering, cache strategies, and size reduction","# Docker Compendium Part 5: Dockerfile Optimization Patterns\n\nYour Dockerfile works. But your image is 2GB, builds take 15 minutes, and production deploys are painfully slow. This article covers the patterns that separate amateur Dockerfiles from production-ready ones - layer ordering, cache strategies, size reduction, and the psychology of optimization.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Topic | Layer optimization, cache strategies, size reduction |\n| Complexity | Intermediate-Advanced |\n| Prerequisites | Part 2 (Image Anatomy), Part 3 (Build Process) |\n| Key Insight | Optimization is about understanding layer caching and image composition |\n| Time to Master | 3-4 hours |\n\n---\n\n## 🎯 What You'll Learn\n\n- **Layer ordering** - arrange instructions for maximum cache hits\n- **Size reduction** - techniques to shrink images dramatically\n- **Cache strategies** - when to bust cache, when to preserve it\n- **Platform-specific patterns** - Node.js, Python, Java, Go optimizations\n- **Anti-patterns** - common mistakes that bloat images\n\n---\n\n## 🔥 Production Story: The 5GB Node.js Image\n\nA team's CI pipeline took 45 minutes. Deploys to Kubernetes caused node pressure. Image pulls frequently timed out.\n\n**Investigation:**\n\n```bash\n$ docker images | grep app\nmycompany/app latest 5.2GB\n\n$ docker history mycompany/app\nIMAGE SIZE CREATED BY\n...\n 2.1GB npm install\n 1.8GB COPY . .\n 800MB apt-get install build-essential\n```\n\n**Root causes identified:**\n1. No `.dockerignore` - copying `node_modules`, `.git`, test fixtures\n2. Build tools in production image\n3. Development dependencies installed\n4. No multi-stage build\n5. Full Ubuntu base instead of slim/Alpine\n\n**The transformation:**\n\n```dockerfile\n# Before: 5.2GB, 45-minute builds\nFROM ubuntu:22.04\nRUN apt-get update && apt-get install -y nodejs npm build-essential python3\nWORKDIR /app\nCOPY . .\nRUN npm install\nCMD [\"npm\", \"start\"]\n\n# After: 180MB, 3-minute builds\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=production\n\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=builder /app/node_modules ./node_modules\nCOPY src/ ./src/\nCOPY package.json ./\nUSER node\nCMD [\"node\", \"src/index.js\"]\n```\n\n**Results:**\n- Image size: 5.2GB → 180MB (97% reduction)\n- Build time: 45 min → 3 min (93% reduction)\n- Deploy time: 8 min → 45 sec\n- CI costs: Reduced by 60%\n\n---\n\n## 🧠 Mental Model: The Optimization Pyramid\n\n```\n┌─────────────────────────────────────────────────────────────────┐\n│ DOCKERFILE OPTIMIZATION │\n│ │\n│ ┌─────────┐ │\n│ ╱ ╲ │\n│ ╱ CACHE ╲ │\n│ ╱ (Speed) ╲ │\n│ ╱ ╲ │\n│ ├───────────────────┤ │\n│ ╱ ╲ │\n│ ╱ SIZE (Storage) ╲ │\n│ ╱ ╲ │\n│ ├───────────────────────────┤ │\n│ ╱ ╲ │\n│ ╱ SECURITY (Safety) ╲ │\n│ ╱ ╲ │\n│ └───────────────────────────────────┘ │\n│ │\n│ Optimization flows top-down: │\n│ 1. Cache - Fast rebuilds, efficient CI │\n│ 2. Size - Fast pulls, lower storage costs │\n│ 3. Security - Minimal attack surface │\n│ │\n│ But they're interconnected: │\n│ - Smaller images often cache better │\n│ - Multi-stage improves both size and security │\n│ - Good layer order helps cache AND size │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Deep Dive\n\n### Layer Ordering: The Foundation\n\n**The Rule:** Order instructions from least to most frequently changing.\n\n```dockerfile\n# ❌ Bad order - any code change rebuilds everything\nFROM node:20\nWORKDIR /app\nCOPY . . # Changes often\nRUN npm install # Expensive, rebuilds every time\nCMD [\"npm\", \"start\"]\n\n# ✅ Good order - code changes don't affect npm install\nFROM node:20\nWORKDIR /app\nCOPY package*.json ./ # Changes rarely\nRUN npm install # Cached most of the time\nCOPY . . # Changes often, but cheap\nCMD [\"npm\", \"start\"]\n```\n\n**The general pattern:**\n\n```dockerfile\n# 1. Base image (changes rarely)\nFROM base:version\n\n# 2. System dependencies (changes rarely)\nRUN apt-get update && apt-get install -y ...\n\n# 3. Dependency files (changes sometimes)\nCOPY package.json requirements.txt go.mod ./\n\n# 4. Install dependencies (cached when dep files unchanged)\nRUN npm install / pip install / go mod download\n\n# 5. Application code (changes frequently)\nCOPY . .\n\n# 6. Build step (if needed)\nRUN npm run build\n\n# 7. Runtime configuration (changes rarely)\nEXPOSE 8080\nCMD [\"...\"]\n```\n\n### Combining RUN Instructions\n\n**Why combine?** Each RUN creates a layer. Temporary files in early layers persist in image even if deleted later.\n\n```dockerfile\n# ❌ Bad - apt cache persists in first layer (100MB+)\nRUN apt-get update\nRUN apt-get install -y curl\nRUN apt-get clean\n\n# ✅ Good - clean in same layer, cache never stored\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends curl && \\\n apt-get clean && \\\n rm -rf /var/lib/apt/lists/*\n```\n\n**But don't over-combine:**\n\n```dockerfile\n# ❌ Over-combined - any change rebuilds everything\nRUN apt-get update && \\\n apt-get install -y curl && \\\n npm install && \\\n npm run build && \\\n npm prune --production\n\n# ✅ Logical groupings\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends curl && \\\n rm -rf /var/lib/apt/lists/*\n\nCOPY package*.json ./\nRUN npm ci\n\nCOPY . .\nRUN npm run build && npm prune --production\n```\n\n### .dockerignore Mastery\n\nThe `.dockerignore` file controls what enters the build context:\n\n```bash\n# Development files\nnode_modules\n__pycache__\n*.pyc\nvenv\n.venv\n\n# Version control\n.git\n.gitignore\n.gitattributes\n\n# IDE\n.idea\n.vscode\n*.swp\n*.swo\n.DS_Store\n\n# Test and coverage\ncoverage\n.coverage\nhtmlcov\n.pytest_cache\n.tox\ntest/\ntests/\n__tests__/\n*.test.js\n*.spec.js\n\n# Documentation\ndocs/\n*.md\n!README.md\n\n# Build artifacts\ndist\nbuild\n*.egg-info\n\n# Local configuration\n.env\n.env.*\n*.local\ndocker-compose*.yml\n\n# CI/CD\n.github\n.gitlab-ci.yml\n.travis.yml\nJenkinsfile\n\n# Logs\n*.log\nlogs/\n\n# Misc\nDockerfile*\nMakefile\n```\n\n**Advanced patterns:**\n\n```bash\n# Exclude everything, then include specific folders\n*\n!src/\n!package.json\n!package-lock.json\n\n# Exclude test files but keep test utilities\ntest/\ntests/\n*.test.js\n!src/testUtils/\n\n# Allow specific dotfiles\n.*\n!.npmrc\n```\n\n### Size Reduction Techniques\n\n#### 1. Choose the Right Base Image\n\n```bash\n# Image size comparison\n$ docker images | grep node\nnode:20 1.1GB\nnode:20-slim 250MB\nnode:20-alpine 180MB\n\n# For compiled languages\ngolang:1.21 800MB\ngolang:1.21-alpine 250MB\nscratch 0MB\n```\n\n**Decision tree:**\n\n```\nNeed glibc compatibility?\n├── Yes → debian-slim or ubuntu minimal\n└── No → Alpine (smaller, but uses musl libc)\n\nCompiled static binary?\n├── Yes → scratch or distroless\n└── No → Use language's slim/alpine variant\n\nNeed debugging tools in prod?\n├── Yes → debian-slim (has shell, standard tools)\n└── No → distroless (no shell, minimal attack surface)\n```\n\n#### 2. Remove Unnecessary Files in Same Layer\n\n```dockerfile\n# ❌ Removal in different layer doesn't reduce size\nRUN npm install\nRUN rm -rf /root/.npm\n\n# ✅ Removal in same layer\nRUN npm install && \\\n rm -rf /root/.npm /root/.cache\n```\n\n#### 3. Multi-Stage Builds\n\n```dockerfile\n# Build stage - large, has all tools\nFROM node:20 AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\nRUN npm run build\n\n# Production stage - minimal\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCOPY --from=builder /app/node_modules ./node_modules\nCOPY package.json ./\nUSER node\nCMD [\"node\", \"dist/index.js\"]\n```\n\n#### 4. Language-Specific Optimizations\n\n**Node.js:**\n\n```dockerfile\n# Use npm ci instead of npm install (faster, more reliable)\nRUN npm ci --only=production\n\n# Or use pnpm for smaller node_modules\nRUN corepack enable && pnpm install --prod --frozen-lockfile\n\n# Remove npm cache\nRUN npm cache clean --force\n```\n\n**Python:**\n\n```dockerfile\n# Don't write .pyc files\nENV PYTHONDONTWRITEBYTECODE=1\nENV PYTHONUNBUFFERED=1\n\n# Install without cache\nRUN pip install --no-cache-dir -r requirements.txt\n\n# Or use pip-tools for reproducibility\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n```\n\n**Java:**\n\n```dockerfile\n# Multi-stage for JAR\nFROM eclipse-temurin:21-jdk AS builder\nCOPY . .\nRUN ./gradlew build -x test\n\nFROM eclipse-temurin:21-jre-alpine\nCOPY --from=builder /app/build/libs/*.jar app.jar\nENTRYPOINT [\"java\", \"-jar\", \"app.jar\"]\n\n# Even smaller with jlink custom runtime\nFROM eclipse-temurin:21-jdk AS builder\nRUN jlink --add-modules java.base,java.logging \\\n --strip-debug --no-header-files --no-man-pages \\\n --output /custom-jre\n\nFROM debian:bookworm-slim\nCOPY --from=builder /custom-jre /opt/java\nCOPY --from=builder /app/build/libs/*.jar app.jar\nENTRYPOINT [\"/opt/java/bin/java\", \"-jar\", \"app.jar\"]\n```\n\n**Go:**\n\n```dockerfile\n# Produces small static binary\nFROM golang:1.21-alpine AS builder\nWORKDIR /app\nCOPY go.* ./\nRUN go mod download\nCOPY . .\nRUN CGO_ENABLED=0 GOOS=linux go build -ldflags=\"-s -w\" -o /app/server\n\n# Scratch = empty image\nFROM scratch\nCOPY --from=builder /app/server /server\nCOPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/\nENTRYPOINT [\"/server\"]\n```\n\n### Cache Optimization Strategies\n\n#### Split Dependency Installation\n\n```dockerfile\n# Python: Split requirements for better caching\nCOPY requirements/base.txt requirements/base.txt\nRUN pip install -r requirements/base.txt\n\nCOPY requirements/production.txt requirements/production.txt\nRUN pip install -r requirements/production.txt\n\nCOPY . .\n```\n\n#### Use BuildKit Cache Mounts\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\n# Node.js with persistent npm cache\nRUN --mount=type=cache,target=/root/.npm \\\n npm ci --only=production\n\n# Python with pip cache\nRUN --mount=type=cache,target=/root/.cache/pip \\\n pip install -r requirements.txt\n\n# apt-get with persistent cache\nRUN --mount=type=cache,target=/var/cache/apt \\\n --mount=type=cache,target=/var/lib/apt \\\n apt-get update && apt-get install -y curl\n```\n\n#### Cache Busting When Needed\n\n```dockerfile\n# Force rebuild from specific point\nARG CACHE_BUST=1\nRUN echo \"Cache bust: $CACHE_BUST\" && \\\n apt-get update && apt-get install -y curl\n\n# Usage: docker build --build-arg CACHE_BUST=$(date +%s) .\n```\n\n### Platform-Specific Patterns\n\n#### Node.js Complete Example\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\nFROM node:20-alpine AS deps\nWORKDIR /app\nCOPY package*.json ./\nRUN --mount=type=cache,target=/root/.npm \\\n npm ci --only=production\n\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN --mount=type=cache,target=/root/.npm \\\n npm ci\nCOPY . .\nRUN npm run build\n\nFROM node:20-alpine\nWORKDIR /app\nENV NODE_ENV=production\n\n# Security: run as non-root\nRUN addgroup -g 1001 -S nodejs && \\\n adduser -S nextjs -u 1001\n\nCOPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules\nCOPY --from=builder --chown=nextjs:nodejs /app/dist ./dist\nCOPY --chown=nextjs:nodejs package.json ./\n\nUSER nextjs\nEXPOSE 3000\nCMD [\"node\", \"dist/index.js\"]\n```\n\n#### Python Complete Example\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\nFROM python:3.11-slim AS builder\nWORKDIR /app\n\nENV PYTHONDONTWRITEBYTECODE=1\nENV PYTHONUNBUFFERED=1\n\n# Install build dependencies\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends gcc libpq-dev && \\\n rm -rf /var/lib/apt/lists/*\n\n# Create virtual environment\nRUN python -m venv /opt/venv\nENV PATH=\"/opt/venv/bin:$PATH\"\n\nCOPY requirements.txt .\nRUN --mount=type=cache,target=/root/.cache/pip \\\n pip install -r requirements.txt\n\nFROM python:3.11-slim\nWORKDIR /app\n\n# Runtime dependencies only\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends libpq5 && \\\n rm -rf /var/lib/apt/lists/*\n\n# Copy virtual environment\nCOPY --from=builder /opt/venv /opt/venv\nENV PATH=\"/opt/venv/bin:$PATH\"\n\n# Non-root user\nRUN useradd --create-home appuser\nUSER appuser\n\nCOPY --chown=appuser:appuser . .\n\nEXPOSE 8000\nCMD [\"gunicorn\", \"--bind\", \"0.0.0.0:8000\", \"app:app\"]\n```\n\n#### Java Spring Boot Example\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\nFROM eclipse-temurin:21-jdk-alpine AS builder\nWORKDIR /app\n\n# Gradle wrapper\nCOPY gradle gradle\nCOPY gradlew build.gradle.kts settings.gradle.kts ./\n\n# Download dependencies first (cached)\nRUN --mount=type=cache,target=/root/.gradle \\\n ./gradlew dependencies --no-daemon\n\nCOPY src src\nRUN --mount=type=cache,target=/root/.gradle \\\n ./gradlew build -x test --no-daemon\n\n# Extract layers for better caching\nRUN java -Djarmode=layertools -jar build/libs/*.jar extract\n\nFROM eclipse-temurin:21-jre-alpine\nWORKDIR /app\n\n# Security\nRUN addgroup -g 1001 -S spring && \\\n adduser -S spring -u 1001 -G spring\n\n# Copy layers in order of change frequency\nCOPY --from=builder /app/dependencies/ ./\nCOPY --from=builder /app/spring-boot-loader/ ./\nCOPY --from=builder /app/snapshot-dependencies/ ./\nCOPY --from=builder /app/application/ ./\n\nUSER spring\nEXPOSE 8080\nENTRYPOINT [\"java\", \"org.springframework.boot.loader.launch.JarLauncher\"]\n```\n\n### Analyzing and Measuring\n\n```bash\n# See layer sizes\ndocker history myimage\n\n# Detailed analysis with dive\ndive myimage\n# Shows:\n# - Layer contents\n# - Wasted space\n# - Efficiency score\n\n# Compare images\ndocker images | grep myimage\ndocker system df -v\n\n# Find large files in image\ndocker run --rm myimage find / -type f -size +10M 2>/dev/null\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: COPY Before Dependencies\n\n```dockerfile\n# ❌ Any file change rebuilds dependencies\nCOPY . .\nRUN npm install\n\n# ✅ Dependencies cached unless package.json changes\nCOPY package*.json ./\nRUN npm install\nCOPY . .\n```\n\n### Mistake 2: Not Cleaning Up in Same Layer\n\n```dockerfile\n# ❌ 200MB apt cache persists in layer 1\nRUN apt-get update && apt-get install -y build-essential\nRUN rm -rf /var/lib/apt/lists/*\n\n# ✅ Clean in same layer, cache never stored\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends build-essential && \\\n rm -rf /var/lib/apt/lists/*\n```\n\n### Mistake 3: Installing Dev Dependencies in Production\n\n```dockerfile\n# ❌ Includes jest, eslint, etc.\nRUN npm install\n\n# ✅ Production only\nRUN npm ci --only=production\n# or\nRUN npm ci && npm prune --production\n```\n\n### Mistake 4: Using :latest Tag\n\n```dockerfile\n# ❌ Unpredictable, changes without notice\nFROM node:latest\n\n# ✅ Specific version\nFROM node:20.10-alpine\n# or with digest (truly immutable)\nFROM node:20@sha256:abc123...\n```\n\n---\n\n## 🐛 Debug This: The Unchanging Cache\n\nA developer reports: \"I changed my code but Docker keeps using cached layers. Even `npm run build` shows cached!\"\n\n```dockerfile\nFROM node:20\nWORKDIR /app\nCOPY package*.json ./\nRUN npm install\nCOPY . .\nRUN npm run build\nCMD [\"node\", \"dist/index.js\"]\n```\n\n```bash\n$ docker build -t myapp .\n# ... Step 4/6 : COPY . .\n# ---> Using cache\n# ... Step 5/6 : RUN npm run build\n# ---> Using cache\n\n# But I changed src/index.js!\n```\n\n**Why does cache hit even though source code changed?**\n\n---\n\n**✅ Solution:**\n\nSeveral possible causes:\n\n**Cause 1: .dockerignore excluding source files**\n\n```bash\n# Check .dockerignore\ncat .dockerignore\n# src/ ← Oops! Source is excluded\n```\n\n**Cause 2: Build from wrong context**\n\n```bash\n# Building from parent directory\ncd ..\ndocker build -f project/Dockerfile .\n# Context is parent directory, doesn't see changes in project/\n```\n\n**Cause 3: Docker BuildKit cache export/import**\n\n```bash\n# CI might be using external cache\ndocker build --cache-from=registry.com/myapp:cache .\n# External cache doesn't know about local changes\n```\n\n**Cause 4: File not actually saved**\n\n```bash\n# Verify file is actually changed\ngit status\ncat src/index.js\n# Sometimes IDEs don't save automatically\n```\n\n**Cause 5: Mounted volume shadowing**\n\n```bash\n# Not during build, but at runtime\ndocker run -v $(pwd)/dist:/app/dist myapp\n# Old dist/ shadows built dist/\n```\n\n**Debug steps:**\n\n```bash\n# 1. Verify file is in context\ntar -cvf - --exclude-from=.dockerignore . | tar -tvf - | grep index.js\n\n# 2. Force no-cache build to test\ndocker build --no-cache -t myapp .\n\n# 3. Check file hash that Docker sees\ndocker build --progress=plain -t myapp . 2>&1 | grep -A2 \"COPY \\.\"\n\n# 4. Try explicit COPY\n# Change: COPY . .\n# To: COPY src/ ./src/\n```\n\n**Most common cause:** `.dockerignore` pattern matching more than intended, or building from wrong context.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Measure Layer Impact\n⭐ Difficulty: Easy | ⏱️ Time: 15 minutes\n\n```bash\n# Create test project\nmkdir layer-test && cd layer-test\n\n# Create Dockerfile with multiple approaches\ncat > Dockerfile.separate << 'EOF'\nFROM ubuntu:22.04\nRUN apt-get update\nRUN apt-get install -y curl\nRUN apt-get install -y wget\nRUN apt-get install -y vim\nRUN apt-get clean\nRUN rm -rf /var/lib/apt/lists/*\nEOF\n\ncat > Dockerfile.combined << 'EOF'\nFROM ubuntu:22.04\nRUN apt-get update && \\\n apt-get install -y --no-install-recommends curl wget vim && \\\n apt-get clean && \\\n rm -rf /var/lib/apt/lists/*\nEOF\n\n# Build both\ndocker build -f Dockerfile.separate -t test:separate .\ndocker build -f Dockerfile.combined -t test:combined .\n\n# Compare sizes\ndocker images | grep test\n\n# Analyze with dive\ndive test:separate\ndive test:combined\n\n# Questions:\n# - How much smaller is combined?\n# - Where is the wasted space in separate?\n```\n\n---\n\n### Exercise 2: Optimize a Node.js App\n⭐⭐ Difficulty: Medium | ⏱️ Time: 25 minutes\n\n```bash\nmkdir node-optimize && cd node-optimize\n\n# Create package.json\ncat > package.json << 'EOF'\n{\n \"name\": \"test-app\",\n \"version\": \"1.0.0\",\n \"scripts\": {\n \"start\": \"node index.js\",\n \"test\": \"jest\"\n },\n \"dependencies\": {\n \"express\": \"^4.18.2\"\n },\n \"devDependencies\": {\n \"jest\": \"^29.7.0\"\n }\n}\nEOF\n\n# Create simple app\necho 'console.log(\"Hello\")' > index.js\n\n# Unoptimized Dockerfile\ncat > Dockerfile.bad << 'EOF'\nFROM node:20\nWORKDIR /app\nCOPY . .\nRUN npm install\nCMD [\"npm\", \"start\"]\nEOF\n\n# Your task: Create Dockerfile.good that:\n# 1. Uses alpine base\n# 2. Proper layer ordering\n# 3. Production dependencies only\n# 4. Non-root user\n# 5. Proper .dockerignore\n\n# Build and compare\ndocker build -f Dockerfile.bad -t node:bad .\ndocker build -f Dockerfile.good -t node:good .\n\ndocker images | grep node\n```\n\n---\n\n### Exercise 3: Multi-Stage for Go\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n```bash\nmkdir go-optimize && cd go-optimize\n\n# Create Go app\ncat > main.go << 'EOF'\npackage main\n\nimport (\n \"fmt\"\n \"net/http\"\n)\n\nfunc main() {\n http.HandleFunc(\"/\", func(w http.ResponseWriter, r *http.Request) {\n fmt.Fprintf(w, \"Hello, World!\")\n })\n fmt.Println(\"Server starting on :8080\")\n http.ListenAndServe(\":8080\", nil)\n}\nEOF\n\ncat > go.mod << 'EOF'\nmodule myapp\ngo 1.21\nEOF\n\n# Single-stage Dockerfile\ncat > Dockerfile.single << 'EOF'\nFROM golang:1.21\nWORKDIR /app\nCOPY . .\nRUN go build -o server .\nEXPOSE 8080\nCMD [\"./server\"]\nEOF\n\n# Create multi-stage Dockerfile that:\n# 1. Uses golang:alpine for building\n# 2. Creates static binary (CGO_ENABLED=0)\n# 3. Uses scratch as final base\n# 4. Includes CA certificates for HTTPS\n\n# Build and compare\ndocker build -f Dockerfile.single -t go:single .\n# docker build -f Dockerfile.multi -t go:multi .\n\ndocker images | grep go\n```\n\n---\n\n### Exercise 4: BuildKit Cache Mounts\n⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 25 minutes\n\n```bash\nmkdir cache-test && cd cache-test\n\ncat > requirements.txt << 'EOF'\nflask==3.0.0\nrequests==2.31.0\nnumpy==1.26.0\npandas==2.1.0\nscikit-learn==1.3.0\nEOF\n\n# Without cache mount\ncat > Dockerfile.nocache << 'EOF'\nFROM python:3.11-slim\nWORKDIR /app\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\nCOPY . .\nCMD [\"python\", \"app.py\"]\nEOF\n\n# With cache mount\ncat > Dockerfile.cached << 'EOF'\n# syntax=docker/dockerfile:1\nFROM python:3.11-slim\nWORKDIR /app\nCOPY requirements.txt .\nRUN --mount=type=cache,target=/root/.cache/pip \\\n pip install -r requirements.txt\nCOPY . .\nCMD [\"python\", \"app.py\"]\nEOF\n\n# Test 1: Build both from scratch\ndocker build --no-cache -f Dockerfile.nocache -t py:nocache .\ndocker build --no-cache -f Dockerfile.cached -t py:cached .\n\n# Test 2: Add a dependency and rebuild\necho \"flask-cors==4.0.0\" >> requirements.txt\ntime docker build -f Dockerfile.nocache -t py:nocache .\ntime docker build -f Dockerfile.cached -t py:cached .\n\n# Questions:\n# - How much faster is the cached version on rebuild?\n# - What happens if you docker system prune?\n```\n\n---\n\n### Exercise 5: Optimize Real-World Dockerfile\n⭐⭐⭐⭐ Difficulty: Expert | ⏱️ Time: 30 minutes\n\nGiven this inefficient Dockerfile, optimize it:\n\n```dockerfile\nFROM ubuntu:22.04\n\n# Install everything\nRUN apt-get update\nRUN apt-get install -y python3 python3-pip nodejs npm git curl\n\nWORKDIR /app\n\n# Copy everything\nCOPY . .\n\n# Install Python deps\nRUN pip3 install flask requests gunicorn pytest black pylint\n\n# Install Node deps\nRUN npm install\n\n# Build frontend\nRUN npm run build\n\n# Run tests\nRUN pytest\n\nCMD [\"gunicorn\", \"--bind\", \"0.0.0.0:8000\", \"app:app\"]\n```\n\n**Your optimized version should:**\n1. Use multi-stage build\n2. Separate frontend and backend builds\n3. Only production dependencies in final image\n4. Proper layer ordering\n5. No test frameworks in production\n6. Minimal base image\n7. Non-root user\n8. BuildKit cache mounts\n\n**Target:** Under 200MB final image\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Q1: How would you reduce a 2GB Docker image to under 200MB?\n\n**Strong Answer:**\n\n\"I'd take a systematic approach:\n\n**1. Analyze the current image:**\n```bash\ndocker history myimage --no-trunc\ndive myimage\n```\n\n**2. Identify bloat sources (usually):**\n- Build tools in runtime image\n- Development dependencies\n- Package manager caches\n- Unnecessary base image components\n- Test files, documentation\n\n**3. Apply multi-stage builds:**\n```dockerfile\nFROM node:20 AS builder\n# Build here with all tools\n\nFROM node:20-alpine\n# Only copy artifacts\nCOPY --from=builder /app/dist ./dist\n```\n\n**4. Switch to minimal base:**\n- node:20 (1GB) → node:20-alpine (180MB)\n- python:3.11 (900MB) → python:3.11-slim (150MB)\n- For compiled langs → scratch or distroless\n\n**5. Clean in same layer:**\n```dockerfile\nRUN apt-get update && apt-get install -y pkg && \\\n rm -rf /var/lib/apt/lists/*\n```\n\n**6. Production deps only:**\n```bash\nnpm ci --only=production\npip install --no-cache-dir\n```\n\n**7. Add proper .dockerignore:**\n- node_modules, .git, tests, docs\n\nI've done this optimization many times. The biggest wins usually come from multi-stage builds and choosing the right base image.\"\n\n### Q2: Explain Docker layer caching and how to optimize for it.\n\n**Strong Answer:**\n\n\"Docker's layer cache works by comparing the instruction and its inputs to previously built layers. For COPY/ADD, it hashes file contents. For RUN, it matches the exact command string.\n\n**Key cache behaviors:**\n1. Cache invalidation cascades - if layer N misses, all subsequent layers rebuild\n2. Files, not timestamps - Docker compares file content hashes\n3. String matching for RUN - even whitespace differences cause miss\n\n**Optimization strategies:**\n\n**Order by change frequency:**\n```dockerfile\n# Rarely changes\nFROM node:20\nRUN apt-get update && apt-get install -y curl\n\n# Sometimes changes\nCOPY package*.json ./\nRUN npm install\n\n# Frequently changes\nCOPY . .\n```\n\n**Split dependencies:**\n```dockerfile\n# Cache dependencies separately from app code\nCOPY package.json package-lock.json ./\nRUN npm ci\nCOPY . .\n```\n\n**Use BuildKit cache mounts:**\n```dockerfile\nRUN --mount=type=cache,target=/root/.npm npm ci\n```\nPersists cache across builds, even when layer rebuilds.\n\n**Avoid cache-busting patterns:**\n```dockerfile\n# ❌ Timestamp changes on every build\nRUN echo $(date) && npm install\n\n# ✅ Stable\nRUN npm install\n```\n\nFor CI, I'd also set up external cache with `--cache-from` and `--cache-to` to share cache between builds.\"\n\n### Q3: What's the difference between COPY and ADD, and when would you use each?\n\n**Strong Answer:**\n\n\"COPY and ADD both copy files from context into the image, but ADD has extra features:\n\n**COPY (preferred):**\n- Simple file/directory copy\n- Preserves permissions\n- Invalidates cache when content changes\n- Transparent, predictable\n\n**ADD extras:**\n- Auto-extracts tar archives (tar, gzip, bzip2, xz)\n- Can download from URLs\n- More complex, less predictable\n\n**When to use ADD:**\n```dockerfile\n# Extracting archive\nADD app.tar.gz /app/\n\n# Although even this is debatable - being explicit is often better:\nCOPY app.tar.gz /tmp/\nRUN tar -xzf /tmp/app.tar.gz -C /app && rm /tmp/app.tar.gz\n```\n\n**Don't use ADD for:**\n```dockerfile\n# ❌ URL download (can't cache, no checksum verification)\nADD https://example.com/file.zip /app/\n\n# ✅ Better: explicit download with verification\nRUN curl -fsSL https://example.com/file.zip -o file.zip && \\\n echo 'expected-sha256 file.zip' | sha256sum -c - && \\\n unzip file.zip && rm file.zip\n```\n\n**My rule:** Always use COPY unless you specifically need ADD's tar extraction feature. For URLs, use RUN with curl/wget for better control and caching.\"\n\n### Q4: How do you handle secrets during Docker build?\n\n**Strong Answer:**\n\n\"Secrets in Docker builds are tricky because anything in a layer is extractable. Here are the approaches:\n\n**❌ Never do this:**\n```dockerfile\nARG NPM_TOKEN\nRUN echo \"//registry.npmjs.org/:_authToken=${NPM_TOKEN}\" >> ~/.npmrc\n# Token visible in: docker history, layer extraction\n```\n\n**✅ BuildKit secrets (recommended):**\n```dockerfile\n# syntax=docker/dockerfile:1\nRUN --mount=type=secret,id=npmrc,target=/root/.npmrc \\\n npm install\n```\n```bash\ndocker build --secret id=npmrc,src=.npmrc .\n```\nSecret is available during build but not stored in any layer.\n\n**✅ Multi-stage isolation:**\n```dockerfile\nFROM node:20 AS builder\nARG NPM_TOKEN\nRUN echo \"//registry.npmjs.org/:_authToken=${NPM_TOKEN}\" >> ~/.npmrc\nRUN npm install\nRUN rm ~/.npmrc\n\nFROM node:20-alpine\nCOPY --from=builder /app/node_modules ./node_modules\n# Token never in final image\n```\nStill visible in builder stage history, but not in final image.\n\n**✅ SSH forwarding for git:**\n```dockerfile\nRUN --mount=type=ssh git clone git@github.com:private/repo.git\n```\n```bash\ndocker build --ssh default .\n```\n\n**Runtime secrets:**\n- Use Docker secrets (Swarm) or Kubernetes secrets\n- Mount as volume/file, never ENV\n- Inject via orchestrator, not Dockerfile\"\n\n### Q5: How do you debug slow Docker builds?\n\n**Strong Answer:**\n\n\"I follow a systematic approach:\n\n**1. Enable verbose output:**\n```bash\nDOCKER_BUILDKIT=1 docker build --progress=plain .\n```\nShows timing for each step.\n\n**2. Check build context:**\n```bash\ntar -cvf - --exclude-from=.dockerignore . | wc -c\n```\nLarge context (>100MB) means slow transfer. Add to .dockerignore.\n\n**3. Identify cache misses:**\n```\n#7 [4/6] RUN npm install\n#7 DONE 45.2s ← Cache miss, slow step\n```\nCheck why it's not caching - file changes? Bad ordering?\n\n**4. Analyze layer timing:**\n```bash\ndocker build --progress=plain . 2>&1 | grep -E '^#[0-9]+ DONE'\n```\n\n**5. Common culprits:**\n- Large context (add .dockerignore)\n- Cache misses (fix layer ordering)\n- Large dependencies (use cache mounts)\n- Slow network (configure proxy/mirror)\n- Build commands (use parallel make)\n\n**6. Use BuildKit cache mounts:**\n```dockerfile\nRUN --mount=type=cache,target=/root/.npm npm ci\n```\n\n**7. Parallelize stages:**\nMulti-stage builds run independent stages in parallel.\n\n**8. Consider build cache sharing:**\n```bash\ndocker build --cache-from registry/app:cache --cache-to registry/app:cache .\n```\n\nI'd document findings and create team guidelines to prevent slow build regressions.\"\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Core Optimization Principles\n\n| Principle | Implementation |\n|-----------|---------------|\n| Layer ordering | Least → most frequently changing |\n| Single-layer cleanup | Combine RUN with cleanup |\n| Multi-stage | Build stage → minimal runtime stage |\n| Proper base image | Alpine/slim/distroless |\n| Cache mounts | `--mount=type=cache` for package managers |\n\n### Size Reduction Checklist\n\n- [ ] Using alpine/slim/distroless base\n- [ ] Multi-stage build separating build from runtime\n- [ ] Production dependencies only\n- [ ] Cleaning package manager cache in same RUN\n- [ ] Proper .dockerignore\n- [ ] No test files/frameworks in production\n\n### Cache Optimization Checklist\n\n- [ ] Dependencies copied before code\n- [ ] Dependency install before full COPY\n- [ ] Using BuildKit cache mounts\n- [ ] Not using timestamps in builds\n- [ ] CI using `--cache-from/--cache-to`\n\n---\n\n## 📋 Quick Reference\n\n### Dockerfile Patterns\n\n```dockerfile\n# Proper ordering\nFROM base\nRUN system-deps # Rarely changes\nCOPY deps-manifest # Sometimes changes\nRUN install-deps # Cached by deps-manifest\nCOPY code # Frequently changes\nRUN build # Runs when code changes\nCMD runtime\n\n# Multi-stage template\nFROM full-image AS builder\n# Build steps here\n\nFROM minimal-image\nCOPY --from=builder /app/artifact /app/\nUSER nonroot\nCMD [\"./artifact\"]\n\n# BuildKit cache mount\nRUN --mount=type=cache,target=/cache-dir command\n\n# BuildKit secret\nRUN --mount=type=secret,id=secretid,target=/path command\n```\n\n### Size Comparison\n\n| Base Image | Size |\n|------------|------|\n| ubuntu:22.04 | 77MB |\n| debian:bookworm-slim | 74MB |\n| alpine:3.18 | 7MB |\n| gcr.io/distroless/static | 2MB |\n| scratch | 0MB |\n\n### Common Commands\n\n```bash\n# Analyze image\ndocker history IMAGE\ndive IMAGE\n\n# Check image size\ndocker images IMAGE\n\n# Check build context\ntar -cvf - --exclude-from=.dockerignore . | wc -c\n\n# Build with timing\ndocker build --progress=plain .\n```\n\n---\n\n## 📅 Review Schedule\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review layer ordering principles | 10 min |\n| Day 3 | Audit a Dockerfile in your project | 15 min |\n| Day 7 | Do Exercise 2 (Node.js optimization) | 25 min |\n| Day 14 | Implement BuildKit cache mounts | 20 min |\n| Day 30 | Optimize a production Dockerfile | 30 min |\n\n---\n\n## 📚 Series Navigation\n\n| Previous | Current | Next |\n|----------|---------|------|\n| [Part 4: Networking Internals](docker-part-4-networking-internals) | **Part 5: Dockerfile Optimization** | [Part 6: Multi-Stage Builds](docker-part-6-multi-stage-builds) |\n\n**Docker Compendium Series:**\n- [Part 0: How to Use This Series](docker-part-0-how-to-use-this-series)\n- [Part 1: Container Internals](docker-part-1-container-internals)\n- [Part 2: Image Anatomy](docker-part-2-image-anatomy)\n- [Part 3: Build Process Deep Dive](docker-part-3-build-process)\n- [Part 4: Networking Internals](docker-part-4-networking-internals)\n- **Part 5: Dockerfile Optimization Patterns** ← You are here\n- [Part 6: Multi-Stage Builds: Beyond Basics](docker-part-6-multi-stage-builds)\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:25.423856Z","createdAt","2026-06-10T07:19:25.424582Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",19,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Devops","readingTime","seriesId","seriesOrder",5,"author",{"_33":57,"_96":59,"_97":98,"_99":100,"_101":-5,"_102":-5,"_103":-5,"_104":-5,"_105":-5},"category",{"_33":92,"_74":61,"_37":93,"_77":94,"_95":-5},"tags",[80,81,82],"series",{"_33":57,"_74":75,"_37":76,"_77":78,"_79":24},"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",{"_33":89,"_74":90,"_37":91},{"_33":86,"_74":87,"_37":88},{"_33":83,"_74":84,"_37":85},224,"Optimization","optimization",227,"Dockerfile","dockerfile",213,"Docker","docker",7,"devops","Category for Devops","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl",56,"Multi-Stage Builds: Beyond Basics","docker-part-6-multi-stage-builds","Advanced multi-stage patterns, secrets, and testing stages","# Docker Compendium Part 6: Multi-Stage Builds - Beyond Basics\n\nMulti-stage builds are Docker's answer to the \"build vs runtime\" dilemma. You've seen the basics - separate build and runtime stages. This article goes deeper: parallel stages, conditional builds, testing stages, and patterns that make complex builds manageable.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Topic | Advanced multi-stage patterns, testing stages, secrets handling |\n| Complexity | Intermediate-Advanced |\n| Prerequisites | Part 3 (Build Process), Part 5 (Optimization) |\n| Key Insight | Stages are independent build graphs - use them for more than size |\n| Time to Master | 2-3 hours |\n\n---\n\n## 🎯 What You'll Learn\n\n- **Advanced stage patterns** - parallel builds, conditional stages, shared bases\n- **Testing in builds** - test stages, fail-fast builds, coverage extraction\n- **Secrets management** - build-time secrets that never reach images\n- **Dynamic staging** - building different outputs from same Dockerfile\n- **Real-world patterns** - monorepo builds, polyglot applications\n\n---\n\n## 🔥 Production Story: The Leaked Credentials\n\nA security audit found NPM tokens in a production image. The team was confused - they had deleted the `.npmrc` file after npm install.\n\n**The Dockerfile:**\n\n```dockerfile\nFROM node:20\nARG NPM_TOKEN\nRUN echo \"//registry.npmjs.org/:_authToken=${NPM_TOKEN}\" >> ~/.npmrc\nRUN npm install\nRUN rm ~/.npmrc # \"Cleaned up!\"\nCOPY . .\nCMD [\"node\", \"index.js\"]\n```\n\n**The audit finding:**\n\n```bash\n# Extract image layers\ndocker save myapp | tar -xf -\n\n# Find the token in layer 2\ncat abc123/layer.tar | tar -xf - -O root/.npmrc\n# //registry.npmjs.org/:_authToken=npm_SECRETTOKEN123\n```\n\nThe `.npmrc` was deleted in layer 4, but it still existed in layer 2. Docker layers are additive - deletion only hides, never removes.\n\n**The fix using multi-stage:**\n\n```dockerfile\n# Stage 1: Install with secrets (never shipped)\nFROM node:20 AS deps\nRUN --mount=type=secret,id=npmrc,target=/root/.npmrc \\\n npm install\n\n# Stage 2: Production (no secrets ever present)\nFROM node:20-alpine\nCOPY --from=deps /app/node_modules ./node_modules\nCOPY . .\nCMD [\"node\", \"index.js\"]\n```\n\n**Lesson:** Multi-stage builds aren't just for size reduction - they're a security boundary. Secrets in build stages never reach the final image.\n\n---\n\n## 🧠 Mental Model: Stages as Build Graphs\n\n```\n┌─────────────────────────────────────────────────────────────────────────┐\n│ MULTI-STAGE BUILD GRAPH │\n│ │\n│ Traditional view: Linear pipeline │\n│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │\n│ │build│ → │test │ → │lint │ → │final│ │\n│ └─────┘ └─────┘ └─────┘ └─────┘ │\n│ │\n│ Reality: Directed Acyclic Graph (DAG) │\n│ │\n│ ┌─────────┐ │\n│ │ base │ ← Shared foundation │\n│ └────┬────┘ │\n│ │ │\n│ ├──────────────┬──────────────┐ │\n│ ▼ ▼ ▼ │\n│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │\n│ │ deps │ │ test │ │ lint │ ← Run in parallel! │\n│ └────┬────┘ └────┬────┘ └────┬────┘ │\n│ │ │ │ │\n│ │ ▼ ▼ │\n│ │ ┌─────────┐ ┌─────────┐ │\n│ │ │ report │ │ check │ ← Optional outputs │\n│ │ └─────────┘ └─────────┘ │\n│ │ │\n│ └──────────────┬────────────────── │\n│ ▼ │\n│ ┌─────────┐ │\n│ │ final │ ← Production image │\n│ └─────────┘ │\n│ │\n│ BuildKit builds independent branches in PARALLEL │\n└─────────────────────────────────────────────────────────────────────────┘\n```\n\n**Key insight:** Stages without dependencies on each other build simultaneously. Design your Dockerfile to maximize parallelism.\n\n---\n\n## 🔬 Deep Dive\n\n### Stage Fundamentals Revisited\n\n```dockerfile\n# Each FROM starts a new stage\nFROM node:20 AS builder # Stage 0, named \"builder\"\nWORKDIR /app\nRUN npm install\n\nFROM node:20 AS tester # Stage 1, named \"tester\"\nWORKDIR /app\nRUN npm test\n\nFROM node:20-alpine # Stage 2, unnamed (final)\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\n```\n\n**Stage properties:**\n- Each stage starts fresh (empty filesystem)\n- Stages can be named (`AS name`) or numbered (0, 1, 2...)\n- Only the final stage becomes the output image\n- `COPY --from=` extracts files from other stages\n- ARG values reset after each FROM\n\n### Parallel Stage Execution\n\nBuildKit automatically parallelizes independent stages:\n\n```dockerfile\n# These run in PARALLEL\nFROM node:20 AS frontend\nWORKDIR /frontend\nCOPY frontend/package*.json ./\nRUN npm ci\nCOPY frontend/ .\nRUN npm run build\n\nFROM python:3.11 AS backend # Parallel with frontend\nWORKDIR /backend\nCOPY backend/requirements.txt .\nRUN pip install -r requirements.txt\nCOPY backend/ .\nRUN python -m pytest\n\nFROM golang:1.21 AS tools # Parallel with frontend AND backend\nWORKDIR /tools\nCOPY tools/ .\nRUN go build -o /bin/migrate ./cmd/migrate\n\n# Final stage waits for all dependencies\nFROM nginx:alpine\nCOPY --from=frontend /frontend/dist /usr/share/nginx/html\nCOPY --from=backend /backend/static /usr/share/nginx/html/api\nCOPY --from=tools /bin/migrate /usr/local/bin/\n```\n\n**Execution timeline:**\n\n```\nTime ────────────────────────────────────────────────────────►\n\nfrontend: [npm ci]──────[build]─────────────────┐\n │\nbackend: [pip install]─[pytest]────────────────┼───┐\n │ │\ntools: [go build]────────────────────────────┼───┼──┐\n │ │ │\nfinal: └───┴──┴─[copy all]\n\nTotal time = max(frontend, backend, tools) + final copy\nNOT: frontend + backend + tools + final (sequential)\n```\n\n### Shared Base Stages\n\nAvoid duplicating common setup:\n\n```dockerfile\n# Shared base with common dependencies\nFROM node:20-alpine AS base\nWORKDIR /app\nRUN apk add --no-cache python3 make g++ # For native modules\n\n# Development dependencies\nFROM base AS deps-dev\nCOPY package*.json ./\nRUN npm ci\n\n# Production dependencies only\nFROM base AS deps-prod\nCOPY package*.json ./\nRUN npm ci --only=production\n\n# Build stage uses dev deps\nFROM deps-dev AS builder\nCOPY . .\nRUN npm run build\n\n# Test stage uses dev deps\nFROM deps-dev AS tester\nCOPY . .\nRUN npm test\n\n# Production uses prod deps + build output\nFROM base AS production\nCOPY --from=deps-prod /app/node_modules ./node_modules\nCOPY --from=builder /app/dist ./dist\nUSER node\nCMD [\"node\", \"dist/index.js\"]\n```\n\n### Testing Stages\n\n**Fail-fast testing:**\n\n```dockerfile\nFROM node:20 AS deps\nCOPY package*.json ./\nRUN npm ci\n\nFROM deps AS test\nCOPY . .\n# Build fails if tests fail\nRUN npm run test\n\nFROM deps AS lint\nCOPY . .\nRUN npm run lint\n\nFROM deps AS typecheck\nCOPY . .\nRUN npm run typecheck\n\n# Only builds if ALL checks pass\nFROM deps AS builder\nCOPY . .\nRUN npm run build\n\nFROM node:20-alpine\nCOPY --from=builder /app/dist ./dist\nCOPY --from=deps /app/node_modules ./node_modules\nCMD [\"node\", \"dist/index.js\"]\n```\n\n**Extract test artifacts:**\n\n```dockerfile\nFROM node:20 AS test\nCOPY . .\nRUN npm ci\nRUN npm test -- --coverage --coverageDirectory=/coverage\n\n# Extract coverage report\nFROM scratch AS coverage\nCOPY --from=test /coverage /\n\n# Usage:\n# docker build --target coverage -o ./coverage-report .\n```\n\n**Conditional test execution:**\n\n```dockerfile\nFROM node:20 AS base\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\n\n# Test stage - runs tests\nFROM base AS test\nRUN npm test\n\n# Build stage - doesn't depend on test\nFROM base AS builder\nRUN npm run build\n\n# Production - can optionally require test\nFROM node:20-alpine AS production\n# If you want tests required, add:\n# COPY --from=test /app/test-passed /tmp/\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n```\n\n```bash\n# Build without tests (faster for dev)\ndocker build --target production .\n\n# Build with tests required (CI)\ndocker build --target test . && docker build --target production .\n```\n\n### Secrets in Multi-Stage Builds\n\n**BuildKit secrets (recommended):**\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\nFROM node:20 AS deps\nWORKDIR /app\nCOPY package*.json ./\n\n# Secret available only during this RUN\nRUN --mount=type=secret,id=npmrc,target=/root/.npmrc \\\n npm ci\n\n# Production stage - secret never existed here\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=deps /app/node_modules ./node_modules\nCOPY . .\nCMD [\"node\", \"index.js\"]\n```\n\n```bash\n# Build with secret\ndocker build --secret id=npmrc,src=.npmrc -t myapp .\n```\n\n**SSH agent forwarding:**\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\nFROM golang:1.21 AS builder\nWORKDIR /app\n\n# Clone private repos using SSH\nRUN --mount=type=ssh \\\n git clone git@github.com:company/private-lib.git\n\nCOPY . .\nRUN go build -o /app/server\n\nFROM scratch\nCOPY --from=builder /app/server /server\nCMD [\"/server\"]\n```\n\n```bash\n# Build with SSH forwarding\ndocker build --ssh default -t myapp .\n```\n\n**Stage isolation for secrets:**\n\n```dockerfile\n# Build stage with secrets (discarded)\nFROM node:20 AS build-with-secrets\nARG NPM_TOKEN\nARG AWS_ACCESS_KEY\n\n# These secrets exist in this stage only\nRUN echo \"//registry.npmjs.org/:_authToken=${NPM_TOKEN}\" >> ~/.npmrc\nRUN aws s3 cp s3://private-bucket/config.json ./config.json\nRUN npm ci\n\n# Clean stage - copy only artifacts, not secrets\nFROM node:20-alpine AS production\nWORKDIR /app\n\n# Only node_modules copied, not .npmrc or AWS credentials\nCOPY --from=build-with-secrets /app/node_modules ./node_modules\nCOPY --from=build-with-secrets /app/config.json ./\n\nCOPY . .\nCMD [\"node\", \"index.js\"]\n```\n\n### Dynamic Stage Selection\n\n**Building different outputs:**\n\n```dockerfile\nFROM node:20 AS base\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\n\n# Development image with hot reload\nFROM base AS development\nRUN npm install -g nodemon\nCMD [\"nodemon\", \"src/index.js\"]\n\n# Production optimized\nFROM base AS builder\nRUN npm run build\nRUN npm prune --production\n\nFROM node:20-alpine AS production\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCOPY --from=builder /app/node_modules ./node_modules\nUSER node\nCMD [\"node\", \"dist/index.js\"]\n\n# Debug image with tools\nFROM production AS debug\nUSER root\nRUN apk add --no-cache curl vim strace\nUSER node\n```\n\n```bash\n# Build for different environments\ndocker build --target development -t myapp:dev .\ndocker build --target production -t myapp:prod .\ndocker build --target debug -t myapp:debug .\n```\n\n### Monorepo Patterns\n\n**Shared dependencies:**\n\n```\nmonorepo/\n├── packages/\n│ ├── common/\n│ ├── api/\n│ └── web/\n├── package.json\n└── Dockerfile\n```\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\n# Base with all workspace deps\nFROM node:20 AS base\nWORKDIR /app\nCOPY package*.json ./\nCOPY packages/common/package*.json ./packages/common/\nCOPY packages/api/package*.json ./packages/api/\nCOPY packages/web/package*.json ./packages/web/\nRUN npm ci\n\n# Build common first (dependency for others)\nFROM base AS common-builder\nCOPY packages/common/ ./packages/common/\nRUN npm run build --workspace=packages/common\n\n# Build API (parallel with web)\nFROM base AS api-builder\nCOPY --from=common-builder /app/packages/common/dist ./packages/common/dist\nCOPY packages/api/ ./packages/api/\nRUN npm run build --workspace=packages/api\n\n# Build Web (parallel with api)\nFROM base AS web-builder\nCOPY --from=common-builder /app/packages/common/dist ./packages/common/dist\nCOPY packages/web/ ./packages/web/\nRUN npm run build --workspace=packages/web\n\n# API production image\nFROM node:20-alpine AS api\nWORKDIR /app\nCOPY --from=api-builder /app/packages/api/dist ./dist\nCOPY --from=api-builder /app/node_modules ./node_modules\nCMD [\"node\", \"dist/index.js\"]\n\n# Web production image (static files)\nFROM nginx:alpine AS web\nCOPY --from=web-builder /app/packages/web/dist /usr/share/nginx/html\n```\n\n```bash\n# Build specific service\ndocker build --target api -t myapp-api .\ndocker build --target web -t myapp-web .\n```\n\n### COPY --from External Images\n\nYou can copy from any image, not just build stages:\n\n```dockerfile\nFROM node:20-alpine\n\n# Copy binary from another image\nCOPY --from=busybox:latest /bin/wget /usr/local/bin/wget\n\n# Copy config from official image\nCOPY --from=nginx:alpine /etc/nginx/nginx.conf /etc/nginx/\n\n# Copy tool from utility image\nCOPY --from=aquasec/trivy:latest /usr/local/bin/trivy /usr/local/bin/\n\n# Copy CA certificates (useful for scratch images)\nCOPY --from=alpine:latest /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/\n```\n\n### Build Arguments Across Stages\n\n```dockerfile\n# Global ARG (before first FROM)\nARG NODE_VERSION=20\n\nFROM node:${NODE_VERSION} AS builder\n# ARG must be redeclared after FROM to use\nARG NODE_ENV=production\nENV NODE_ENV=${NODE_ENV}\n\nRUN npm ci\nRUN npm run build\n\nFROM node:${NODE_VERSION}-alpine\n# Must redeclare again for this stage\nARG NODE_ENV=production\nENV NODE_ENV=${NODE_ENV}\n\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n```\n\n```bash\n# Override at build time\ndocker build \\\n --build-arg NODE_VERSION=18 \\\n --build-arg NODE_ENV=development \\\n -t myapp .\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Not Using Named Stages\n\n```dockerfile\n# ❌ Fragile - stage numbers change if you add stages\nFROM node:20\nRUN npm install\n\nFROM node:20\nCOPY --from=0 /app/node_modules ./\n\n# ✅ Robust - names are stable\nFROM node:20 AS deps\nRUN npm install\n\nFROM node:20\nCOPY --from=deps /app/node_modules ./\n```\n\n### Mistake 2: Forgetting ARG Scope\n\n```dockerfile\n# ❌ ARG not available after FROM\nARG VERSION=1.0\nFROM node:20\nRUN echo $VERSION # Empty!\n\n# ✅ Redeclare ARG after FROM\nARG VERSION=1.0\nFROM node:20\nARG VERSION\nRUN echo $VERSION # 1.0\n```\n\n### Mistake 3: Copying More Than Needed\n\n```dockerfile\n# ❌ Copying entire stage\nFROM builder AS deps\nRUN npm ci\n\nFROM node:20-alpine\nCOPY --from=deps /app ./ # Copies everything including source!\n\n# ✅ Copy only what's needed\nFROM node:20-alpine\nCOPY --from=deps /app/node_modules ./node_modules\n```\n\n---\n\n## 🐛 Debug This: The Missing Environment Variable\n\nA developer reports: \"My app works in the build stage but fails in production. Environment variables are missing!\"\n\n```dockerfile\nFROM node:20 AS builder\nARG API_URL=http://localhost:3000\nENV API_URL=${API_URL}\nWORKDIR /app\nCOPY . .\nRUN npm ci\nRUN npm run build # Uses API_URL in build\n\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n# Error: API_URL is undefined!\n```\n\n**Why is API_URL missing in the final stage?**\n\n---\n\n**✅ Solution:**\n\nENV variables don't transfer between stages. Each stage is independent.\n\n**The problem:** `ENV API_URL` was set in `builder` stage, but the final stage starts fresh from `node:20-alpine` with no knowledge of the builder's environment.\n\n**Fix 1: Redeclare in final stage:**\n\n```dockerfile\nFROM node:20 AS builder\nARG API_URL=http://localhost:3000\nENV API_URL=${API_URL}\nRUN npm run build\n\nFROM node:20-alpine\nARG API_URL=http://localhost:3000\nENV API_URL=${API_URL}\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n```\n\n**Fix 2: Use runtime configuration:**\n\n```dockerfile\nFROM node:20 AS builder\nARG API_URL\nRUN API_URL=${API_URL} npm run build\n# API_URL baked into build output\n\nFROM node:20-alpine\n# No ENV needed - it's in the built files\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n```\n\n**Fix 3: Configuration file:**\n\n```dockerfile\nFROM node:20 AS builder\nARG API_URL\nRUN echo \"{\\\"apiUrl\\\": \\\"${API_URL}\\\"}\" > config.json\nRUN npm run build\n\nFROM node:20-alpine\nCOPY --from=builder /app/config.json ./\nCOPY --from=builder /app/dist ./dist\nCMD [\"node\", \"dist/index.js\"]\n```\n\n**Key lesson:** Stages share nothing automatically. COPY --from transfers files, not environment.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Parallel Stage Build\n⭐ Difficulty: Easy | ⏱️ Time: 15 minutes\n\n```dockerfile\n# Create a Dockerfile with parallel stages\n# Stage 1: frontend - npm run build (simulate with sleep 5)\n# Stage 2: backend - pip install (simulate with sleep 5)\n# Stage 3: final - copies from both\n\n# Measure build time to verify parallelism\n# With parallelism: ~5 seconds\n# Without: ~10 seconds\n```\n\n```bash\n# Your Dockerfile here\ncat > Dockerfile << 'EOF'\n# TODO: Create parallel stages\nFROM alpine AS frontend\nRUN sleep 5 && echo \"frontend\" > /frontend.txt\n\nFROM alpine AS backend\nRUN sleep 5 && echo \"backend\" > /backend.txt\n\nFROM alpine\nCOPY --from=frontend /frontend.txt /\nCOPY --from=backend /backend.txt /\nEOF\n\n# Measure\ntime docker build --progress=plain -t parallel-test .\n```\n\n---\n\n### Exercise 2: Test Stage with Artifacts\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n```bash\nmkdir test-stage && cd test-stage\n\n# Create test project\ncat > package.json << 'EOF'\n{\n \"scripts\": {\n \"test\": \"echo 'Tests passed!' && mkdir -p coverage && echo 'report' > coverage/report.txt\"\n }\n}\nEOF\n\n# Create Dockerfile with:\n# 1. deps stage - installs dependencies\n# 2. test stage - runs tests, generates coverage\n# 3. coverage stage - exports just the coverage report\n# 4. production stage - final image\n\n# Build and extract coverage:\n# docker build --target coverage -o ./coverage-output .\n```\n\n---\n\n### Exercise 3: Secret Handling\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n```bash\nmkdir secrets-test && cd secrets-test\n\n# Create a \"secret\" file\necho \"SECRET_TOKEN=abc123\" > .env.secret\n\n# Create Dockerfile that:\n# 1. Uses BuildKit secret mount to access .env.secret\n# 2. Creates a file that proves secret was accessed\n# 3. Final image should NOT contain the secret\n\n# Verify:\n# 1. Build succeeds\n# 2. docker history shows no secret\n# 3. docker run myapp cat /app/used-secret.txt works\n# 4. docker run myapp cat /.env.secret fails (file doesn't exist)\n```\n\n---\n\n### Exercise 4: Monorepo Multi-Service Build\n⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 30 minutes\n\n```bash\nmkdir -p monorepo/{api,web,shared}\n\n# API service\ncat > monorepo/api/index.js << 'EOF'\nconsole.log(\"API Service\");\nEOF\n\n# Web service\ncat > monorepo/web/index.js << 'EOF'\nconsole.log(\"Web Service\");\nEOF\n\n# Shared library\ncat > monorepo/shared/utils.js << 'EOF'\nmodule.exports = { version: \"1.0.0\" };\nEOF\n\n# Create single Dockerfile that can build:\n# --target api → API service image\n# --target web → Web service image\n# Both should include shared library\n# Use parallel stages where possible\n```\n\n---\n\n### Exercise 5: Complete CI/CD Pipeline Dockerfile\n⭐⭐⭐⭐ Difficulty: Expert | ⏱️ Time: 35 minutes\n\nCreate a comprehensive Dockerfile with these stages:\n\n```\ndeps-base → deps-dev → lint ──┐\n │\n → deps-prod ├─→ build → production\n │\n test ───────────┘\n ↓\n coverage (extractable)\n```\n\nRequirements:\n1. `deps-base`: Install system deps\n2. `deps-dev`: Full dev dependencies\n3. `deps-prod`: Production only\n4. `lint`: ESLint check (fails build if errors)\n5. `test`: Jest tests (fails build if tests fail)\n6. `coverage`: Extractable coverage report\n7. `build`: TypeScript compile\n8. `production`: Minimal runtime image\n\n```bash\n# All checks pass:\ndocker build -t myapp:prod .\n\n# Extract coverage:\ndocker build --target coverage -o ./coverage .\n\n# Lint only:\ndocker build --target lint .\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Q1: How do you handle secrets in multi-stage Docker builds?\n\n**Strong Answer:**\n\n\"There are several patterns depending on the use case:\n\n**BuildKit secret mounts (best practice):**\n```dockerfile\nRUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci\n```\nSecret is available during build but never written to any layer. Build with `--secret id=npmrc,src=.npmrc`.\n\n**Stage isolation:**\nEven with ARG, use a separate build stage that's discarded:\n```dockerfile\nFROM node AS build-with-secrets\nARG NPM_TOKEN\nRUN npm ci # Uses token\n\nFROM node AS production\nCOPY --from=build-with-secrets /app/node_modules ./\n# Token never existed in this stage\n```\n\n**SSH forwarding for git:**\n```dockerfile\nRUN --mount=type=ssh git clone git@github.com:private/repo\n```\n\n**What NOT to do:**\n- Don't use ARG for secrets in final stage (visible in history)\n- Don't COPY secret files (persist in layers)\n- Don't delete secrets after use in same stage (still in earlier layer)\n\nThe key principle: secrets should exist only during specific RUN commands, never in any layer that becomes part of the final image.\"\n\n### Q2: Explain how BuildKit parallelizes multi-stage builds.\n\n**Strong Answer:**\n\n\"BuildKit represents the Dockerfile as a directed acyclic graph (DAG) and executes independent branches in parallel.\n\n**How it determines parallelism:**\n1. Parses all stages and their dependencies (COPY --from, FROM...AS)\n2. Builds dependency graph\n3. Stages with no dependencies on each other run concurrently\n\n**Example:**\n```dockerfile\nFROM base AS frontend\nRUN npm build # Takes 30s\n\nFROM base AS backend\nRUN pip install # Takes 30s\n\nFROM alpine AS final\nCOPY --from=frontend /dist /\nCOPY --from=backend /app /\n```\n\nWithout parallelism: 30 + 30 + copy = 61s\nWith parallelism: max(30, 30) + copy = 31s\n\n**Maximizing parallelism:**\n- Keep stages independent when possible\n- Use shared base stages to avoid duplicate work\n- Don't create unnecessary dependencies between stages\n\n**Viewing parallelism:**\n```bash\ndocker build --progress=plain .\n```\nShows which stages run simultaneously.\n\n**Practical impact:** Complex builds with frontend, backend, and tools can see 2-3x speedup. In our CI, we reduced builds from 15 minutes to 5 minutes primarily through parallel stages.\"\n\n### Q3: When would you use multiple FROM stages vs just combining RUN commands?\n\n**Strong Answer:**\n\n\"They solve different problems:\n\n**Multiple stages for:**\n1. **Size reduction** - Build tools not needed at runtime\n2. **Security isolation** - Secrets in build stage only\n3. **Different base images** - Full SDK for build, minimal for runtime\n4. **Parallel builds** - Independent stages run concurrently\n5. **Multiple outputs** - Same Dockerfile, different --target builds\n\n**Combined RUN for:**\n1. **Layer optimization** - Install and clean in one layer\n2. **Cache efficiency** - Logically grouped operations\n3. **Simple linear operations** - No benefit from separation\n\n**Decision framework:**\n\n```\nNeed different base image? → Multi-stage\nHandling secrets? → Multi-stage\nWant parallel builds? → Multi-stage\nBuilding multiple artifacts? → Multi-stage\nJust installing packages? → Combined RUN\nSimple cleanup? → Combined RUN\n```\n\n**Example where both matter:**\n```dockerfile\n# Multi-stage for build/runtime separation\nFROM node AS builder\n# Combined RUN for efficient layer\nRUN npm ci && npm run build && rm -rf node_modules\n\nFROM node:alpine\nCOPY --from=builder /app/dist ./\n```\n\nI use multi-stage as the default for production images and combine RUNs within each stage for optimization.\"\n\n### Q4: How would you structure a Dockerfile for a monorepo with shared dependencies?\n\n**Strong Answer:**\n\n\"Monorepo Dockerfiles need to balance build speed, parallelism, and caching:\n\n**Pattern 1: Shared base with workspace installs:**\n```dockerfile\nFROM node AS base\nCOPY package*.json ./\nCOPY packages/*/package*.json ./packages/\nRUN npm ci --workspace=packages/*\n\nFROM base AS service-a\nCOPY packages/shared ./packages/shared\nCOPY packages/service-a ./packages/service-a\nRUN npm run build --workspace=service-a\n\nFROM base AS service-b\nCOPY packages/shared ./packages/shared\nCOPY packages/service-b ./packages/service-b\nRUN npm run build --workspace=service-b\n```\n\n**Key considerations:**\n\n1. **Layer caching** - Copy package.jsons first, then source\n2. **Shared code** - Build shared libraries first, copy to dependents\n3. **Parallelism** - Independent services build in parallel\n4. **Selective builds** - Use --target to build specific services\n5. **Cache mounts** - Share npm/pip cache across stages\n\n**For very large monorepos:**\n- Consider using Docker buildx bake for coordinated builds\n- Use build matrix in CI for service-specific builds\n- Implement change detection to skip unchanged services\n\n**Production deployment:**\nEach service gets its own minimal image, built from the same Dockerfile with different --target flags. Shared base ensures consistency.\"\n\n### Q5: How do you debug issues in earlier build stages when only the final stage fails?\n\n**Strong Answer:**\n\n\"Several techniques:\n\n**1. Build up to specific stage:**\n```bash\ndocker build --target builder -t debug:builder .\ndocker run -it debug:builder /bin/sh\n```\n\n**2. Add debug output in Dockerfile:**\n```dockerfile\nRUN npm ci && ls -la node_modules/\nRUN npm run build || (cat build.log && exit 1)\n```\n\n**3. Use BuildKit progress output:**\n```bash\nDOCKER_BUILDKIT=1 docker build --progress=plain . 2>&1 | tee build.log\n```\nShows all output including from cached layers.\n\n**4. Extract artifacts from intermediate stage:**\n```dockerfile\nFROM scratch AS debug-artifacts\nCOPY --from=builder /app/build-log.txt /\nCOPY --from=builder /app/node_modules/.package-lock.json /\n```\n```bash\ndocker build --target debug-artifacts -o ./debug-output .\n```\n\n**5. Add a debug stage:**\n```dockerfile\nFROM builder AS debug\nRUN find / -name '*.log' 2>/dev/null\nRUN cat /app/tsconfig.json\nRUN npm ls --depth=0\n```\n\n**6. Override entrypoint:**\n```bash\ndocker run --entrypoint /bin/sh myapp:builder -c 'env && ls -la'\n```\n\n**7. BuildKit cache inspection:**\n```bash\ndocker buildx du --verbose\n```\n\nMy usual flow: build with --progress=plain, identify failing step, build --target to that stage, shell in and investigate.\"\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Core Concepts\n\n| Concept | Key Point |\n|---------|-----------|\n| Stage independence | Each stage starts fresh, shares nothing automatically |\n| Parallel execution | Independent stages build concurrently |\n| Named stages | Use AS name for maintainability |\n| COPY --from | Only way to transfer files between stages |\n| --target | Build up to specific stage |\n\n### Multi-Stage Patterns\n\n```dockerfile\n# Size reduction\nFROM sdk AS builder → FROM runtime\n\n# Security isolation\nFROM full AS build-with-secrets → FROM clean\n\n# Testing pipeline\nFROM base → tests → lint → build → production\n\n# Multiple outputs\nFROM base → service-a, service-b, service-c (--target)\n\n# Monorepo\nFROM base → shared → parallel services\n```\n\n### What You Can Do Now\n\n1. **Structure builds for parallelism** - Independent stages for speed\n2. **Handle secrets safely** - BuildKit mounts or stage isolation\n3. **Create multi-output Dockerfiles** - One file, many targets\n4. **Debug intermediate stages** - --target and artifact extraction\n\n---\n\n## 📋 Quick Reference\n\n### Stage Syntax\n\n```dockerfile\n# Named stage\nFROM image:tag AS stagename\n\n# Copy from stage\nCOPY --from=stagename /src /dest\n\n# Copy from external image\nCOPY --from=nginx:alpine /etc/nginx /etc/nginx\n\n# Build specific target\ndocker build --target stagename .\n\n# ARG across stages\nARG VERSION # Before first FROM - global\nFROM node\nARG VERSION # Must redeclare in each stage\n```\n\n### BuildKit Secret/SSH\n\n```dockerfile\n# syntax=docker/dockerfile:1\n\n# Secret mount\nRUN --mount=type=secret,id=mysecret,target=/path \\\n command\n\n# SSH mount\nRUN --mount=type=ssh \\\n git clone git@github.com:repo\n\n# Build commands\ndocker build --secret id=mysecret,src=file.txt .\ndocker build --ssh default .\n```\n\n### Debug Commands\n\n```bash\n# Build to specific stage\ndocker build --target stagename -t debug .\n\n# Shell into stage\ndocker run -it --rm debug /bin/sh\n\n# Extract files from stage\ndocker build --target stage -o ./output .\n\n# Verbose build output\ndocker build --progress=plain . 2>&1 | tee build.log\n```\n\n---\n\n## 📅 Review Schedule\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review stage isolation principles | 10 min |\n| Day 3 | Do Exercise 1 (parallel stages) | 15 min |\n| Day 7 | Implement testing stage in a project | 25 min |\n| Day 14 | Add BuildKit secrets to a build | 20 min |\n| Day 30 | Refactor a complex Dockerfile with multiple targets | 30 min |\n\n---\n\n## 📚 Series Navigation\n\n| Previous | Current | Next |\n|----------|---------|------|\n| [Part 5: Dockerfile Optimization](docker-part-5-dockerfile-optimization) | **Part 6: Multi-Stage Builds** | [Part 7: Base Image Selection](docker-part-7-base-images) |\n\n**Docker Compendium Series:**\n- [Part 0: How to Use This Series](docker-part-0-how-to-use-this-series)\n- [Part 1: Container Internals](docker-part-1-container-internals)\n- [Part 2: Image Anatomy](docker-part-2-image-anatomy)\n- [Part 3: Build Process Deep Dive](docker-part-3-build-process)\n- [Part 4: Networking Internals](docker-part-4-networking-internals)\n- [Part 5: Dockerfile Optimization Patterns](docker-part-5-dockerfile-optimization)\n- **Part 6: Multi-Stage Builds: Beyond Basics** ← You are here\n- [Part 7: Base Image Selection & Security](docker-part-7-base-images)\n","2026-06-10T07:19:25.435919Z","2026-06-10T07:19:25.436519Z",18,6,{"_33":57,"_96":59,"_97":98,"_99":100,"_101":-5,"_102":-5,"_103":-5,"_104":-5,"_105":-5},{"_33":92,"_74":61,"_37":93,"_77":94,"_95":-5},[119,120,121],{"_33":57,"_74":75,"_37":76,"_77":78,"_79":24},{"_33":89,"_74":90,"_37":91},{"_33":86,"_74":87,"_37":88},{"_33":122,"_74":123,"_37":124},228,"Multi-stage","multi-stage"]