Containers Aren’t Just Linux Processes: OCI Explained

When we say "container," a developer's mind jumps to Docker, a few docker run incantations, and blissful ignorance of what's under the hood. But dig a little deeper, and you'll find: a container is not just a Linux process with a sprinkle of chroot. It's a whole zoo of abstractions, standardized by the Open Container Initiative (OCI).

What's behind the docker run magic?

OCI isn't a single standard; it's three specs that together define what a "proper" container looks like:

• Runtime Specification — how to start and stop a container using namespaces, cgroups, and other kernel goodies.
• Image Specification — what's inside the image: layers, config, metadata. Everything we push to a registry.
• Distribution Specification — how to exchange images over the network without reinventing the wheel.

Basically, OCI is a gentleman's agreement that lets Podman, containerd, CRI-O, and even your homebrew bash script understand each other. Without it, we'd still be living in the "it works on my machine" world.

Why aren't they just processes?

Yes, at the core of a container is a process (or a group of processes), but between you and that process lies a layer of magic: mounting filesystems, setting up networking, managing resources. Try manually configuring cgroups for CPU and memory — and you'll understand why Docker makes money. OCI takes on all that pain, offering a unified interface.

By the way, if you've ever written your own container runtime (and who hasn't?), you know: implementing an OCI Runtime is a quest on par with "assembling IKEA in total darkness." But the result is worth it: your container will run anywhere there's an OCI-compatible runtime.

METABYTE studio's comment: We love digging into OCI too, but usually trust containerd — it asks for a laptop reboot less often. And if you need a custom container build for production, we know where the rakes are.