Celebrating the Open Container Initiative Image Specification [feedly]

----
Celebrating the Open Container Initiative Image Specification
// CoreOS Blog

Today we are celebrating the start of the new Open Container Initiative project, the OCI Image Specification. This means there is an industry-backed project under the OCI with a strong technical community of industry maintainers to standardize how container images are built, verified, signed, and named.

Users can expect a shared industry standard for creating and shipping software containers from this project in the coming months. If you are using an appc or Docker image today, there is nothing to change. Nevertheless, this is a major industry step toward the promise of "package once, run anywhere" containers, and users can expect increased innovation and interoperability between container registries, build tools, and runtimes in 2016.

The OCI has expanded beyond its first project, the OCI Runtime Spec, which is about how to run containers. Today the OCI's focus has broadened to include a new OCI Image Format Spec, an open specification for a container image, the build artifact that contains everything needed to run a piece of software. As the Docker image format has evolved to include many features from the appc spec in the last 16 months, the OCI project is starting with the Docker v2.2 image format as its base. This should result in minimal effort to converge the two formats. And soon both Docker and rkt will support a shared, standard container image format, with an open specification housed at the OCI.

Bringing the industry together

Check out CoreOS CEO Alex Polvi's blog post for a refresh on the history of the OCI project. The OCI formed in the summer of 2015, and development had focused exclusively on the container execution environment. We are happy to see this essential OCI Image Format Spec project get underway this month. It will focus on the most critical and foundational component of container standards: the distributable container image. An open, and openly implementable, container image format specification underpins all the portability goals of containers, allowing users to build and package a container once, sign it, and run it in a variety of vendor implementations and platforms, in the cloud and on-premises.

Here's a summary of the ancestral components of the OCI Image Specification, their features and histories:

	Docker v1	appc	Docker v2.2	OCI Image
Introduced	2013	Dec 2014	Apr 2015	Apr 2016
Federated namespace	Yes	Yes	Yes	Yes
Content-addressable	No	Yes	Yes	Yes
Signable	No	Yes, optional	Yes, optional	Yes, optional
Delegatable DNS namespace	No	Yes	No	Yes

Who is involved?

The initial maintainers of the OCI Image Format Spec are the people behind the appc spec, the developers of the Docker image format, and other notable members of the application container community:

• Vincent Batts, Red Hat
• Jonathan Boulle, CoreOS
• Jason Bouzane, Google
• Brendan Burns, Google
• Stephen Day, Docker
• Brandon Philips, CoreOS
• John Starks, Microsoft

The OCI and the Image Spec project welcome community involvement, and over time we intend to add more maintainers based on active participation.

What are container images, again?

At a high level, a container image is the build artifact that contains everything needed to run a piece of software. Today, developers use tools like the Dockerfile, acbuild, dgr, or custom scripts to build container images. This results in a file, or set of files, that can be uploaded to the Internet. Anyone who wants to run this software then can specify some name, like example.com/my-app, to download, verify, and run that container.

What does this mean for the user?

The goal of the OCI Image Spec is to allow developers to package and sign application containers, then run them in a variety of container engines. This means teams can choose the build tools and execution scheme that best meets their needs. With a container image specification that anyone is free to influence and to implement, containers will run without modification in a variety of runtimes, from rkt and Docker, to Kubernetes and Amazon ECS. This is a huge win for users that will drive the continuing adoption of containers in modern infrastructure.

Given the wide industry participation in the Open Container Initiative, we expect to see support for the OCI Image format within container image registries like Quay, Amazon Container Registry, Google Container Registry, and Docker Hub in the coming months. Coupling this increased container portability with name delegation enables a set of powerful container registry mirroring and image distribution primitives for users. With support for the common OCI image format in container registries, it will be easier to move and replicate container images, without worrying about managing multiple build processes and formats.

rkt and Quay will support the new OCI image format

Today, the Quay container registry and rkt container runtime support both the Docker image format and the appc image format. We remain committed to backward compatibility so users who have invested time and tooling can continue to manage, store, and run container images in the formats they have today using Quay and rkt.

We will add support for the OCI Image Spec alongside existing formats as the OCI format matures. According to the current OCI Image Spec Roadmap, this should be possible over the coming months. We hope the OCI image format quickly becomes the single shared industry standard that all future build, storage, and runtime products employ.

As this effort combines the best parts of the appc image format and the Docker v2.2 image, we expect that specifying and implementing the new OCI image format will move quickly. We appreciate your help and support as we move with the joint effort to standardize the application container image, a fundamental building block of #GIFEE (Google Infrastructure for Everyone Else).

How to contribute

As a community we have made great strides in container standards that will make it easier for the industry to thrive with containers. If you are interested in supporting this effort you can contribute by involving yourself in upstream open source projects like rkt or Clair to help projects like these support the spec, telling your cloud providers you want to see them support the OCI Image Spec, or getting involved in the specification project itself. This is a joint effort and the best way to get there is to have the entire industry pushing it forward together.

Learn more at these events

We also invite you to join us at an upcoming event to learn more. On Friday, April 15 at 11 a.m. PT, Brandon Philips, CTO of CoreOS, will discuss more during his talk at Container Camp San Francisco. We also encourage you to join CoreOS and the community at CoreOS Fest in Berlin, May 9-10, or at the satellite event in San Francisco on May 9. Be sure to get your tickets ahead of time.

----

Shared via my feedly reader

Sent from my iPhone