How to learn Docker

You build your first images and learn to see them as ordered stacks of read-only layers. This stage sits first because every later topic — caching, size, security, multi-stage builds — is a consequence of how layers work.

• Dockerfile instructions: FROM, RUN, COPY, ADD, CMD, ENTRYPOINT, ENV, WORKDIR
• Layer creation rules: which instructions create a layer and which do not
• Reading `docker history` and `docker inspect` output
• Image tags and the `latest` convention
• Registry basics: Docker Hub, pulling, pushing
• Image size measurement with `docker images`

You can now: Build the same application twice with different instruction ordering and explain, from `docker history`, why one image is 200MB larger.

You learn exactly when the cache is invalidated and how to structure a Dockerfile so that slow steps stay cached. This stage follows images and layers because the cache is the practical payoff of understanding them.

• Cache invalidation rules: instruction order, file changes, base image changes
• The difference between COPY and ADD for caching
• Using .dockerignore to protect the cache
• BuildKit and `DOCKER_BUILDKIT=1`
• Cache-busting techniques: build args, versioned dependencies
• Reading build output to see which steps used cache

You can now: Take a Dockerfile that rebuilds a 400MB dependency layer on every source change and restructure it so the dependency layer stays cached.

You move from building to running: process lifecycle, logs, signals, resource limits, and restart policies. This stage comes after the build cache because running containers is mostly about managing what the image already contains.

• Container lifecycle: create, start, stop, kill, rm
• Foreground vs detached mode, `docker logs`, `docker attach`
• PID 1 and signal handling, `docker stop` vs `docker kill`
• Resource limits: --memory, --cpus, --pids-limit
• Restart policies: no, on-failure, always, unless-stopped
• Port publishing and the difference between EXPOSE and -p

You can now: Run a container that handles SIGTERM gracefully, confirm it with `docker stop`, then write a second container that ignores SIGTERM and observe the 10-second default kill delay.

You learn where container data lives and how containers talk to each other. This stage follows running containers because volumes and networks only matter once you have stateful or multi-container applications.

• Named volumes vs bind mounts vs tmpfs
• Volume lifecycle: create, inspect, prune, backup and restore
• The copy-up behaviour for empty named volumes
• Bridge networks and container DNS resolution
• User-defined networks vs the default bridge
• Network drivers: bridge, host, none, overlay (concept only)

You can now: Run two containers on a user-defined network that communicate by container name, then move one to the default bridge and show that DNS resolution stops working.

You define multi-container applications in a single file. This stage sits after volumes and networks because a Compose file is mostly a declarative wrapper around the run, volume and network commands you already know.

• Compose file structure: services, networks, volumes
• The difference between `docker compose` and `docker-compose`
• Build context and image reuse in Compose
• Environment variables and .env files
• Depends_on and healthchecks for startup ordering
• Compose lifecycle: up, down, restart, logs, exec

You can now: Define a three-service application (web, database, cache) in a Compose file, bring it up with one command, and show that the web service can resolve the database by service name.

You reduce image size and attack surface by separating build dependencies from runtime dependencies. This stage comes last because it requires fluency with layers, the cache and running containers to be meaningful.

• Multi-stage build syntax: multiple FROM instructions, named stages, COPY --from
• Choosing minimal base images: alpine, distroless, scratch
• Non-root users and USER instruction
• Layer squashing and experimental features
• Image scanning with `docker scout` or third-party tools
• Reproducible builds: pinning base image digests

You can now: Take a single-stage image with a full toolchain and reduce it by 80% using a multi-stage build, then run the result as a non-root user.