Lesson 1: Docker Basics

Container Forge: Production Docker Patterns for Cloud-Native Foundations

What We Build Today

• Multi-stage container images with non-root execution, dumb-init signal handling, and layered caching that cuts rebuild time by 90% on code-only changes

• Image optimization pipeline comparing unoptimized (450MB+) vs optimized (~120MB) vs production multi-stage builds with security hardening

• Segmented Docker networks with named volumes, Docker secrets, and healthcheck-driven startup ordering across six services

• Break-It-Friday debug lab with three deliberate networking bugs mirroring production DNS and dependency failures

Why This Matters

Every Kubernetes cluster runs containers. The difference between a team that treats Docker as "just packaging" and one that understands image layers, network isolation, and startup ordering is the difference between 2 AM pages and silent rollouts. At Spotify, container images are rebuilt thousands of times daily — layer caching strategy directly impacts developer velocity. At Netflix, non-root containers and minimal base images are non-negotiable security requirements enforced before any image reaches production AMIs. Airbnb's migration to Kubernetes failed initially because teams skipped Docker networking fundamentals — services couldn't resolve each other because network policies and DNS were treated as "Kubernetes problems" rather than container problems that persist in orchestration.

This week establishes the substrate. Kubernetes does not replace Docker networking — it wraps it. A Pod's containers share a network namespace; a Service's DNS name resolves through CoreDNS using the same alias semantics as Docker Compose. Engineers who master Week 1 patterns deploy Week 2 Kubernetes manifests with intuition rather than trial-and-error.

Docker Architecture Deep Dive

Multi-Stage Builds and Layer Caching

The fundamental insight: Docker images are not files — they are ordered layer stacks with content-addressable caching. When you COPY requirements.txt before application code, dependency installation layers remain cached across code changes. Production teams at FAANG scale enforce this ordering in CI lint rules because a single misplaced COPY . . before dependency installation can add 4 minutes to every build in a 200-service monorepo.

Our production Dockerfile uses five stages: base (system deps + non-root user), dependencies (full install), development (hot reload), and production (minimal runtime). The anti-pattern — single-stage images with gcc, vim, and git installed — bloats attack surface and pull time. Trivy scans on bloated images surface hundreds of false-positive CVEs from dev tools that never execute in production.