OCI’s Long-Awaited Container Runtime and Image Specifications Hit the Streets

After two years of work, the Open Container Initiative has published version 1.0 specifications for both a container image and a container runtime format. Fostered by the Linux Foundation, the OCI sought to ensure compatibility between container systems around the industry, including everyone from major cloud providers to Docker itself.

Much of the work done by the OCI was based originally on the work of Docker, said Chris Aniszczyk, OCI executive director. The project seeded with a code donation from Docker’s Libcontainer component, which became runC, the minimal runtime specification for OCI. The OCI image format was seeded from Docker’s V2 image format.

Vincent Batts, principal software engineer at OCI and Red Hat, helped to push the specification over the finish line during these last six months. He said that a lot of the final work was around getting the wording right so that all involved parties, including those representing Microsoft’s Windows ecosystem and even some of the Solaris people at Oracle, were happy and compatible.

An image format standard had to arise eventually, Batts said. “It’s one of these things where I think nobody really wanted to have a specification or standard, per se. I think a lot of folks involved in the ecosystem were wishing that a de facto standard would arise, but the issue with that standard arising is that there was a lot of inflexibility. The use cases that were needed didn’t have an audience to hear out how they needed all the flexibility and features that would need to go into that de facto standard,” said Batts.

The image specification is particularly important for portability, agreed Stephen Walli, who is the director of open source programs at Docker. “Folks have been thinking about virtual machine images for a long time now. I think what you’re seeing is, when Solomon [Hykes, chief technology officer of Docker] said ‘Here’s this easy way to build containers very rapidly,’ that set of open source projects became the de facto standards,” said Walli.

“In a lot of ways,” said Batts, “the Docker image format has certain de facto standards to it, but the fact is it’s tailored so it would only exist in the Docker ecosystem. If you made your own root file system builder — and there are plenty of tools to produce a root file system — if they were going to tailor that to a Docker image, there was this translation gap where if you weren’t using the Docker tool to produce it, you were constantly having to jump hurdles to get your image to be a Docker container image.”

Linux, Windows, Solaris

Thus, the OCI 1.0 specification should allow multiple tools to produce compatible containers. This should extend to the cloud as well, where vendors can either use an existing compatible runtime, or as with Oracle’s new Railcart, write its own implementations of the runtime specification.

“For tooling that doesn’t even exist yet, we need things to be more specified,” said Batts. “In a lot of ways it is boring enough somebody might not go out and Google what OCI tooling they need. They are just going to discover whatever container tooling they’re looking for in their use case, and ideally, it will support OCI images. They’ll have a compatibility layer and reuse more infrastructure, and not just if we’re not building images using tool ‘X’ we have to rip everything out and use something else. For a lot of risk averse companies, that might be a non-starter completely,” said Batts.

The OCI 1.0 specification is the culmination of the collaboration between over 40 companies, including Microsoft and Oracle. This also means that the specification covers Windows and Solaris, both. David Messina, senior vice president of marketing and community at Docker, said that Microsoft and Oracle, “were very collaborative and essential to the success of the solution because the focus was always on more than just Linux containers. The focus was on Windows, Linux, and Solaris, and that’s ultimately what’s shipping in the 1.0 specification. There are a lot of vendors involved, but there are a core set of contributors, and we’re sitting here with a 1.0 spec because of some really great cross-company collaborations.”

As for the end users, most of those involved in the project hope end users don’t notice many differences in their day to day workflows.

“What should people expect?” asked Batts. “Ideally, I feel like by and large people might not be impacted day-to-day.” He added that he expects OCI images will be an output vector for most registries and their toolchains. “This is just what Amazon’s EC2 Container Registry has already done. You could Docker push an image to their registry and turn around and request the MIME type of an OCI image back from it. It will do the translation on its side, then push or pull.”

“The whole point is that you can have a variety of tools for a variety of use cases, and still have some common artifact or layer where they can communicate. It’s similar to how people got used to using Qemu images for virtual machines over the years,” said Batts.

As for the future of the specification, Brandon Philips, Chief Technology Officer of CoreOS, said that there are already ideas floating around for what can be tackled in the next revision. “There are some ideas around improving the way stuff is packaged and shipped around. How can we more effectively ship around diffs and compress things? That relies on having really good specifications around how distribution works.

Docker’s Walli said that “The next big piece of work in front of the working groups is certification. The specifications have finally landed this week, now we get to prove it. Next, we will have certification in place to use OCI brands to validate products.”

CoreOS, The Linux Foundation and Red Hat are sponsors of The New Stack.

Feature image: A Terracotta model of a ship, 6th century B.C., The Metropolitan Museum of Art, New York, The Cesnola Collection.