5 ms·

Celebrating the Open Container Initiative Image Specification

71 points by polvi 10y ago

codehusker 10y 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 10y 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 10y 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.
    - jclulow 10y ago
      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!
    - teacup50 10y ago
      Dropping POSIX in favor of a syscall ABI implicitly defined by Linux's implementation is a pretty substantial backwards step.
  - gshulegaard 10y 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-the-microsoft-angle/ 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".
  - SEJeff 10y 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.
  - fapjacks 10y 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.
bkeroack 10y ago
I thought that's what AppC was supposed to be? Does that mean AppC is moribund?
- philips 10y 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 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 10y 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".
    - pekk 10y ago
      That depends on what happens with OCI.
timthelion 10y 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 10y 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 10y 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.
shockzzz 10y 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 10y 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.
shockzzz 10y ago
If only Blue Origin & SpaceX can behave this way too...

71 points by polvi 10y 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 10y 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 10y 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.
  - jclulow 10y ago
    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!
  - teacup50 10y ago
    Dropping POSIX in favor of a syscall ABI implicitly defined by Linux's implementation is a pretty substantial backwards step.
- gshulegaard 10y 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-the-microsoft-angle/ 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".
- SEJeff 10y 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.
- fapjacks 10y 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.

bkeroack 10y ago

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

philips 10y 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 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 10y 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".
  - pekk 10y ago
    That depends on what happens with OCI.

timthelion 10y 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 10y 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 10y 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.

shockzzz 10y 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 10y 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.

shockzzz 10y ago

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