Containers: isolation without a virtual machine

The case

It worked on my machine. Not on the server.

Isaac built the order system with one version of Python on his laptop. The server had another version, and a library was missing. He spent the afternoon installing dependencies by hand, and every new server repeated the problem.

A VM per application would fix it, but each one would carry a full operating system just to run a program.

This post builds on Kernel, Processes and Threads and Virtual Machines.

The problem

A program depends on its environment

A program doesn't run on its own: it depends on a language version, libraries and system settings. When the development and production environments differ, the same code behaves differently.

A VM solves the separation, but at a cost: each application brings its own kernel and its own operating system, with their own memory, disk and boot time.

The solution

Container: an isolated process

A container is an ordinary process, running on the server's own kernel, with two things that isolate it: what it can see and what it can use. There is no second kernel. That's why a container starts in seconds and needs little extra memory.

Namespaces (what it sees)

Each container has its own view of processes, network, mount points and users. Inside it, the program believes it is alone.

At the store: the order system sees only its own processes and its own network port.

cgroups (what it can use)

The kernel limits how much CPU and memory the group of processes can consume.

At the store: the report can't take the memory the order system needs.

Image (the package)

A package with the file system and the application's dependencies, which runs the same way on any server.

At the store: the same package runs on Isaac's laptop and on the server.

Don't mix them up

Container × VM

Container

“Do I need another kernel, or just an isolated process?”

Example: Ten instances of the order system on the same server, sharing the kernel.
Focus: Starts in seconds, uses little extra memory, but the kernel is shared.

Virtual machine

“Do I need a different operating system, or stronger isolation?”

Example: A Windows system running on a Linux server, or customers who can't share a kernel.
Focus: Each VM has its own kernel. Stronger isolation, with more memory and boot cost.

Under the hood

Namespaces and cgroups

Namespaces and cgroups are Linux kernel features. A container is, in practice, a process that the kernel placed inside a set of namespaces and a cgroup.

Process namespace: the container sees only its own processes, and its main process appears with a number of its own, such as PID 1.
Network namespace: each container has its own interfaces and ports.
Mount namespace: the container sees its own file system, mounted from the image.
cgroup: sets CPU and memory limits, and counts what the group consumes.

Because all of this happens in the kernel, a container that exceeds its memory is terminated by the kernel, just like an ordinary process, and doesn't bring down the server.

Packaging

Image and registry

An image is an immutable package: the layers of the file system and the configuration for starting the program. Each layer is reused: two images that start from the same base share that base on disk.

A container is a running instance of an image. It gets a writable layer on top, and everything it writes there disappears when the container is removed.

Images are stored in a registry, from which servers download them. Anyone who needs data to survive the container uses a volume, a storage area mounted into it.

In practice

Limit and run

With Docker, one of the best-known tools, a single command starts a container with memory and CPU limits:

bash

docker run --memory 512m --cpus 1 nginx

The command downloads the nginx image, creates the namespaces, applies the cgroup and starts the process. A container that uses more than 512 MB is terminated, and the other containers on the server keep running.

Situation	Choice
Several Python services with different versions, on the same server	Containers
A Windows and a Linux system on the same hardware	VM
Database data that must survive the container	Volume, or a managed database service
Updating the application without touching the server	Replace the image and restart the container

Key terms

Six terms to remember

Tap a card to see the definition.

Quick test

Three questions, exam style

Two containers run on the same server. What do they share?

A team wants a database to keep its files after the container is removed. What should it use?

Which kernel feature limits how much memory a container can use?

Containers solve the problem of packaging and isolating an application without paying for a full operating system for it. Understanding namespaces and cgroups shows what is isolated and what isn't, which is why the choice between container and VM depends on the risk you accept and on the operating system you need. The next step is to see how these pieces run in the cloud.