8 Docker Concepts
Docker concepts for image builds, runtime isolation, storage, networking, and registries.
Docker makes more sense once you stop treating it as magic packaging and start treating it as a workflow around Linux isolation primitives, layered filesystems, and reproducible builds. A Dockerfile defines how an image is built, the image becomes a container at runtime, and registries, networks, and volumes decide how that container moves and behaves.
Dockerfile
A Dockerfile is a build recipe, not a shell history. Each instruction creates a new image layer and therefore affects cache reuse, build time, and final image size. Ordering matters. If you copy the whole source tree before installing dependencies, a one line code change can invalidate the expensive dependency layer. Good Dockerfiles separate stable steps from volatile ones, pin base images deliberately, and avoid baking secrets into build arguments or copied files.
Docker Image
An image is an immutable filesystem snapshot plus metadata such as entrypoint, environment defaults, and exposed ports. Images are made of layers, so many images can share the same base bytes on disk. That makes distribution efficient, but it also means image hygiene matters. A bloated image increases pull time, attack surface, and cold start cost. An image is a deployable artifact, not a running machine.
Docker Container
A container is a running instance of an image with its own writable layer, process namespace, network view, and resource limits. It is not a lightweight virtual machine. The main process inside the container is still a host process managed through namespaces and cgroups. That explains many surprises. If PID 1 does not handle signals correctly, shutdown is messy. If the writable layer fills up, the container fails even though the image itself is untouched.
Docker Registry
A registry stores and distributes images by tag or digest. Tags are convenient, but they are mutable names. Digests identify exact image content and are safer for reproducible deployments. Public registries make sharing simple, while private registries are common for internal services and licensed components. The operational concern is provenance. Teams should know who built the image, which base image it depends on, and whether the pushed tag still points to the bytes they tested.
Docker Volumes
Volumes hold data outside the container's writable layer so that databases, uploads, or caches survive container replacement. This matters because containers are meant to be disposable. A new deployment should be able to recreate the container without destroying the state that users care about. The catch is ownership and lifecycle. Backups, permissions, and cleanup rules apply to volumes separately from the container image.
Docker Compose
Docker Compose defines multi container applications as one declarative stack. A web service can depend on a database, cache, and background worker without requiring a pile of manual docker run commands. The benefit is repeatability for development, demos, and smaller production setups. The limitation is scope. Compose orchestrates one host well, but it is not a full cluster scheduler.
Docker Networks
Networks decide which containers can talk to each other and how names resolve between them. The default bridge network is enough for many local setups, but explicit user defined networks give clearer isolation and built in DNS by service name. Misunderstanding networks leads to two common failures: accidental exposure of ports to the host, and false assumptions that containers can see localhost on the host.
Docker CLI
The Docker CLI is the control surface for building, inspecting, running, and debugging everything else. Commands such as docker build, docker run, docker exec, docker logs, and docker inspect expose the lifecycle of the system. Teams that only memorise the happy path usually struggle when a container exits immediately or a bind mount hides expected files.
These concepts fit together as one model. Build clean images from deliberate Dockerfiles, store them in registries you can trust, run them as disposable containers, keep persistent state in volumes, connect services with explicit networks, and use Compose or the CLI according to the operational scale.