Open Container Initiative Nears Container-Spec Goal

Why Cloud Security Beats Your Data Center

The Open Container Initiative (OCI) is building out its multi-vendor consensus on how containers will be implemented, while at the same time gathering new members into its alliance.

OCI, launched as the Open Container Project on June 22, was renamed a month later, possibly to avoid an acronym clash with the Open Compute Project or other existing commercial names. It started out with 21 signers; it's since added Oracle and Twitter to its ranks. Both are potentially large container users, and Oracle needed to sign on to keep its Oracle Linux up to date. In addition, the OCI has added AT&T, ClusterHQ, Datera, Kismatic, Kyup, Midokura, Nutanix, Polyverse, Resin.io, Sysdig, SUSE, and Verizon.

They are joining Google, Goldman Sachs, Docker, CoreOS, Amazon, HP, IBM, Red Hat, HP, EMC, Joyent, Intel, Cisco, Pivotal, VMware, Mikodura, Apcera, Nutanix, Mesosphere, Microsoft, and Rancher.

The OCI is producing a shared method of formatting a container, known as the App Container or AppC specification, originally contributed by CoreOS. "We should have a first draft by the end of July," according to a post on Github's open container website.

[Want to learn more about the launch of the Open Container Initiative? See Docker, CoreOS Bury The Hatchet For Container Spec.]

OCI is also working to finalize its proposed container runtime, the defined runC environment, which sets the conditions in which a container may run. Docker contributed its own runtime, runC, as the shared standard. OCI has accepted and is working with it, but it's unclear whether it will meet its July 31 deadline. The members of the OCI have rallied around Docker's container plumbing as the best type to run future containers.

Docker has made use of core Linux components, such as control groups, namespaces, capabilities, seccomp, and apparmor, and fashioned the elements needed to make containers run in a predictable fashion.

"Because 'containers' are actually an array of complicated, sometimes arcane system features, we have integrated them into a unified low-level component which we simply call runC. Docker makes heavy use of these features and has become famous for it," wrote Docker engineers in a June blog post when the Open Container Initiative was announced.

For a Docker container to be able to do the things that its user wishes it to do (that is, intersect with a given host and connect the application that it contains to the host server) it needs to be able to rely on a sandboxing environment that allows some of the details of how the application runs to match up with the way the host runs. The main requirement to getting the two together is relatively simple: The host server needs to run the same Linux kernel as required by the application code in the container. Since the Linux kernel is a highly defined and labeled set of code, matching up the two is usually a given.

With the initiative's specified runC runtime, a Docker container and a CoreOS Rocket container will be able to run in the same environment in the same way, without glitches, if both continue to adhere to the OCI runtime standard.

"RunC is a lightweight, portable container runtime. It includes all of the plumbing code used by Docker to interact with system features related to containers," the Docker engineers claimed in their blog.

The blog post cited how the runtime is designed for security, usable at scale in a production setting because it's been thoroughly tested by Docker, and available independent of the rest of the Docker platform for other container systems.

Roughly half of Docker's engineering effort has been in things like the runC runtime environment. The other half has been in the more visible tools and utilities that developers see as they invoke the Docker engine, format a container, and prepare to move it around a networked environment.

The OCI is off to a fast start as a multi-vendor, joint technical organization that will share the basic elements of container technology. These same vendors remember that the last time they quarreled over a new technology, VMware ran off with the leading virtual machine intellectual property and the enterprise product initiative.

This time they seem determined to keep lightweight container technology in play among a broad group of vendors and, early on, resolve the obvious barriers that might spring up to its adoption. If it's swiftly and broadly adopted, many users will benefit from the rapid advances, with Docker, CoreOS, and many others finding ways to benefit as well.