Docker: Zero to Hero

From "what is a container?" to writing lean, secure, production-grade images and multi-service stacks. Everything runs locally. Work top to bottom, or jump to a part.

The journey:

1. What Docker is and the mental model
2. Your first container
3. Images, layers, and the build cache
4. Writing a Dockerfile
5. Data that survives: volumes and bind mounts
6. Networking and connecting containers
7. Multi-service stacks with Docker Compose
8. Multi-stage builds and small images
9. Security hardening
10. Registries, tags, and CI
11. Troubleshooting toolkit

---

Prerequisites

No cloud account, registry login, or paid service is required. Confirm your install works before you start:

docker version          # client + server both reported
docker run --rm hello-world   # prints a success message, then exits

---

Part 1 — What Docker is and the mental model

Docker packages an application and everything it needs (runtime, libraries, files) into a portable image, and runs it as an isolated container — a set of processes on the host kernel, fenced off by Linux namespaces (what it can see) and cgroups (what it can use).

Three words you must not confuse:

The value: the image runs the same on your laptop, CI, and production — "works on my machine" becomes "works everywhere," because the machine ships inside the image.

---

Part 2 — Your first container

docker run hello-world                 # pulls + runs a tiny test image
docker run -d -p 8080:80 --name web nginx   # run nginx detached, map host:container port
docker ps                              # running containers
docker logs web                        # its stdout/stderr
docker exec -it web sh                 # get a shell inside it
docker stop web && docker rm web       # stop + remove

Key flags to internalize: -d (detached/background), -p host:container (publish a port), --name, -e KEY=val (env var), -it (interactive shell), --rm (auto-delete on exit).

---

Part 3 — Images, layers, and the build cache

An image is a stack of read-only layers; each Dockerfile instruction adds one. When you run a container, Docker adds a thin writable layer on top. Layers are cached and shared between images, which is why the order of instructions matters enormously for build speed.

docker images              # list local images
docker pull python:3.12-slim
docker history python:3.12-slim   # see the layers

The cache rule: Docker reuses a cached layer until an instruction (or a file it copies) changes; after that, every following layer rebuilds. So put the things that change least (dependency installs) before the things that change most (your source code).

---

Part 4 — Writing a Dockerfile

A Dockerfile is the recipe for an image. Here's a well-ordered one for a Python app:

FROM python:3.12-slim                 # small, official base

WORKDIR /app

# Copy ONLY the dependency manifest first, so `pip install` is cached
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Now copy source (changes often — kept last so it doesn't bust the deps cache)
COPY . .

EXPOSE 8000
# Prefer exec form (JSON array) so signals reach your process for clean shutdown
CMD ["python", "app.py"]

Build and run:

docker build -t myapp:1.0 .
docker run --rm -p 8000:8000 myapp:1.0

Essential instructions: FROM (base), WORKDIR, COPY/ADD (prefer COPY), RUN (build-time commands), ENV, EXPOSE (documentation), ENTRYPOINT vs CMD (ENTRYPOINT = the fixed command, CMD = default args). Add a .dockerignore (like .gitignore) so junk and secrets never enter the build context.

---

Part 5 — Data that survives: volumes and bind mounts

Containers are ephemeral — delete one and its writable layer is gone. To persist or share data:

# Named volume (Docker-managed, best for databases)
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:16

# Bind mount (host path -> container, great for live-editing code in dev)
docker run --rm -p 8000:8000 -v "$(pwd):/app" myapp:1.0

• Named volumes are managed by Docker and portable — use them for stateful data (databases).
• Bind mounts map a host directory in — perfect for development hot-reload, risky for prod (couples you to the host layout).
• tmpfs keeps data in RAM only.

docker volume ls / docker volume rm manage them.

---

Part 6 — Networking and connecting containers

Containers on the same user-defined network reach each other by name via Docker's built-in DNS.

docker network create appnet
docker run -d --name db --network appnet postgres:16
docker run -d --name api --network appnet -e DB_HOST=db myapp:1.0
# 'api' can now connect to 'db:5432' — the name resolves automatically

• -p 8080:80 publishes a container port to the host (north-south).
• A shared user-defined network gives name-based service discovery (east-west). The default bridge network does not provide name resolution — always create your own network (or use Compose, which does it for you).

---

Part 7 — Multi-service stacks with Docker Compose

Real apps are several containers. Compose declares them in one file and wires networking/volumes automatically.

# compose.yaml
services:
  api:
    build: .
    ports: ["8000:8000"]
    environment:
      DB_HOST: db
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 5

volumes:
  pgdata:

docker compose up -d      # build + start everything, one network, name-based DNS
docker compose logs -f api
docker compose down       # stop + remove (add -v to also drop volumes)

depends_on + healthcheck ensures the API waits until the DB is actually ready, not just started.

---

Part 8 — Multi-stage builds and small images

Small images build faster, pull faster, and have a smaller attack surface. The trick is a multi-stage build: compile in a fat builder stage, then copy just the artifact into a tiny runtime stage.

# ---- build stage ----
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# ---- runtime stage (tiny) ----
FROM gcr.io/distroless/static
COPY --from=build /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

The final image contains only the binary — no compiler, no shell, often under 20MB. For interpreted languages, use -slim or -alpine bases and copy only what you need. Check size with docker images and inspect layers with tools like dive.

---

Part 9 — Security hardening

Default containers run as root — a real risk. Harden them:

# Create and use a non-root user
RUN useradd -u 10001 -m appuser
USER 10001

Checklist:

• Run as non-root (USER), and drop capabilities at runtime (--cap-drop ALL).
• Pin versions (python:3.12.4-slim, or a digest) — never rely on latest.
• Minimal base (distroless/slim/alpine) = smaller attack surface.
• No secrets in images — pass them at runtime (-e, secrets, env files), and use .dockerignore so .env/keys never enter the build.
• Scan images for CVEs (docker scout cves, Trivy, Grype) in CI.
• Read-only root filesystem where possible (--read-only + tmpfs for writable paths).

---

Part 10 — Registries, tags, and CI

docker tag myapp:1.0 ghcr.io/you/myapp:1.0
docker login ghcr.io
docker push ghcr.io/you/myapp:1.0

Tagging discipline: tag with an immutable version or the git SHA (myapp:sha-ab12cd) for deploys, and move a :latest or :stable pointer separately. Deploying :latest is a classic source of "which version is actually running?" incidents. In CI, build with BuildKit (cache mounts, parallel stages), scan, then push on green.

---

Part 11 — Troubleshooting toolkit

---

Common mistakes to avoid

• COPY . . before installing dependencies. Every source edit then busts the dependency cache and reinstalls everything. Copy the manifest and install first.
• Shipping :latest to production. You lose the answer to "what's actually running?" Tag with a version or the git SHA and move :latest separately.
• Baking secrets into images. Anything in a layer is extractable forever, even if a later layer "deletes" it. Pass secrets at runtime and add a .dockerignore.
• Running as root. The default. One container escape becomes host root. Add a USER and drop capabilities.
• Storing data in the container's writable layer. It vanishes with docker rm. Use a named volume for anything stateful.
• Using the default bridge network for multi-container apps. It has no name-based DNS — create a user-defined network (or use Compose).
• RUN apt-get update in a separate layer from install. A cached update layer serves stale package indexes. Chain them in one RUN.

---

Practice: try it yourself

Work these hands-on — they cement the whole loop.

1. Lean image challenge. Take the Python Dockerfile from Part 4 and get the final image under 150MB. (Hints: -slim base, multi-stage, --no-cache-dir, a .dockerignore.) Compare with docker images.
2. Break the cache on purpose. Build the image, edit only a source file, rebuild. Which layers rebuilt? Now edit requirements.txt and rebuild — what changed? Explain why from the cache rule.
3. Two-service stack. Write a compose.yaml with an app container talking to Postgres by name, with a healthcheck gate. Bring it up, docker compose logs -f, then down -v.
4. Persist and prove it. Run Postgres with a named volume, create a table, docker rm the container, start a fresh one on the same volume — verify the table survived.

Self-check (answer without scrolling up):

• What's the difference between an image and a container? Between ENTRYPOINT and CMD?
• Why does instruction order in a Dockerfile change build speed?
• Two containers can't reach each other by name. What's the most likely cause?
• Where do secrets belong — the image or the runtime? Why?

---

Where to go next

• Test yourself on the Docker interview questions and use cases.
• Study failure modes in the production issues section.
• Handy tool: lint and harden your Dockerfile with the Dockerfile Linter & Generator.
• Then Kubernetes — once you're comfortable with images and containers, the Kubernetes getting-started tutorial is the natural next step.

You now have the full loop: write a Dockerfile → build a lean image → run and network containers → compose a stack → harden → ship. That's zero to hero.