Celebrating the Open Container Initiative Image Specification

Celebrating the Open Container Initiative Image Specification(coreos.com)

71 points by polvi 10 years ago | 18 comments

codehusker 10 years ago |

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 10 years ago | |

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 10 years ago | | |

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.

gshulegaard 10 years ago | | |

While not true yet, Docker is working on this by replacing the underlying LXC with their own secret sauce (at least last I checked). I suspect this is a result of their partnership with Microsoft (http://www.zdnet.com/article/dockers-unikernel-acquisition-t...). They were also moving towards creating proprietary and unique management tools before CoreOS started putting pressure on them.

Also notable is Docker isn't just containers, but they also have strong design opinions and container "philosophy".

fapjacks 10 years ago | | |

Docker runs natively on FreeBSD as of release 11 (which does require the new Linux 64-bit compatibility facility). It uses jails to achieve the same effect and in fact uses the very same images available on the default Docker hub. Also Docker has released beta engines for both Mac and Windows. So no, it's not a Linux monoculture even when considering only Docker.

SEJeff 10 years ago | | |

It would work fine on OS X if that operating system actually had equivalent control group or namespace functionality. OS X / Darwin lack these features, hence the boot2docker VM.

timthelion 10 years ago |

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 10 years ago | |

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 10 years ago | | |

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 10 years ago |

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

philips 10 years ago | |

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

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

(CTO of CoreOS, OCI Technical Oversight Board member)

tyingq 10 years ago | | |

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".

shockzzz 10 years ago |

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

shockzzz 10 years ago |

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

dastbe 10 years ago | |

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.

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.