How Docker Works — build, ship, run
How Docker works, shown on an interactive canvas: Dockerfile to image, registry to container, and the namespaces and cgroups that isolate a process.
Docker packages an application and everything it needs into an image, then runs it as a container — an isolated process that behaves identically on any machine with a Docker engine.
How Docker Works — build, ship, run
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the three columns left to right: Build, Ship, Run.
- The bottom band, "Host operating system", is the foundation: the container at the end of the flow runs ON it, sharing its kernel.
- The image is the artifact everything else moves around — from the Docker engine to the registry and back to the runtime.
Building the image
"Developer writes a Dockerfile describing the app" is a recipe, not a result: a base image, the dependencies to install, files to copy and the command to run. "docker build packages the app and its dependencies" executes the recipe, and "The build produces an image — a read-only snapshot" is the output — an immutable artifact in layered filesystem. Reproducibility is the point: the same Dockerfile produces the same image on any machine.
Shipping the artifact
"Image is pushed to a registry, or pulled from one" is the "Ship" act. The registry is the image distribution network — a private registry for your team, a public one for base images. The image never changes during shipping, which is what makes deployment deterministic: what you tested is exactly what you run.
Running the container
"docker run starts a container from the image" crosses from the Docker engine to the "Container runtime" cluster. "Container is isolated with namespaces and cgroups" is the isolation mechanism — namespaces give the process its own view of the file system, network and process table, cgroups cap its CPU and memory. "Container shares the host kernel but has its own file system" sits in the "Host operating system" band to make the contrast with a virtual machine explicit, and "The app process runs the same everywhere" is the payoff that justifies the whole stack.
Key relationships and takeaways
- An image is a read-only snapshot; a container is a running instance of it.
- Containers share the host kernel and fake isolation with namespaces — which is why they start in seconds where virtual machines take minutes.
- Cgroups limit what a container can consume, so one noisy neighbour cannot starve the host.
- The image's immutability is what makes "runs the same everywhere" true.
- Docker provides the packaging and the runtime; orchestrators like Kubernetes manage many containers across hosts.
When to use this visual
- Explaining to a developer why Docker works and how a container differs from a virtual machine.
- Onboarding a team to the build-ship-run model before they write their first Dockerfile.
- Grounding a conversation about environment drift — why "works on my machine" stops applying.
How it works
Annotate your Dockerfile steps
On the Dockerfile box, list the real layers of your build — base image, dependency install, copy source, run command — so the recipe is concrete.
Name your registries
Rename the registry step with your actual registries (a private ECR, a public image), and note which images you push and which you pull.
Add the network and volume boxes
Extend the runtime column with how your containers talk — a bridge network — and where state lives — a volume — since those are the two parts beginners most often miss.
Link to orchestration
If you use Kubernetes, add a note pointing from the running container to the Kubernetes visual, and what the kubelet changes about where the container runs.
Frequently asked questions
What is the difference between a container and a virtual machine?
A virtual machine virtualises the hardware: it carries a full operating system and a hypervisor mediates everything, which makes it heavy and slow to start. A container virtualises the operating system: it shares the host kernel and uses namespaces for isolation and cgroups for resource limits. That is why containers start in seconds and are so much lighter — the trade-off is that all containers on a host share that host's kernel.
What is an image versus a container?
An image is the static artifact — a read-only snapshot of the application and its dependencies, built from the Dockerfile. A container is that image in motion: a running process with a writable layer on top. You build an image once and can start thousands of containers from it, each isolated from the others.
How does Docker isolate containers?
With two Linux kernel features. Namespaces give each container its own view of the system — its own file system, network stack, process table and user ids — so it appears to be its own machine. Cgroups (control groups) limit and meter resources, capping how much CPU, memory and I/O a container can consume so one container cannot take down its neighbours.
Why does Docker make applications portable?
Because the image bundles the application with its runtime, libraries and configuration — everything except the kernel. Wherever a Docker engine exists, the image runs the same way, so the gap between a developer's laptop, a CI runner and a production server shrinks to the configuration that is deliberately kept outside the image.
Edit this visual in QueryChart (FlowJam)
Open this exact Docker canvas as your own chart, rename the clusters to your stack, and annotate your image pipeline.