This page assumes you know nothing. Before you can read the parent note Containerization with Docker comfortably, every word it uses has to mean something concrete in your head. So we build each symbol, term, and picture from the ground up, in an order where each one leans only on the ones before it.
Before any Docker term, you must see what an "environment" is.
Look at the figure below. Your program (the amber box) is tiny. The stack of things underneath it — that grey tower — is the environment. Change any one brick in the tower and the amber box on top may crash.
Why the topic needs this: the parent note's opening line — "it works on my machine" — is entirely about two machines having different towers. Every later idea (image, container, layer) is a strategy for shipping the whole tower instead of just the amber box.
To understand sharing later, you need three plain words about a computer.
Picture the host as a building, the kernel as the building's single central power-and-plumbing system, and each process as a tenant plugged into that shared system.
Why the topic needs this: the parent claims containers are light because they "share the host's Linux kernel." That sentence is meaningless until you know a kernel is one shared core and a container is just a process — not a whole new building.
The parent uses two exact kernel words. Here they are, from zero.
Why the topic needs this: these two features are literally how a container isolates itself without needing its own operating system. Everything the parent calls "lightweight isolation" is namespaces (see) + cgroups (use).
Left (VM): each application sits on top of its own full guest operating system. Every guest OS is gigabytes and takes seconds to boot. The hardware is virtualized underneath them.
Right (Container): each application is just a process isolated by namespaces/cgroups. There is no guest OS — every container reuses the one host kernel at the bottom.
Why the topic needs this: the entire reason Docker won is on the right side of this figure — you skip the grey "Guest OS" blocks. If you don't see what got deleted, "lightweight" is just a word.
Now the trickiest picture in the parent note: layers. Build it slowly.
A file marked read-only can be looked at but not changed. A writable file can be edited. Hold onto that distinction — it decides what survives.
Look at the figure: each instruction adds a transparent sheet. Reading the final filesystem is like looking straight down through all the sheets at once — the top-most version of each file wins.
Let me name the symbols the parent's cost formula uses, before you meet the formula:
L1,…,Ln — the list of layers, from bottom (1) to top (n). The subscript is just an index (a position number).
ci — the cost (build time) of layer number i. The letter c = cost, the little i = "which layer".
k — the index of the first layer that changed since last build.
∑i=knci — the summation symbol. It means "add up ci for every i starting at k and ending at n." Why this tool? We need one compact way to say "total the costs of the changed layer and everything stacked above it" — a sum is exactly the tool that adds a running list.
So the parent's rebuild cost Crebuild=∑i=knci reads in plain words: "the build time is the sum of the costs of the first changed layer and every layer above it" — because a changed layer forces everything resting on top of it to rebuild too.
Last foundation, because the parent warns about it as a mistake.
Why the topic needs this: the parent's mistake "the container will remember my model file" is exactly the ephemeral trap. Data you must keep goes in a volume — tying into Reproducibility in ML and Container Registries.
