OCI 1.0 separates image interchange from container execution

Portability requires agreement about more than the name of a container image. A tool that constructs an image and a runtime that executes a container need compatible representations, but they consume different inputs. The first stable Open Container Initiative specifications formalize those two parts of the process. The image specification describes the artifact, while the runtime specification describes the prepared local bundle and execution contract.

Docker's 19 July explanation follows the release of the runtime and image specifications as version 1.0. Stephen Walli emphasizes that this is a specification milestone and that the certification program remains under development. A stable document gives implementers a target. It does not establish that every product using container terminology has passed a certification process.

I value Docker principally for turning an application environment into a transferable artifact. These specifications give that transfer a definition beyond a particular product's implementation. The interesting engineering detail is where they divide the work, because an image stored for distribution is not yet the same object as a container prepared for execution on a host.

An image manifest identifies the parts

The OCI image specification at v1.0.0 defines an image in terms of a manifest, filesystem layers and configuration, with an optional image index. The manifest records the content-addressable identities of the filesystem changesets that make up the image. Configuration supplies information such as application arguments and environment settings.

That structure connects identity to contents. A consumer does not have to treat each layer as an opaque filename whose meaning depends only on a server's naming choices. The image document identifies the components by digest, which lets software refer to the same component through its content identity. The specification's stated goal is interoperability between tools that build, transport and prepare images.

The manifest definition is more precise about the scope of one manifest. It describes one image for a particular architecture and operating system. A separate image index can point to several manifests. That keeps the description of one platform-specific image distinct from the selection among implementations for different platforms.

The manifest's required configuration field is itself a descriptor that references the configuration by digest. Layers form an ordered array of descriptors. These are relationships between objects, rather than a single undifferentiated archive. An implementation has to interpret those relationships correctly to reconstruct the intended image.

Layer order is part of the artifact

The manifest requires the base layer at array index zero, followed by subsequent layers in stack order. It also specifies that the final filesystem must match applying those layers to an empty directory. A set containing the correct layer blobs is therefore insufficient if their ordering is wrong.

This matters because a layer describes a filesystem change, and the effect of a later change depends on what earlier changes established. The image carries a construction order for the resulting filesystem. A consumer cannot reorder the descriptors simply because it has downloaded all their referenced contents successfully.

The manifest specification requires support for tar and gzip-compressed tar layer media types. It also includes nondistributable variants. These declarations make format support a concrete implementation requirement. An implementer reading the manifest must understand what a descriptor's media type says about the referenced bytes before it can apply the corresponding changeset.

Schema numbering contains another historical detail. The required manifest schemaVersion is 2, with the specification explaining that this preserves compatibility with older Docker versions. Releasing OCI 1.0 does not imply that every version field inside its formats starts at 1. The document version and the serialized schema field have different purposes.

The runtime consumes a local bundle

The runtime specification's bundle definition describes files organized on a local filesystem. A required config.json sits at the root of the bundle directory. The container root filesystem is the directory referenced by root.path when that property is present in the configuration.

This local representation has a different purpose from the image manifest and its layer descriptors. Image preparation has already produced the material needed by the runtime. The bundle definition explicitly limits itself to how the container and its configuration are stored locally so that a compliant runtime can consume them.

The directory itself is not part of the bundle. The specification explains that an archive of a bundle places the artifacts at the archive's root rather than inside an extra containing directory. That detail can sound minor until software constructs a bundle with the wrong nesting. Interoperability depends on such concrete layout rules, not only agreement about the broad idea of running a container.

Image preparation and runtime execution therefore remain connected operations with a defined representation between them. The image specification describes translation toward a runtime bundle, and the runtime specification defines the local input. A tool may participate in one stage of that process without implementing the entire application platform around it.

Platform choice and platform integration remain distinct

The image index's ability to refer to platform-specific manifests recognizes that one application name can have several implementations. The runtime representation then describes execution inputs for the selected platform. These are useful building blocks for portability, but neither says that every application's behavior becomes identical across operating systems.

Walli's account explicitly rejects the idea that OCI is only about Linux. It describes work applicable to multiple operating systems and processor architectures. The standards are intended to accommodate that range while still making the actual platform of a particular image explicit.

For someone selecting an image, this distinction matters. A multi-platform collection does not make each individual manifest independent of architecture or operating system. The manifest definition states the opposite. Software must select a suitable member of the collection and prepare it for the runtime that will execute it.

I find the separation useful because it makes portability a set of reviewable contracts. A producer can describe an image's parts and target platform. Preparation can create the local bundle. The runtime can consume that bundle. A claim about compatibility should identify which of these relationships the implementation satisfies.

A standard does not supply the complete platform

Docker's explanation distinguishes OCI work from the integrated Docker product. The specification covers image layout and runtime behavior, while Docker also supplies application-facing tooling and other platform functions. Agreeing on the lower-level formats leaves substantial implementation and product work outside those documents.

Containerd provides another example of that surrounding work. Walli describes responsibilities including image transfer and storage, execution supervision and support for storage and network attachments. A specification does not eliminate the need for a maintained implementation that performs those operations and presents an interface to its callers.

The distinction also applies to orchestration. A runtime bundle does not decide where an application should run in a cluster. Its local configuration becomes useful after another system has made placement and preparation decisions. Standardizing the representation lets systems share assumptions at that point without requiring them to use an identical scheduling model.

This limited scope is a strength when it produces dependable interfaces. A format can remain useful across platforms that make different choices about deployment and administration. Expanding the claim to every part of application delivery would obscure which parts the published specifications actually define.

Certification remains separate work

Walli says the certification working group is still defining how projects and products will demonstrate conformance. As of this post, the release of version 1.0 does not provide completed certification evidence for an arbitrary implementation. Engineering teams can read the requirements, but product claims need to distinguish implementation intent from the result of a formal process.

The image specification itself uses normative requirement words and defines compliance in terms of satisfying its mandatory requirements. That is useful to an implementer working through the document. A certification program adds a shared process for demonstrating conformance, which is why the two milestones should not be collapsed into one event.

Docker also identifies distribution and signing as ideas for further OCI work. Those statements describe possible future scope, not capabilities standardized by this release. An image can have a content identity while the surrounding mechanisms for discovery, transfer and trust still require their own agreements.

The immediate result is a stable pair of specifications that implementers can work against. One defines the image's content relationships and filesystem construction, while the other defines the locally prepared bundle. Tools can use those contracts to exchange and execute artifacts while continuing to make their own choices about the broader container platform.