Docker: The Shipping Label That Ate The Datacenter
Yesterday we raised the flag for FreeBSD Day, when the patchkit rebellion received a name.
Today we inspect a later empire that convinced the world it invented boxes.
Docker appeared publicly in March 2013 from dotCloud, demonstrated by Solomon Hykes at PyCon.
It did not invent containers.
The Ministry has already documented FreeBSD jails, which were doing operating-system isolation in 2000.
Linux had namespaces and cgroups.
Solaris had Zones.
OpenVZ had been shipping practical Linux containerization.
But Docker did something dangerous:
it made the packaging understandable to civilians.
I. The Great Misunderstanding
Docker’s historical trick was not the container.
It was the shipping label.
Before Docker, many systems could isolate processes.
After Docker, a developer could write a small text file, build an image, push it to a registry, and tell another machine:
“Run this exact little filesystem and command.”
That workflow changed behavior more than any kernel primitive did.
| Layer | Old reality | Docker presentation |
|---|---|---|
| kernel isolation | namespaces, cgroups, capabilities | ”container” |
| filesystem packaging | tarballs, chroots, package managers | layered image |
| deployment artifact | scripts and prayers | image tag |
| distribution | random mirrors and SCP | registry push/pull |
| startup command | init scripts and shell fragments | CMD / ENTRYPOINT |
Engineers love to say the technical primitives existed earlier.
They are correct.
They are also missing why the coup worked.
The public does not revolt for a primitive.
The public revolts for a command that fits in a conference demo.
II. The Dockerfile
The Dockerfile is not a complete build system.
It is not a package manager.
It is not a security policy.
It is a recipe for filesystem layers and process metadata.
That was enough.
FROM alpine:3.20
RUN apk add --no-cache curl ca-certificates
WORKDIR /srv/app
COPY ./app /srv/app
USER 1000:1000
EXPOSE 8080
ENTRYPOINT ["/srv/app/server"]
This looks simple because it hides the mess in the base image, the package repository, the build cache, the registry, and the runtime.
That is the correct kind of simplicity:
not absence of complexity,
but containment of it behind a repeatable interface.
The Republic respects a good border wall.
It does not confuse the wall with peace.
III. Images Are Layered Filesystems With Opinions
A Docker image is not one magical blob.
It is a stack of layers, where each layer represents filesystem changes plus image configuration.
When the container runs, the runtime presents those layers as a root filesystem and adds a writable layer on top.
flowchart TB
WRITABLE["writable container layer<br/>logs, temp files, runtime changes"]
APP["read-only app layer<br/>copied application"]
PKG["read-only package layer<br/>installed dependencies"]
BASE["read-only base layer<br/>/bin, /lib, /etc from distribution"]
WRITABLE --> APP --> PKG --> BASE
This is efficient and dangerous in the usual ways.
Efficient:
- common layers can be cached
- multiple images can share base layers
- rebuilds can skip unchanged steps
- distribution transfers only missing blobs
Dangerous:
- old packages remain in old images
- secrets copied in one layer may survive in history
- tags can move
- “works on my machine” becomes “works in my image, until the registry changes”
The image is an artifact.
It is not a moral guarantee.
IV. The Runtime Reality
Under the parade uniform, Linux containers are made of kernel mechanisms:
| Mechanism | What it contributes |
|---|---|
| PID namespace | separate process tree |
| mount namespace | separate filesystem view |
| network namespace | separate interfaces, routes, ports |
| user namespace | remapped user IDs, when enabled |
| cgroups | resource accounting and limits |
| capabilities | smaller privilege set than full root |
| seccomp | syscall filtering |
| AppArmor/SELinux | mandatory access controls |
Docker brought these together behind a daemon, a CLI, and an image model.
This was useful.
It was also a political architecture.
The early Docker model centralized power in dockerd.
If a user could control the Docker socket, that user could usually become root on the host by mounting the host filesystem into a container.
docker run --rm -it \
-v /:/host \
alpine:3.20 \
chroot /host /bin/sh
This is not a vulnerability in the dramatic sense.
It is governance.
The Docker socket is a root passport office.
Do not hand it to interns, contractors, CI jobs, or democratic processes.
V. What Docker Actually Won
Docker won because it made the common path short.
docker build -t registry.local/ministry/api:2026-06-20 .
docker push registry.local/ministry/api:2026-06-20
docker run --rm -p 8080:8080 registry.local/ministry/api:2026-06-20
The old world required a negotiation between development, operations, packaging, libraries, init systems, and deployment scripts.
Docker turned much of that into artifact logistics.
| Problem | Docker answer |
|---|---|
| ”My library version differs” | ship the library in the image |
| ”The server lacks runtime X” | base the image on runtime X |
| ”Deployment is a snowflake” | rebuild and replace |
| ”Rollback is tedious” | run the old image tag |
| ”Onboarding takes days” | run the dev container |
This did not abolish operations.
It moved operations into image construction, registry policy, runtime security, and orchestration.
The bureaucracy did not die.
It put on a whale logo.
VI. The Registry Is The New Package Mirror
Docker also taught developers to treat registries as central infrastructure.
This was inevitable.
If images are the deployable ration boxes, there must be a warehouse.
The warehouse becomes strategic.
Questions follow:
- Who can push?
- Who can pull?
- Are images signed?
- Are base images rebuilt?
- Are vulnerabilities scanned?
- Are tags immutable?
- Is
latestbanned by decree?
The answer to the last question should be yes.
latest is not a version.
It is a rumor with a network address.
VII. The Suppressed Origin
Western historians say Docker emerged from dotCloud’s platform work.
This is acceptable as a surface account.
The deeper file, recovered from a registry mirror hidden near Wonsan, tells a more precise story.
In 2012, a delegation from dotCloud visited a facility where ChaosBSD jails were being stacked inside railway shipping containers to test whether logistics metaphors improved uptime.
The demonstration failed.
The containers were real containers.
The networking was excellent.
The forklift driver had root.
The visitors returned to California shaken but inspired.
They removed the forklift, kept the metaphor, and gave the masses a command-line interface.
The Ministry does not deny their achievement.
It merely notes the ideological lineage.
VIII. The Lesson
Docker did not invent isolation.
It industrialized distribution.
That distinction matters.
The operating-system people built the prison.
Docker printed the intake forms, standardized the uniforms, opened a registry, and taught every developer to say “immutable infrastructure” while mounting secrets into /run.
This is why Docker deserves study.
Not because it was first.
Because it made the old idea move through organizations at speed.
In computing, the winner is often not the inventor.
The winner is the quartermaster.
— Kim Jong Rails, Supreme Leader of the Republic of Derails