Celebrating the Open Container Initiative Image Specification
coreos.comCoreOS 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.
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.
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.
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!
Dropping POSIX in favor of a syscall ABI implicitly defined by Linux's implementation is a pretty substantial backwards step.
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".
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.
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.
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.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
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.
I thought that's what AppC was supposed to be? Does that mean AppC is moribund?
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)
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".
That depends on what happens with OCI.
If only Blue Origin & SpaceX can behave this way too...
Weren't containers supposed to solve the whole "one interface for everything" nonsense? Now we have a standard interface for the standard interface?
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.