The Open Container Initiative, a consortium founded to develop open standards around Docker-style containers across platforms, has delivered 1.0 milestones for two crucial specifications under its banner.
The new standards are not likely to affect the way developers work with containers. The real impact is likely to be felt by commercial producers of container-related products, especially if they are angling to have OCI certification applied to what they produce.
Image format and runtime
OCI’s newly finalised standards cover two key components of the container ecosystem—the image format for containers, and the runtime specification. The OCI Image Format, as the first is formally called, is easy enough to grasp. It describes the way a container image is laid out internally and what its various components are.
OCI likens the Image Format to Linux package manager formats like .deb and .rpm, “a dependable open specification that can be shared between different tools and be evolved for years or decades of compatibility.”
The other standard, the OCI Runtime Specification, describes how a container is configured, executed, and disposed of on all the major platforms where OCI containers run—Linux, Windows, and Solaris. All three platforms now support Docker-style containers, but each platform has its own implementation quirks, and the spec is intended to encompass those.
Both image and runtime specifications have reference implementations in Go, largely derived from the implementations that are already in wide use.
Not covered
There are many aspects to containers that the OCI standards do not yet cover, but which the OCI eventually intends to create specifications for. Container distribution, for instance, the way a container runtime pulls an image from a repository, is not yet covered by a spec.
The next big step for OCI standards will be using them as the basis for a certification program. Apps and services that purport to adhere to the OCI standards can be certified by the OCI by way of a test suite that checks to see if the way they implement the container image format and runtime behaviours are up to snuff. The companies themselves don’t get to self-apply that certification; only the OCI can apply it.
The general population of developers who use containers to deploy their applications and services will not likely feel the impact of the 1.0 spec in the near term. The existing OCI specs were drawn largely from work already out in the field—e.g., Docker’s V2 Image Format for containers and its containerd runtime (which implements the image format). When OCI-certified images and runtimes show up, they will likely be identical to those already in common use, or only marginally different.
Standard effect
The effects of OCI standards, and the certification process, are likely to be felt most by vendors producing commercial-grade container products. In theory, those products don’t need the OCI stamp as long as they look, walk, and quack like other certified container products, but it will become harder to justify being the odd man out.
Docker and the OCI alike want to defray worries that Docker alone will continue to call the shots for how container standards are developed. Governance for both the image format and containerd left Docker’s hands last year, with the former going to the OCI and the latter under the stewardship of the Cloud Native Computing Foundation (CNCF), where it sits alongside CoreOS’s own rkt runtime. It’ll be worth seeing how the governance of those projects continues, and where the lion’s share of the work done with them comes from, once the OCI process certification gets underway.
IDG News Service
Ltd
