It seems like it took forever, but now there are standards in place for containers. They're far from being complete, but the first two components are now good-to-go. On Wednesday, version 1.0 of the Open Container Initiative's Runtime Specification and Image Format Specification were released, both based on Docker's image format technology.
The OCI is an official non-profit project of the Linux Foundation which got its start in 2015 as the Open Container Project, spurred by Docker and CoreOS which enlisted 21 industry leaders to form the organization. It's purpose: to develop minimal common standards for software containers.
The current membership roster reads like a who's who of corporate container users and includes Amazon Web Services, Microsoft, Google and IBM, all heavy hitters in the public cloud arena where container technology rules the day.
The two specifications released this week cover exactly what they say. The Runtime Specification sets standards of container configuration, execution and disposal on Linux, Windows and Solaris. The Image Format standardizes the internal layout of a container image and describes its components. Although these had already been fairly standardized on their own, there are minor -- and sometimes problematic -- differences.
Ironing out these differences was one of the reasons why these standards were two years in the making. One example would be the Docker issue. It might seem obvious for OCI to use Docker's work as the basis of these specifications. Not only had Docker, in many ways, been setting these standards on its own as the industry's most visible container company, it had donated its image format standard technology to the organization, which included its container format, runtime code and specifications, which were exactly what was addressed in this first release by OCI. However, according to LinuxInsider there was push back, mainly from CoreOS, a commercial Linux distribution for running containers, which was initially critical of OCI's direction.
Chris Aniszczyk, OCI's executive director, seems to see such openly expressed concerns as part of the process.
"Building standards is a somewhat different collaboration from building an open source project," he said. "Like any technical open-source project with companies making money in unique ways, there's always going to be different opinions."
Any misgivings from CoreOS seemed to have been laid by the wayside. On Wednesday the company seemed to be OCI's biggest booster.
"With the OCI Runtime Spec, and more importantly, the OCI Image Format Spec, at 1.0 and now mature for broad use, users can expect the OCI to help stabilize a growing market of interoperable, pluggable tools, and should gain confidence that containers are here to stay," Brandon Philips, CoreOS's CTO and chairman of OCI's technical oversight board, said in a statement. "And we are actively working with the Kubernetes community to bring this v1.0 OCI release to a future release."
Although Wednesday's release is considered to be something of a milestone -- and it is -- it's not expected to have much of a day-to-day effect on developers' lives, as the specifications were drawn from what were already best practices. The biggest impact will be on commercial developers of container-related applications -- especially if planned OCI certification for container apps becomes a big thing, which will probably be the case.
Implementation of a certification program to give a seal of approval to apps that properly implement OCI's specifications are just a part of the work that's on the organizations to do list.
"While v1.0 represents a great deal of progress, marking a readiness for serious commercial adoption, there is still work to be done," the organization said in a press release on Wednesday. "The OCI community will be launching a formal certification program later this year while active and ongoing work is underway in terms of additional platform support and potential to add additional specification functionality or projects."
One area the OCI is currently discussing is the use of hashes as a way to ensure a unique container name to do away with various naming systems. There are others. Stay tuned...