eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Two years ago, the emerging world of application containers was at a crossroads with rival efforts threatening to potentially bifurcate the technology paradigm. To solve that challenge, the Open Container Initiative was formed, and today after two years of effort the OCI is officially releasing the 1.0 milestone of the OCI container runtime and image specification standards.
In 2014, Docker’s container engine dominated the landscape, but in December 2014 rival CoreOS challenged its dominance with the rkt engine after voicing public dissatisfaction with Docker’s runtime. The OCI, which is run under the Linux Foundation Collaborative Projects effort, came into being in June 2015 under the name Open Container Project in June 2015; a month later, it was renamed OCI.
The two-year period before the release of the OCI 1.0 specification is actually double what the initial expectation for the project had outlined.
“The original charter targeted an initial release out in under one year,” Brandon Philips, CTO of CoreOS, told eWEEK. “But these things take time to get right, and in the extra time a number of implementations have come along to confirm the work that has gone into the OCI v1.0 specifications.”
Docker Senior Vice President of Marketing and Community David Messina told eWEEK that in his view, the two-year development of the OCI specification was the right amount of time to get the job done properly.
In addition to issues with the container runtime, CoreOS also had concerns about the container image format, which led to the launch of its appc effort. The new OCI image specification format 1.0 milestone incorporates some of the original ideas from CoreOS’ appc approach.
“The OCI image format has essentially taken some of the best ideas from appc and the Docker v2.2 image formats,” Philips said. “Today, the OCI spec is missing a number of things that appc specified, but those are things the OCI community intends to discuss post v1.0, including formats for image signing and the transport of images over an HTTP or other API.”
The OCI runtime specification is intended to be a foundational element of application containers that will help to enable a degree of standardization and interoperability across different runtime implementations. The project’s GitHub abstracts state that the OCI Runtime Specification aims to specify the configuration, execution environment and lifecycle of a container. While the OCI runtime specifications are important, they likely are not something that end users will ever directly deal with.
“The runtime specification is fairly low level and mostly the concern of people building systems like Kubernetes, not the end users,” Philips said. “I see the end user of the OCI specs being primarily the application developers who are building container images and putting their applications inside.”
Although end user mays not read the OCI specs from end to end, they can rely on the guarantees about filesystem layout, interoperability and execution environment that the two specs, when brought together, provide, Philips added.
Vincent Batts, principal software engineer at Red Hat, agrees that while the runtime and image specs are low level, they provide an important level of interoperability. He also noted that the lack of a container standard has been a barrier inside the Linux container ecosystem, primarily in limiting integration and overall technology choice.
“Prior to OCI, the only standards have been mostly de facto; when breaking changes happen, things would simply break, as there was no other option other than just letting them break,” Batts told eWEEK. “When there are heterogeneous deployments of tools, there is a need for the ‘glue’ between them to have more assurance on the format of the container images.”
Certification
While the OCI runtime and image specifications are now at the 1.0 milestone, Docker’s Messina said there is not yet any formal certification process to validate that any implementation is in fact fully compliant with the specifications.
“Once the certification and testing suites are all set up, we’ll talk about Docker OCI compatibility,” Messina said. “The certification program doesn’t exist today, and we don’t want to mislead anyone.”
Efforts are underway to enable certification for both the runtime tools and image tools within an OCI Certification Working Group, according to Batts. With the specifications now at the 1.0 milestone, the “dust has settled” and it’s now possible to complete the automated tooling that will help to enable certification, he added.
“Much attention and focus will be placed on automating and enabling folks to claim OCI compatibility and even OCI certified status,” Batts said. “It is not true that just anyone can claim such without it being refuted, but the automation behind that refutation is upcoming.”
While Docker and CoreOS have both built container engines that will have OCI-compliant runtimes, Red Hat also has an effort it is helping to lead.
“Red Hat is working on cri-o, which is an OCI-based runtime that can support any OCI-compliant runtime as a back end,” Mrunal Patel, principal software engineer at Red Hat, told eWEEK. “Cri-o implements the Kubernetes CRI [Container Runtime Interface] API and aims to be a lightweight runtime for Kubernetes.”
Looking forward, there is still work to be done in the OCI to further advance the container market.
“There are over 40 vendors participating in OCI, so now it’s important to get the test suite done and get people through the certification process so we can talk about compatibility,” Messina said. “Now that the 1.0 specifications are in place, you’ll see the industry build on those foundations.”
CoreOS’ Philips is also optimistic about the impact of the OCI 1.0 milestone and how it will help to further enable the growth and development of the application container market.
“My hope for the evolution of the OCI is that it gets widely implemented and includes all of the critical parts that are necessary for full interoperability from build, distribution and execution of a container,” Philips said. “On the top of my mind this includes signature specifications and distribution.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.