Docker Fundamentals

Docker is a platform for packaging an application together with everything it needs to run, and executing that package as an isolated process on any machine that has Docker installed.

Before Docker, "it works on my machine" was a real engineering problem — an application's behavior depended on the exact OS, library versions, and configuration of the machine it ran on. Docker solves this by packaging the application, its dependencies, and its runtime environment into a single image that behaves identically everywhere: your laptop, a teammate's laptop, a CI runner, and a production server.

The core building blocks

Docker architecture, as this guide covers it, is a build-and-run pipeline, and the diagram under “What Is Docker?” above shows it end to end. A Dockerfile describes how to build an image, the image is stored in a registry so it can move between machines, and a container is a running instance created from that image. The rest of this guide covers each stage in detail, starting with images and layers.

Containers solve two problems at once: environment consistency, and efficient use of hardware.

The consistency problem

Before containers, deploying software meant carefully replicating a server's exact configuration — OS version, installed packages, library versions, environment variables — by hand or with configuration management tools. Any drift between environments (dev, staging, prod) could cause bugs that only appeared in one place.

The efficiency problem

Virtual machines solved isolation by giving each application its own full operating system — but that means duplicating gigabytes of OS overhead and minutes of boot time per application. Running ten applications meant ten guest kernels, ten copies of system libraries, and ten multi-second boots.

A virtual machine virtualizes hardware and runs a full guest operating system; a container virtualizes the operating system and runs an isolated process.

A hypervisor (like VMware ESXi or KVM) presents each VM with virtual hardware — virtual CPU, virtual disk, virtual NIC — and the VM boots its own kernel on top of that virtual hardware, just like it would on a physical machine. This gives very strong isolation (a VM can run an entirely different OS from its host) at the cost of size and boot time.

A container, by contrast, is simply a process running on the host, isolated using namespaces (separate views of process IDs, network interfaces, mounts, hostname…) and cgroups (limits on CPU, memory, and I/O). There is no second kernel, no virtual hardware — just the host kernel enforcing boundaries around a normal process.

A Docker image is not one big blob — it's a stack of read-only layers, one per Dockerfile instruction, unioned together into a single filesystem view.

When Docker builds an image, each instruction in the Dockerfile (FROM, RUN, COPY, …) produces a new layer containing only the filesystem changes made by that instruction. Layers are content-addressed (identified by a hash of their contents) and can be shared across many images — if two images both start FROM node:20-slim, they literally share that base layer on disk.

A container moves through a well-defined lifecycle: created, running, stopped, and eventually removed.

Docker gives every container its own network namespace, and lets you connect containers together on private, user-defined networks.

By default, everything written inside a container's writable layer disappears when the container is removed. Volumes decouple data from the container's lifecycle.

A named volume is a storage area managed by Docker, independent of any particular container. When a container mounts a volume at a path (e.g. /var/lib/postgresql/data), reads and writes to that path go to the volume instead of the container's own filesystem. If the container is removed and a new one is started with the same volume mounted, the data is still there.

The same image should be deployable to development, staging, and production without being rebuilt — configuration differences are injected at container start time.

Environment variables (-e KEY=value, or an env file) are the standard mechanism for injecting configuration — database URLs, feature flags, API keys, log levels — into a container without baking them into the image. This keeps the image itself environment-agnostic and reusable.