DOCKER::DOCS
⌂
Containers for Consistent Environments

Docker Complete Guide

Docker packages an application together with everything it needs to run — code, runtime, system libraries, configuration — into a single portable image, so it behaves identically on a laptop, a CI runner, or a production server. A container is what you get when that image actually runs: an isolated process with its own filesystem and network, built on Linux kernel features rather than a full virtual machine, which is why it starts in milliseconds instead of minutes. This doc walks through the 10 concepts that make up everyday Docker usage, each with a diagram, a "where & when to use it" guide, and concrete implementation steps.

10 topics 10 diagrams 1 engine

Use the sidebar to jump straight to any topic — each one opens its own page with a full explanation, a diagram of exactly how it fits into the container lifecycle, and the concrete steps to use it for real. If you're starting from zero, work through Introduction & Installation and Images vs Containers first: everything else on this page assumes Docker is already running and that distinction already makes sense.

Diagram · From Dockerfile to Running Anywhere
Dockerfile Image tagged & layered cached, reusable Container isolated, running Any Docker Host laptop, CI, prod server same behavior everywhere THE CONCEPTS THAT SHAPE THIS PIPELINE Volumes Networks Compose Multi-Stage Registry Lifecycle Cmds

A Dockerfile builds into an image once; that same image can be run as a container anywhere Docker is installed, with identical behavior every time. Everything below the line is a concept that shapes how that pipeline actually behaves in practice — each one is its own topic in this guide.

All 10 topics in this guide

Summary & Patterns

Once the individual topics make sense on their own, these references tie them together: the order to learn them in, and the single habit — layer ordering — that separates a Dockerfile that rebuilds in two seconds from one that rebuilds from scratch every time.

Recommended Learning Order

Key Concept — Why Layer Order Controls Rebuild Speed

The single biggest lever over how fast docker build feels day to day: whether dependencies are installed before or after your source code is copied in.

Diagram · Slow Rebuilds vs Fast Rebuilds
❌ DEPS AFTER SOURCE ✅ DEPS BEFORE SOURCE FROM node:20-slim base layer COPY . . copies source too early RUN npm install reruns on every code change RUN npm run build reruns too — nothing was cached FROM node:20-slim base layer COPY package.json . only this file, first RUN npm install cached — reruns only if deps change COPY . . && RUN build only this re-runs on code edits

Docker caches each layer and only re-runs an instruction — and everything after it — when that instruction's own inputs change. Copy source code before installing dependencies (left) and a one-line code edit invalidates the install step too, every time. Copy just package.json first and install before the rest of the source (right), and the same edit only invalidates the final COPY — npm install stays cached until package.json itself actually changes.

Official Documentation Reference URLs

Every topic covered in this guide, with a direct link to its official Docker docs.