Introduction
Docker is a platform for packaging an application together with everything it needs to run, code, runtime, system libraries, and configuration, into a single unit called a container image. Running that image produces a container: an isolated process that behaves the same way regardless of what machine it runs on, because the environment it depends on travels with it rather than being installed separately on every host.
Cricket analogy: A touring squad that packs its own turf specification, kit, and match balls rather than trusting whatever the host ground happens to have plays the same game everywhere, mirroring how a Docker image bundles everything an app needs so it runs the same on any host.
Explanation
A container is not a full virtual machine: it shares the host machine's operating system kernel rather than emulating an entire separate operating system, which is why containers start in a second or two and use a small fraction of the resources a VM would need. Isolation between containers, and between a container and the host, is enforced by kernel features (namespaces and cgroups) rather than by hardware-level virtualization, so many containers can run efficiently on one host.
Cricket analogy: Multiple domestic teams sharing one stadium's ground staff and facilities rather than each building a private stadium still play fully separate matches thanks to scheduling and boundary rules, mirroring how containers share the host kernel but stay isolated via namespaces and cgroups.
Docker images are built from a Dockerfile, a text file listing the steps to assemble the image layer by layer: starting from a base image, copying in application code, installing dependencies, and specifying the command that runs when a container starts. Because each instruction creates a cached layer, rebuilding an image after a small code change is fast, since Docker only rebuilds the layers after the one that actually changed.
Cricket analogy: A team's matchday preparation checklist is built step by step, base fitness first, then specific drills, then final tactics, and if only the final tactics change, the earlier steps don't need to be redone, mirroring how Docker only rebuilds image layers after the one that changed.
Example
FROM node:20-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci # cached unless package files change
COPY . . # invalidates cache only for this and later layers
CMD ["node", "server.js"]Key Takeaways
- Docker packages an application with all its dependencies into a portable container image.
- Containers share the host OS kernel, unlike VMs, so they start fast and use fewer resources.
- Kernel namespaces and cgroups enforce isolation between containers on the same host.
- Images are built layer by layer from a Dockerfile, and unchanged layers are cached for fast rebuilds.
Practice what you learned
1. What does a Docker container package together?
2. Why do containers start faster than virtual machines?
3. What kernel features enforce isolation between containers?
4. What file defines the steps to build a Docker image?
5. Why is rebuilding a Docker image after a small code change usually fast?
Was this page helpful?
You May Also Like
Containers vs VMs
How containers and virtual machines differ in what they virtualize, how fast they start, and how much overhead they carry per instance.
What Is a Pipeline
What a CI/CD pipeline is: a sequence of automated stages that take source code through build, test, and deploy steps in order.
DevOps Lifecycle
How the DevOps lifecycle chains Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor into one continuous, automated feedback loop.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics