
Celebrating the Open Container Initiative Image Specification - polvi
https://coreos.com/blog/oci-image-specification.html
======
codehusker
CoreOS has done a lot of work to avoid a monoculture of Docker containers, and
I think we all benefit from the interchangeability of different
implementations/runtimes.

The future of containers just keeps getting brighter and brighter.

~~~
teacup50
Isn't this just a Linux monoculture? It's not like you can run most containers
as-is on a platform like OS X without actually virtualizing Linux itself.

~~~
jahewson
Not necessarily. You need a platform which supports Linux syscalls, but you
don't need Linux per se. Unlike VMs, containers sit above the kernel so you're
tied to its interface but not its implementation. For example, see Solaris' LX
Branded Zones.

~~~
jclulow
At Joyent, our Triton cloud stack is built on illumos (nee Solaris) LX branded
zones. We also have a Docker-compatible remote API, so not only can you run
unmodified Linux binaries in containers, you can do so using the regular
Docker client CLI!

------
timthelion
Wait, they don't use hashes? Why???

    
    
        Image ID
            Each layer is given an ID upon its creation. It is     represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be  globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptographic hash of image contents as the result is considered indistinguishable from random. The choice is left up to implementors.

~~~
jsprogrammer
Maybe don't paste into a horizontal scrollbox so that you may see the whole
thing?

It says:

>an image ID may be derived as a cryptographic hash of image contents

~~~
philips
Using the crypto hash is something that we should probably fix up and enforce.
Could you file a bug?

We just started the project last week and imported the original Docker v2.2,
which this text is from, a few days ago. So, there is language that will
change and improve before the initial v0.1.0 release.

------
bkeroack
I thought that's what AppC was supposed to be? Does that mean AppC is
moribund?

~~~
philips
No, appc isn't moribund; the appc community continues to maintain the
spec[1][2]. Our hope is that the best parts of the appc will be added into the
OCI for a shared industry standard. And today I am optimistic the OCI will do
that.

The OCI membership includes important parties in the ecosystem from container
engine implementers to public providers with container registries: Google,
Microsoft, Amazon, Docker, CoreOS, Red Hat, and many others. This means that
we have good a organizational setup to get a single industry standard. It is
worth the additional effort to obtain that goal for the industry.

tl;dr appc is a source of inspiration for the OCI work and will continue to be
maintained and available in rkt, Quay, and others. We have a good shot at an
industry standard for container images. And we want to make that successful
even if it requires some initial duplicated effort.

[1] [https://github.com/opencontainers/image-
spec#faq](https://github.com/opencontainers/image-spec#faq)

[2] [https://coreos.com/blog/making-sense-of-
standards.html](https://coreos.com/blog/making-sense-of-standards.html)

(CTO of CoreOS, OCI Technical Oversight Board member)

~~~
tyingq
Your first link says this:

>>Q: What happens to AppC or Docker Image Formats?

>>A: Existing formats can continue to be a proving ground for technologies, as
needed...

Sounds pretty moribund to me. It exists only if it wants to be a proving
ground, "as needed".

~~~
pekk
That depends on what happens with OCI.

------
shockzzz
If only Blue Origin & SpaceX can behave this way too...

------
shockzzz
Weren't containers supposed to solve the whole "one interface for everything"
nonsense? Now we have a standard interface for the standard interface?

~~~
dastbe
This is a community standard for how image artifacts should look. Right now,
everyone is building systems against the Docker image specification which is
problematic because Docker can and should be able to modify and extend it
however they please. By agreeing on a common image spec, support for features
can be more consistently available as they appear while Docker and others can
extend and innovate for customers that want those specific features.

As an comparative example, we have common CSS specs which provide consistent
support for most features as they are included, but Chrome, Mozilla, and
WebKit are still able to experiment with new features.

