Basic

What a container actually is

A container is a regular process, boxed in. Linux can run a program with a restricted view of the filesystem and a limited set of resources; Docker is a thin wrapper that makes that box easy to build and ship. Nothing magical happens at runtime: the isolation is enforced by the kernel the moment the process starts.

What you will see

The process is killed by the kernel, not by Python. Exit code is non-zero and the message mentions memory.

About 2 min of reading

Try It

Run one command in a box and watch it exit

Install the CLI

docker --version

Before you run it, say out loud what it will print. Then open the answer.

What it prints

A version line, e.g. Docker version 3.x. If it is missing, install the distro package before continuing.

Run the smallest box

docker run --rm echo hi

Before you run it, say out loud what it will print. Then open the answer.

What it prints

Prints hi. The --rm flag deletes the box when it exits, so `docker ps` shows nothing afterwards.

Confirm nothing leaked

docker ps

Before you run it, say out loud what it will print. Then open the answer.

What it prints

An empty table. The box existed only while the command ran.

See the kernel enforce a budget

docker run --rm --memory=50m python -c 'x = bytearray(200_000_000)'

Before you run it, say out loud what it will print. Then open the answer.

What it prints

The process is killed by the kernel, not by Python. Exit code is non-zero and the message mentions memory.

If your distro has no cgroup v2 support, the flag is ignored and the process succeeds. That is a kernel feature, not a Docker bug.

Data Flow

From a recipe to a running process

1 Write a Dockerfile: base image, files to copy, command to run

↓

2 Build: each line becomes a cached layer on disk

↓

3 Run: kernel creates a process with namespaces and a resource budget

↓

4 Exit: the box is deleted, the recipe and its layers stay

Why this works

What you get from isolation

A container gives you three things: a filesystem that does not leak host files, a process tree that does not see host processes, and a resource budget that the kernel enforces. That is enough to run one program in a predictable environment without pretending it is a separate OS.

What isolation does not give you

A container is not a security boundary against a determined attacker, and it is not a way to run Windows programs on Linux. The kernel is shared; anything that can read /proc can read the container's state. Isolation is for reproducibility and dependency clarity, not secrecy.

Examples

A container is a process

When you run docker run python -c 'print(1)', the kernel creates a process, puts it in its own set of namespaces (a private view of the filesystem, its own process tree, no access to the host's network sockets), and records which resources it may use. The container is that process plus a recipe for how to build it.

The isolation is a kernel feature

Namespaces hide resources from the process; cgroups account for them. unshare and chroot are the same primitives Docker uses, just without the packaging. You can see the isolation with ps aux on the host: the container's process is a normal PID, just with a restricted view.

The box is disposable, the recipe is not

You never edit a running container as a workflow. You write a recipe (a Dockerfile), build it, run it, and throw the box away. The recipe is the durable artifact; the container is a cache of one execution of that recipe.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

Next Lesson

Reading a version string

Reading a version string →