“Works on my machine”: containers

§ 01A year later

That gap, a year on, is on six laptops. Fennel now has six engineers, and each of them set up their own laptop by hand. Riley joined last month and spent the whole first week installing tools from a page on the team wiki. The page was months out of date: Sam’s notes all over again.

Fennel also has a second machine now, called staging, where each release is tried out before customers see it. Production still runs on one rented machine. Both were set up by hand, at different times, by different people.

From Jordan’s seat, none of this looks like a server problem. It shows up in three other places:

• Onboarding takes a week. A new engineer’s first days go to installing things, not to working on Fennel.
• Some bugs happen only in production. A customer reports one, an engineer tries the same thing on their laptop, and it works. “Can’t reproduce” turns into a regular line in the weekly update.
• Releases pass on staging and then fail in production. Staging was supposed to catch exactly these.

Nobody is being careless. This is last chapter’s drift, now on every machine Fennel has. Each laptop, the staging machine and production was set up by hand, and each has quietly become a little different from the others. When the software installed on two machines differs, small incompatibilities appear, and code that passed its tests on one machine can fail on the other. Here’s what one of those bugs looks like up close.

§ 02Same code, two machines

Here is one of those bugs, step by step, on Riley’s laptop and Fennel’s production machine. Scroll through it. Two questions along the way unlock what happens next.

§ 03What goes in the image, and what doesn’t

That also answers Riley’s first week. Instead of following a wiki page to install Python, the libraries and the tools one at a time, a new engineer downloads the image and runs it, and starts with exactly what everyone else has.

This is why an image can’t drift the way Sam’s server did. The server drifted because people changed it by hand, one sensible fix at a time. Nobody can change a built image by hand, so the image that passed the tests is exactly the image that ships.

Two things stay out of the image on purpose. Settings that differ from place to place, like the database address and its password, are handed to the app when it starts. That’s why one image can run in staging and in production. And the data the app writes, like orders, is kept outside the app, in Fennel’s database, so replacing the app doesn’t wipe it out.

In the last chapter you found that the code isn’t the whole app. The image isn’t the whole app either: it’s the code plus what it needs to run, without the settings and data that make each place different. Keeping the data out has a name of its own.

The two words work as a pair. The image is immutable, so every fresh copy starts out exactly the same. The app is stateless, so throwing a copy away costs nothing. The next section shows what those running copies are.

§ 04Build once, run many: images and containers

An image is a package. It does nothing until a machine runs it. Here is how one image gets from Riley’s laptop to every machine that needs it.

Riley builds fennel-app:v43 once and uploads it to a registry, a shared store of images that Fennel’s machines can reach. Engineers call that upload a push. The laptop, the staging machine and production then each download, or pull, the same image from it.

Running an image starts a container. Last chapter called a running app a process; in practice an app is usually one main process, sometimes with a few helper processes it starts itself. A container is that group of processes, started from an image and isolated from the rest of the machine by the machine’s operating system. The processes inside see the files that came from the image, not the machine’s own, and they see each other but none of the machine’s other programs.

One image can run as several containers, on one machine or on many; in Fig. 02, production runs two.

A running container can write files, and someone can even change things inside it by hand. But containers don’t last. Every release replaces the running containers with new ones, started from the new image, and when a container is replaced, the changes made inside it go with it. Each new container starts fresh, with exactly what the image holds. Because Fennel’s app is stateless, that costs nothing: its orders were never inside the container.

You’ll hear the name Docker in conversations like these. The next chapter places it.

§ 05Not a small VM

Sam has a one-line summary of all this, and it’s one you’ll hear often: “a container is basically a small VM.” Last chapter’s virtual machine was a whole computer made in software, with its own operating system. Before reading on, decide whether that’s what a container is.

The core of the operating system has a name, the kernel: the part that runs the hardware and every process on it. Here is the same machine running three apps two ways.

Leaving out the kernel is what makes a container small and quick to start. A VM has to carry a whole operating system and boot it, the way a computer starts up. A container skips both: starting one just starts a process on a kernel that’s already running. An image often does include an operating system’s basic files and tools (engineers will say an image is “based on Debian”, for example), but never its kernel, and nothing boots. So a container is typically tens to hundreds of megabytes and starts in seconds, while a VM is typically gigabytes and takes tens of seconds to minutes to boot. Those are rough orders of magnitude, not measurements; the real numbers depend on the app and the setup.

Without a whole operating system and kernel for every app, the same machine has room for many more apps. How many more depends on the apps themselves.

The price is a thinner wall. Every container on a machine shares one kernel, so a flaw in that kernel is shared by all of them, while each VM has its own kernel. That’s why cloud providers that run many different customers’ containers on the same machines put each customer’s containers inside a lightweight VM of its own; AWS does this for some of its services. Containers are still walled off from each other, though. The wall between containers isn’t missing, it’s just thinner. For a company running only its own code, that trade-off is usually fine.

You also don’t have to choose one or the other. When Fennel rents a machine from a cloud provider, that machine is usually a VM, and Fennel’s containers run inside it. In the cloud, you usually get both: containers, running inside a VM.

§ 06The conversation

After the photo bug, Sam brings a proposal to the next planning meeting.

“Let’s containerize everything.”

Sam

So containers settle what runs on each machine. They leave open what happens to the machines themselves:

• Who notices the machine died?
• Who starts its containers again, and on which machine?
• What happens to anything written only on that machine?
• Once there are many machines, who decides what runs where?

Those jobs have a name. We’ll name it in the next chapter.