Docker

Master containerization from kernel internals to production orchestration. Covers Linux namespaces, cgroups, image layering, networking, storage, Compose, CI/CD pipelines, and every interview question that comes up at senior-level interviews.

How to Use This Guide

This guide is structured as a progressive deep-dive, from foundational concepts to production-grade patterns:

• Sections 1-4 — Core theory: why Docker exists, engine architecture, kernel-level isolation, containers vs VMs.
• Sections 5-7 — Practical mastery: image layers & build cache, networking internals, volumes & persistence.
• Sections 8-11 — Production: Compose, CI/CD pipelines, security hardening, debugging techniques.
• Section 12 — FAANG-level interview questions with concise answers covering kernel internals, architecture, and design.

Start with Sections 1-3 if you need to explain Docker internals in an interview. If you already understand the fundamentals, jump to Section 5 for image optimization or directly to the Interview Q&A for rapid prep.

1. The Origin Story — Why Containers Exist

2. Architecture — Docker Engine Internals

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TB
    subgraph CLIENT["Docker Client (CLI)"]
        CMD1["docker build"]
        CMD2["docker run"]
        CMD3["docker push"]
    end

    subgraph DAEMON["Docker Daemon (dockerd)"]
        direction TB
        REST["REST API<br/>/var/run/docker.sock"]
        IMG_SVC["Image Service"]
        CTR_SVC["Container Service"]
        NET_SVC["Network Service"]
        VOL_SVC["Volume Service"]
    end

    subgraph RUNTIME["Container Runtime Stack"]
        direction TB
        CONTAINERD["containerd<br/><small>container lifecycle management</small>"]
        SHIM["containerd-shim<br/><small>keeps container alive if containerd restarts</small>"]
        RUNC["runc<br/><small>OCI runtime — creates namespaces + cgroups</small>"]
    end

    subgraph REGISTRY["Registry (Docker Hub / ECR / GCR)"]
        REPO["Repositories<br/>nginx, postgres, myapp"]
    end

    CLIENT -->|"REST API over Unix socket"| REST
    REST --> IMG_SVC & CTR_SVC & NET_SVC & VOL_SVC
    CTR_SVC --> CONTAINERD
    CONTAINERD --> SHIM
    SHIM --> RUNC
    IMG_SVC <-->|"pull / push"| REPO

    style CLIENT fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    style DAEMON fill:#FEF3C7,stroke:#F59E0B,color:#92400E
    style RUNTIME fill:#D1FAE5,stroke:#10B981,color:#065F46
    style REGISTRY fill:#EDE9FE,stroke:#8B5CF6,color:#5B21B6

The Execution Flow — What Actually Happens

When you type docker run -d --name web -p 8080:80 nginx:

3. Linux Kernel Internals — How Isolation Works

This is what separates a "Docker user" from a "container engineer." Containers are NOT VMs. They're just normal Linux processes with restrictions.

Namespaces — Isolation

Each namespace gives a container its own view of a system resource:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph TB
    subgraph HOST["Host Kernel (shared)"]
        subgraph NS1["Container A Namespaces"]
            PID1["PID: 1 (nginx)"]
            NET1["NET: 172.17.0.2"]
            MNT1["MNT: /app rootfs"]
        end
        subgraph NS2["Container B Namespaces"]
            PID2["PID: 1 (java)"]
            NET2["NET: 172.17.0.3"]
            MNT2["MNT: /app rootfs"]
        end
    end

    style HOST fill:#F0FDF4,stroke:#22C55E,color:#166534
    style NS1 fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    style NS2 fill:#EDE9FE,stroke:#8B5CF6,color:#5B21B6

Cgroups — Resource Limits

Cgroups (Control Groups) limit HOW MUCH of a resource a container can use:

Union Filesystem (OverlayFS) — Layers Made Real

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph TB
    subgraph OFS["OverlayFS Mount"]
        MERGED["Merged View<br/><small>(what the container sees)</small>"]
    end

    subgraph UPPER["Upper Layer (writable)"]
        UF1["modified-config.yml"]
        UF2["new-logfile.log"]
        UF3[".wh.deleted-file<br/><small>(whiteout = deletion marker)</small>"]
    end

    subgraph LOWER["Lower Layers (read-only image)"]
        L3["Layer 3: COPY app.jar"]
        L2["Layer 2: RUN apt-get install"]
        L1["Layer 1: FROM ubuntu:22.04"]
    end

    MERGED --> UPPER
    MERGED --> LOWER

    style OFS fill:#FEF3C7,stroke:#F59E0B,color:#92400E
    style UPPER fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    style LOWER fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF

How writes work: Container writes go to the upper (writable) layer. Reads check upper first, then fall through to lower layers. Deletes create "whiteout" files. This is why containers start instantly — no filesystem copy needed.

Why this matters for production: - 100 containers from the same image share ONE copy of the lower layers (massive disk savings) - Writes only exist in the container's upper layer (destroyed on docker rm) - If you write large files inside a container without volumes, OverlayFS performance degrades

4. Containers vs VMs — The Real Difference

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph TB
    subgraph VM_STACK["Virtual Machine Architecture"]
        direction TB
        VM_APP1["App A"] & VM_APP2["App B"]
        VM_BIN1["Bins/Libs"] & VM_BIN2["Bins/Libs"]
        VM_OS1["Guest OS<br/><small>Ubuntu 22.04</small>"] & VM_OS2["Guest OS<br/><small>CentOS 9</small>"]
        VM_HYP["Hypervisor (VMware / KVM / Xen)"]
        VM_HOST["Host Operating System"]
        VM_HW["Infrastructure (Hardware)"]
    end

    subgraph CTR_STACK["Container Architecture"]
        direction TB
        CTR_APP1["App A"] & CTR_APP2["App B"] & CTR_APP3["App C"] & CTR_APP4["App D"]
        CTR_BIN1["Bins/Libs"] & CTR_BIN2["Bins/Libs"] & CTR_BIN3["Bins/Libs"] & CTR_BIN4["Bins/Libs"]
        CTR_RT["Container Runtime (containerd)"]
        CTR_HOST["Host Operating System (shared kernel)"]
        CTR_HW["Infrastructure (Hardware)"]
    end

    style VM_STACK fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    style CTR_STACK fill:#D1FAE5,stroke:#10B981,color:#065F46

5. Image Deep Dive — Layers & Build Cache

Layer Architecture

Every Dockerfile instruction creates a layer. Docker caches layers by content hash. If nothing changed → cache hit → skip rebuild.

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph TB
    subgraph BUILD["Build Process"]
        direction TB
        I1["FROM eclipse-temurin:21-jdk<br/><small>CACHED: base image (pulled once)</small>"]
        I2["COPY pom.xml + mvnw<br/><small>CACHED: until pom.xml changes</small>"]
        I3["RUN mvn dependency:resolve<br/><small>CACHED: deps change ~weekly</small>"]
        I4["COPY src/<br/><small>INVALIDATED: every commit</small>"]
        I5["RUN mvn package<br/><small>REBUILD: triggered by src change</small>"]
    end

    I1 --> I2 --> I3 --> I4 --> I5

    style I1 fill:#D1FAE5,stroke:#10B981,color:#065F46
    style I2 fill:#D1FAE5,stroke:#10B981,color:#065F46
    style I3 fill:#D1FAE5,stroke:#10B981,color:#065F46
    style I4 fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    style I5 fill:#FEE2E2,stroke:#EF4444,color:#991B1B

The golden rule: Order instructions from LEAST frequently changing to MOST frequently changing. Any layer that changes invalidates ALL layers below it.

Multi-Stage Builds — Shrink Images by 80%

# ============ Stage 1: Build (has all tools, ~800MB) ============
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app

# Layer 1: Dependencies (cached until pom.xml changes)
COPY pom.xml mvnw ./
COPY .mvn/ .mvn/
RUN ./mvnw dependency:resolve -B

# Layer 2: Source + build (changes every commit)
COPY src/ src/
RUN ./mvnw package -DskipTests -B && \
    # Extract layered JAR for even smaller runtime
    java -Djarmode=layertools -jar target/*.jar extract --destination /extracted

# ============ Stage 2: Runtime (minimal, ~200MB) ============
FROM eclipse-temurin:21-jre
WORKDIR /app

# Security: non-root user
RUN groupadd -r app && useradd -r -g app -d /app app

# Copy extracted layers (maximizes Docker layer caching at runtime)
COPY --from=builder /extracted/dependencies/ ./
COPY --from=builder /extracted/spring-boot-loader/ ./
COPY --from=builder /extracted/snapshot-dependencies/ ./
COPY --from=builder /extracted/application/ ./

RUN chown -R app:app /app
USER app

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:8080/actuator/health || exit 1

# Note: -Djava.security.egd=file:/dev/./urandom is unnecessary since Java 11;
# the default SecureRandom already uses /dev/urandom.
ENTRYPOINT ["java", \
  "-XX:+UseContainerSupport", \
  "-XX:MaxRAMPercentage=75.0", \
  "-XX:InitialRAMPercentage=50.0", \
  "org.springframework.boot.loader.launch.JarLauncher"]

Why -XX:MaxRAMPercentage=75.0? The JVM by default reads the HOST's memory, not the cgroup limit. Without this flag, a container with --memory=512m on a 32GB host will think it has 32GB and set heap to 8GB → instant OOM kill.

Image Naming & Tagging Strategy

registry.example.com/team-name/service-name:v2.1.0-alpine
─────────────────── ───────── ──────────── ──────────────
     registry         org/team    repo        tag

Production tagging rules:

• Never use :latest in production (non-reproducible deploys)
• Use semantic versions: v2.1.0
• Include variant: v2.1.0-alpine, v2.1.0-jre21
• CI should tag with git SHA: v2.1.0-abc123f (exact traceability)

6. Networking — Bridges, veth Pairs, iptables

How Container Networking Works

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TB
    subgraph HOST["Host Machine"]
        subgraph BRIDGE["docker0 bridge (172.17.0.0/16)"]
            VETH1["veth-abc<br/>→ Container A"]
            VETH2["veth-def<br/>→ Container B"]
        end
        ETH0["eth0 (host NIC)<br/>192.168.1.100"]
        IPTABLES["iptables NAT rules<br/><small>-p 8080:80 → DNAT to 172.17.0.2:80</small>"]
    end

    subgraph CNSA["Container A (172.17.0.2)"]
        CETH1["eth0 → veth pair"]
        NGINX["nginx :80"]
    end

    subgraph CNSB["Container B (172.17.0.3)"]
        CETH2["eth0 → veth pair"]
        PG["postgres :5432"]
    end

    INTERNET["Internet / Host"] -->|":8080"| IPTABLES
    IPTABLES -->|"DNAT"| VETH1
    VETH1 --- CETH1
    VETH2 --- CETH2
    CETH1 --- NGINX
    CETH2 --- PG

    style BRIDGE fill:#D1FAE5,stroke:#10B981,color:#065F46
    style CNSA fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    style CNSB fill:#EDE9FE,stroke:#8B5CF6,color:#5B21B6

Under the hood:

1. Each container gets its own network namespace (isolated network stack)
2. A veth pair connects the container's namespace to the host bridge
3. The docker0 bridge acts like a virtual switch
4. iptables NAT handles port mapping (host → container) and outbound traffic (container → internet via MASQUERADE)

Network Types — When To Use Each

7. Volumes & Storage — Persistence Strategies

The Three Types

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph NV["Named Volume"]
        direction TB
        NVD["Docker manages location<br/>/var/lib/docker/volumes/pgdata/_data"]
        NVP["Portable, survives everything"]
    end

    subgraph BM["Bind Mount"]
        direction TB
        BMD["You specify exact host path<br/>/home/dev/project/src:/app/src"]
        BMP["Development live-reload"]
    end

    subgraph TM["tmpfs"]
        direction TB
        TMD["RAM only, never hits disk<br/>--tmpfs /app/tmp"]
        TMP["Sensitive scratch data"]
    end

    style NV fill:#D1FAE5,stroke:#10B981,color:#065F46
    style BM fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    style TM fill:#FEF3C7,stroke:#F59E0B,color:#92400E

Production Database Pattern

# Create a named volume (persists across container lifecycle)
docker volume create pgdata

# Run Postgres with volume + resource limits + health check
docker run -d \
  --name postgres \
  --network app-net \
  -v pgdata:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD_FILE=/run/secrets/pg_pass \
  --memory=2g --cpus=2.0 \
  --restart unless-stopped \
  --health-cmd="pg_isready -U postgres" \
  --health-interval=10s \
  postgres:16-alpine

# Backup the volume (production pattern)
docker run --rm \
  -v pgdata:/source:ro \
  -v $(pwd)/backups:/backup \
  alpine tar czf /backup/pgdata-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

8. Docker Compose — Multi-Service Orchestration

Production-Grade Stack

services:
  api:
    build:
      context: .
      dockerfile: Dockerfile
      target: production       # multi-stage target
    ports: ["8080:8080"]
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/myapp
      SPRING_REDIS_HOST: cache
      JAVA_OPTS: "-XX:MaxRAMPercentage=75.0"
    depends_on:
      db: { condition: service_healthy }
      cache: { condition: service_healthy }
    deploy:
      resources:
        limits: { memory: 1G, cpus: '2.0' }
        reservations: { memory: 512M, cpus: '0.5' }
    restart: unless-stopped
    networks: [app-net]

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./sql/init.sql:/docker-entrypoint-initdb.d/01-init.sql:ro
    environment:
      POSTGRES_DB: myapp
      POSTGRES_PASSWORD: ${DB_PASSWORD}   # from .env file
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 10s
    deploy:
      resources:
        limits: { memory: 2G }
    networks: [app-net]

  cache:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes: [redis-data:/data]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
    networks: [app-net]

  nginx:
    image: nginx:1.25-alpine
    ports: ["80:80", "443:443"]
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    depends_on:
      api: { condition: service_healthy }
    networks: [app-net]

volumes:
  pgdata:
  redis-data:

networks:
  app-net:
    driver: bridge

9. CI/CD — The Production Pipeline

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    A["Git Push"] --> B["Lint Dockerfile<br/><small>hadolint</small>"]
    B --> C["Build Image<br/><small>--cache-from registry</small>"]
    C --> D["Unit Tests<br/><small>inside container</small>"]
    D --> E["Security Scan<br/><small>trivy / docker scout</small>"]
    E --> F{"CVEs found?"}
    F -->|Critical| G["Block Deploy"]
    F -->|None/Low| H["Push to Registry<br/><small>:git-sha + :latest</small>"]
    H --> I["Deploy to Staging"]
    I --> J["Integration Tests"]
    J --> K["Deploy to Prod<br/><small>canary → full</small>"]

    style G fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    style H fill:#D1FAE5,stroke:#10B981,color:#065F46
    style K fill:#D1FAE5,stroke:#10B981,color:#065F46

10. Production Hardening & Security

11. Debugging Production Containers

12. Interview Q&A (FAANG-Level)

Push → Lint Dockerfile (hadolint) → Build with layer cache from registry
→ Run unit tests inside container → Security scan (trivy)
→ Push tagged image (git-sha + semver) → Deploy to staging
→ Run integration tests against staging → Canary deploy to prod (10%)
→ Monitor error rate for 15min → Full rollout or auto-rollback