Why containers?
“It works on my machine” used to end many conversations. Containers package an application with everything it needs and run it the same way everywhere. Compare them with virtual machines in 3D, and learn what actually isolates a container.
In this lecture you will
- Explain the deployment problems containers solve
- Compare containers and virtual machines — isolation, size and start-up time
- Describe the kernel features that make containers possible
- Distinguish an image from a container
A developer finishes a feature, tests it on their laptop and hands it over. In staging it crashes: a different version of a library, a missing system package, an environment variable nobody wrote down. For decades, teams fought this with long setup documents and fragile deployment scripts. Containers changed that by shipping the application together with its environment.
What a container packages
A container bundles an application with everything it needs to run: the language runtime, libraries, system tools, configuration defaults and the code itself. The only thing it doesn’t bring is the operating-system kernel. The result runs the same way on a developer’s laptop, a CI runner and a production cluster.
That consistency is why containers became the standard unit of deployment for cloud software — and the foundation for Kubernetes, which the rest of this course builds towards.
Virtual machines and containers
Before containers, the common way to isolate applications on one server was the virtual machine. Step through the two approaches side by side.
- Two ways to share a serverBoth approaches run three applications on one physical machine, isolated from each other. The difference is where the isolation happens.
- Virtual machinesA hypervisor divides the hardware into virtual machines. Each runs a complete guest operating system — its own kernel, services and memory — before your app even starts.
- ContainersContainers skip the guest OS. They are ordinary processes on the host, isolated by the kernel, so they start in about a second or less and use far less memory.
- Where isolation happensA VM’s boundary is a whole virtual machine enforced by the hypervisor. A container’s boundary is kernel features — lighter, but all containers share one kernel.
- What both give youEach application carries its own libraries and runtime. Two apps can need different versions of the same library without conflict.
Neither replaces the other. In the cloud, containers usually run inside virtual machines: the VMs isolate customers from each other, and containers pack many applications efficiently inside each VM.
The saving is easy to estimate. Fill one server with services both ways:
Memory is usually the first limit, so the servers are filled by memory alone; CPU tells a similar story. The smaller each service, the bigger the saving from not carrying a guest operating system each.
How isolation actually works
A container is not a special object inside Linux — it is a process (or a group of processes) wrapped in two kernel features:
- Namespaces
- Control what a process can see. In its own namespaces, a container sees only its own processes, network interfaces, hostname, users and file system mounts.
- cgroups
- Control groups limit and account for what a process can use — CPU time, memory, disk and network I/O. This is how container resource limits are enforced.
- Layered file system
- A union of read-only image layers plus a thin writable layer on top, giving each container its own view of the file system.
Run the same commands inside a container and on its host, and namespaces and cgroups become concrete:
The container is an ordinary Linux process: inside, namespaces show it a private world; outside, the host sees PID 48213 in a cgroup with a 256 MiB memory limit. Output formats are real; process IDs and addresses are examples.
Because containers share the host kernel, they are lighter than VMs, but a kernel vulnerability can affect all of them. Teams handling untrusted code often add stronger sandboxing or run such workloads in separate VMs.
Images and containers
Two words are often confused:
- An image is a read-only template: the files and settings needed to run the app, built from a recipe called a Dockerfile. Images are versioned and stored in a registry.
- A container is a running instance of an image, with its own writable layer, process and network identity. One image can start any number of containers.
docker pull nginx:1.27 # download an image from a registry
docker run -d -p 8080:80 nginx:1.27 # start a container from it
docker ps # list running containersNext, we open up an image and see how it is built, layer by layer — and why the order of lines in a Dockerfile can turn a two-minute build into a two-second one.
Key takeaways
- A container packages an app with its libraries and runtime, so it runs the same on a laptop, a CI runner and production.
- Virtual machines virtualize hardware and each runs a full OS; containers share the host’s kernel and isolate processes.
- Containers are built on Linux namespaces (what a process can see) and cgroups (what it can use).
- An image is a read-only template; a container is a running instance of it with its own writable layer.
Check your understanding
3 questions · answers explainedQ1What is the main reason containers start faster and use less memory than virtual machines?
Q2Which Linux feature limits how much CPU and memory a container may use?
Q3What is the relationship between an image and a container?