Basis Lab

What a Container Actually Is

Six Views a Process Can Be Given Instead of Yours

Last timeNot a Small Machine

A namespace separates one kind of name rather than a machine, so the service calling itself process one is the host's process 24813 and the host's list settles every argument.

One sentence settles most arguments about containers. The program inside is an

ordinary process on the host, and it is in the host's own process list. If the

service calls itself process one and a shell on the host calls it 24813, those

are not two processes and not two machines. They are two names for one entry in

one table.

What got separated is not a machine but a handful of name lookups. The kernel

has no object called a container. It has processes, and each process carries a

set of views, and a view is the answer the kernel gives when that process asks

about one kind of name. Six of those views are separated when a container

starts, and what follows is what each one hides, what each one leaves exactly

as it was, and why the asymmetry between the host's view and the container's

explains almost everything that surprises people.

A view is a name lookup, not a box

The tempting picture is a box with the process inside it. There is no box.

There is a field on the process that points at a view, and the kernel consults

that field while answering.

Follow one question through. The service asks what processes exist. The kernel

looks at the asking process, reads which process-numbers view it belongs to,

collects the processes that are members of that view, and renames each one as

that view names it. A shell on the host asks the same question through the same

code, and the only thing that differs is the asker, so it gets the host's view,

which contains everything.

FIG 1The same question, asked by two processes
The branch is the lesson. One body of code, one process table, two answers, and the difference is entirely in which process asked. Note that only the right-hand branch sees both, which is why an argument about what a container is doing is settled from the host and never from inside it.

Three consequences come straight off that mechanism. A view is inherited by

children, so what is separated is a subtree of processes rather than a thing. A

view lasts as long as a process sits in it or something holds it open, so

stopping a container destroys nothing: the last process in the view leaves and

the view is released. And the containment is in one direction only. The host's

view holds every member of every container's view, and no container's view

holds anything of the host's, which is why the host is where you look and

inside is where you are misled.

The lesson stops here

6 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the planThe contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

The rest of this course

  1. 01One Kernel, Many Processes, and No Boot Sequence Anywhere
  2. 02Six Views a Process Can Be Given Instead of Yoursyou are here
  3. 03A Different Root Directory, and Why It Is Not a Wallopening only
  4. 04Half a Processor and 512 MB, and Why Only One of Them Killsopening only
  5. 05Layers, and Why One Line Rebuilds Sixty Megabytesopening only
  6. 06Why the File It Wrote Is Owned by Rootopening only
  7. 07Follow One Request In, and Name Every Translation on the Wayopening only
  8. 08The Boundary Is a View, and the Kernel Underneath It Is Sharedopening only

Read alongside