OCI is the industry collaborated effort to define an open containers specifications regarding container format and runtime - that is the official tone and is true. The history of how it comes to where it stands today from the initial disagreement is a very interesting story or case study regarding open source business model and competition.
But past is past, nowadays, OCI is non-argumentable THE container standard, IMO, as we'll see later in the article it is adopted by most of the mainstream container implementation, including docker, and container orchestration system, such as kubernetes, Plus, it is particularly helpful to anyone trying to understand how the containers works internally. Open source code are awesome but it is double awesome with high quality documentation!
OCI has two specs, a Image spec and a Runtime spec. Below is the overview of what they cover and how they interact.
Image spec defines the archive format of container images, which will be unpacked to the
runtime bundlefrom which we can run a
To the top level, it is just a tar ball, after untar-ed, it has a
The layout isn't that useful without a specification of what that stuff is and how they are related (referenced).
We can ignore the file
index.jsonis the entry point, it contains primary a
manifest. which listed all the "resources" used by a single container image. Similar to Manifest.xml file for an Android apk.
manifestcontains primarily the
The config contains notably 1) configurations if the image, which can and will be converted to the runtime config file of the runtime bundle, and 2) the layers, which makes up the root file system of the runtime bundle, and 3) some metadata regarding the image history.
layers are what makes up the final rootfs. The first layer is the base, all the other layers contain only the changes to its base.
Put that into a diagram, roughly this.
More on Layers
A config file is just a json and is easy. So the interesting part is how to represent a file system as a layer, and how to union all the layers, as we know the layers are diffs.
- How to represent a layer?
- For the base layer,
tarall the content;
- For non base layers,
tarthe changeset compared with its base.Hence, first detect the change, form a
changeset; and then tar the changeset, as the representation of this layer.
- How to union all the layers?
Apply all the changesets on top of the base layer. This will give you the rootfs system.
Once the Image is unpacked to a runtime bundle on the disk file system, runtime spec will take care from there. Roughly, the job is to create a container and run the (processes in the) containers.
A container has a lifecycle, at the essence, as you can imagine, it can be model as following state diagram.
You can throw in a few other actions and states, such as
paused, but those are the fundamental ones.
note: Somehow, the left arrow (
<) will sabotage the whole diagram using my current blogspot template. I just omit it until I find a time to fix it.
Image, Container, and Processes
Containersare created from (container)
Image, you can create more than one containers from a single Image, and you can repack the containers, possible with changes to base image, back to a new Image.
After you get the containers, you can run
processinside of that container, without all the nice things about a container, most notably, self-contained - don't depend on the host libraries.
Implementations and Ecosystems
runCis the reference implementation of the oci runtime specification. The diagram below shows its relationship with other projects, mostly with docker origin, Each entity below follows the format of
To make things looks even more crowded/flourished, throw in some kubernetes things.
CRI is the Container Runtime Interface defined by kubernetes to allows for pluggable container runtime for k8s. There are currently several implementations, among them are
cri-o, both are actually end up use