How Docker Works: an editable mindmap
Explore How Docker Works as an editable mindmap. Follow color-coded branches for Describe & build, Image, Container, Host kernel, Portable app, with supporting ideas and curved connections.
A mindmap of How Docker Works, with the main ideas arranged around a central topic and connections that show how they relate.
How Docker Works: an editable mindmap
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this mindmap
- Begin at “How Docker Works” in the centre, then explore any branch that answers your question. The branch colors keep each group of ideas together.
- Curved lines show relationships; arrowheads appear only where one idea leads to another. Select any idea in the editor to change its text, position, or connections.
Describe & build
This branch brings together “The Dockerfile is a recipe: base image, dependencies, files to copy, the command to run. It makes the build reproducible — the same file produces the same image everywhere.”, “docker build packages the app and its dependencies”.
Image
This branch brings together “An image is the packaging artifact: everything the app needs to run, frozen in read-only layers. It never changes once built.”, “Image is pushed to a registry, or pulled from one”.
Container
This branch brings together “docker run starts a container from the image”, “Namespaces isolate what the process can see (its own file system, network, processes); cgroups limit what it can use (CPU, memory). This is how many containers run on one host without fighting.”.
Host kernel
This branch brings together “Container shares the host kernel but has its own file system”.
Portable app
This branch brings together “Because the container carries its own runtime, libraries and configuration, “works on my machine” stops being a real failure mode.”.
Connections across the map
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.
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
Start at the central topic
Rename “How Docker Works” if you want to adapt this map to a specific project or lesson.
Develop the branches
Edit the supporting ideas, then add examples and notes where a branch needs more detail.
Connect related ideas
Draw curved connections across branches; use an arrow only when the relationship has a direction.
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 mindmap in QueryChart
Open this mindmap as your own editable free canvas. Move ideas, add branches, and draw new connections.