Docker container

A program rarely runs alone. It needs certain helper programs, certain versions of them, and certain operating system settings. If one of these is missing, it won’t start or will behave differently than expected. A Docker container solves this problem by packing the program together with all these ingredients into a single package. This package can be copied to another machine and started there without installing anything extra. Docker is the name of the software that creates and runs such packages; it made the technology popular starting in 2013.

The end of “But it works on my machine”

The classic dispute in software development goes like this: a developer writes a program, everything works on their laptop. On the company’s server, it crashes. The reason is almost never the program itself, but the environment around it. The laptop had a newer version of a helper library, the server an older one. Containers end this dispute because the environment is shipped along with the program.

For companies, speed matters most of all. A container starts in a fraction of a second. If ten times as many people suddenly visit an online shop in the evening, the data center simply starts a hundred additional copies of the same container. When demand drops, they’re shut down again. This flexibility is the foundation that keeps large services affordable in the first place.

In the AI world, there’s another point to add: traceability. AI software depends on a great many exact version numbers. Anyone who wants to verify a result a year later needs exactly the same environment. A container preserves it.

Image, container, and the shared system kernel

At the start there’s a recipe, a simple text file. It states, line by line, what belongs in the package: which base system, which additional programs, which of your own code. From this recipe, Docker builds an image. An image is the immutable template, comparable to a printing plate. Starting the image creates a running container from it. Any number of containers can be started simultaneously from a single template.

It’s important to distinguish this from a virtual machine. A virtual machine simulates an entire second computer, including its own operating system. That costs several gigabytes of storage and minutes at startup. A container, by contrast, shares the host machine’s system kernel, i.e. the innermost part of the operating system. It contains only the layers above it. That’s why it’s often only a few hundred megabytes in size.

A common misconception is that containers are completely isolated from one another. They are separated, but they depend on the same system kernel. Anyone who needs maximum security between different customers therefore often combines containers with virtual machines after all. A second misconception: containers don’t remember anything. If you delete a container, any changes inside it are gone. Data must be deliberately written to an attached storage volume.

From phone photo services to AI data centers

Almost every major online service runs in containers today. When you stream a video, send a message, or open a banking app, containers are responding to you in the background. They’re usually managed by Kubernetes, a piece of software that automatically distributes, monitors, and restarts thousands of containers in case of failures. That’s why Docker and Kubernetes almost always appear together in job listings.

You’ll also come across the term when trying out AI models. Providers of graphics cards and cloud services distribute ready-made images in which all the drivers and libraries already fit together. Instead of spending an afternoon on installation, you start a container and get going.

In business news, the topic comes up as a cost question. Containers make it possible to divide server capacity more finely and thus use it more efficiently. That’s why containers are the foundation of modern cloud offerings, where you only pay for the compute time actually used.