Hacker News Reader

Comment by chubot | Hacker News Reader

Does anyone have experience with non-Docker OCI implementations to share? What's an example of something that uses OCI but not Docker? The blog post is a little vague.

I applaud this effort because Docker is sloppy, but I also realize that this isn't usually how technological adoption occurs. Usually the sloppy implementation is standardized, e.g. JavaScript, POSIX, CSV, Markdown, Ruby and Python to some extent -- rather than something designed from scratch or designed with fewer implementation artifacts.

Maybe C++ is an exception, where things are actually standardized and there are multiple, healthy, competing implementations.

View on HN

See the implementation lists for both specs:

https://github.com/opencontainers/image-spec/blob/master/imp...

https://github.com/opencontainers/runtime-spec/blob/master/i...

Now that things are 1.0 we expect many people to start implementing the spec. For example, the transition steps required to add OCI v1.0 support on-top of Docker v2.2 support for an application primarily involves changing a few strings. See the implementation notes here.

https://github.com/opencontainers/image-spec/blob/6060c3b6c6...

Docker uses a separate project called containerd to implement OCI: https://github.com/containerd/containerd

Containerd itself is not at all Docker-specific, you can use it independently for anything that requires transferring and running OCI containers. Because it's bundled with Docker, it's by far the most widely installed OCI implementation, easily in the tens of millions of nodes.

I agree that more implementations are necessary. My team released an oci-runtime implementation in rust a few weeks ago: https://github.com/oracle/railcar

We also released an oci-image builder that uses a different model from docker build: https://github.com/oracle/smith

> Maybe C++ is an exception, where things are actually standardized and there are multiple, healthy, competing implementations.

I see you missed the 1990 and early 2000's part of C++ history.

Why don't gcc and MS C++ count? I think gcc was a little behind yes, but it caught up. Also I think there were several other independent C++ vendors in the 90's, whose names I don't recall.

Just out of my mind, as an early C++ adopter (1993).

Turbo C++, Borland C++, Watcom C++, Green Hills C++, Microsoft C++ 7.0, djgpp for MS-DOS.

Turbo C++, Borland C++, Watcom C++, Green Hills C++, Microsoft C++ 7.0, C++ Builder, Symantec C++, Metrowerks C++, C++ Builder, Visual C++ for Windows 3.x onwards.

MPW C++, Metrowerks C++, Visual C++ for Mac OS.

Borland C++, CSet++, Visual Age for C++ for OS/2.

aC++ for HP-UX, xlC++ for Aix, Sun Forte C++ for Solaris.

gcc for most UNIX systems.

These are just the ones I remember without having to do a search.

Writing portable C++ code in those days was quite an adventure, specially since we only had the CFront followed by C++ ARM as standards, while ANSI/ISO were working on the first actual standard.

Sure, but you're not really disagreeing with me. I was saying that C++ wasn't dominated by a particular implementation, i.e. it wasn't a "fake standard".

It was and is a standard that MANY independent implementations tried to conform to!

> Usually the sloppy implementation is standardized

That's what this is. OCI v1.0 is pretty much "what Docker does".

While this is somewhat true for the image-spec (with some very notable exceptions where the semantics have deviated heavily), it's absolutely untrue for the runtime-spec. As one of the people who maintains the legacy of what Docker did before the OCI (libcontainer which is now part of runc), the interfaces and semantics are very significantly different.

Docker does use the OCI runtime-spec internally now (with plans to support the image-spec at some point), but that happened after the spec had become fairly stable.

The most important thing is not where the spec design came from, but that it's now being maintained by a community that will make sure you don't end up with fragmentation and lock-in.

How much does the OCI image spec differ from the one developed by CoreOS for appc? When OCI was announced, image spec was outside of its scope (https://coreos.com/blog/making-sense-of-standards.html), so coreos's work in this space seemed highly important. So has all work essentially been abandoned? Or did it inform the image spec of OCI (and 'what docker does') at all?

Not really though. Equating docker with OCI is kind of like saying gmail is the same thing as SMTP. Gmail works with SMTP to send messages, and docker works within the confines of OCI to create images.

While Docker is mostly OCI compatible these days (I say mostly as they extend their tools beyond it, making it hard to replicate the build without using docker itself. Not in-and-of itself a bad thing, but still annoying for portability), it shouldn't be confused with the OCI itself, which is there to help safeguard against companies like Docker going off and doing incompatible things.

runC is the tool that fits the OCI spec. It spawns containers on your host OS. runV is another tool that fits the OCI spec - it spawns container on hypervisors (type 2 AND 1).

runC is the most commonly used - it is used by containerd (which is docker's wrapper), garden (which is cloudfoundry's wrapper), and CRI-O (which is kubernete's wrapper).

rkt is another container company, whose wrapper is (afaik) just called rkt, and whose runC equivalent is systemd-nspawn, which does not meet OCI spec last time I checked.

FYI, rkt was created (and I believe still predominantly maintained) by CoreOS: https://coreos.com/rkt

It was created by CoreOS, but was recently donated to the Cloud Native Computing Foundation[1] (the same foundation that houses Kubernetes). However, I still believe the main contributors are CoreOS at the moment.

[1]: https://www.cncf.io/projects/

rkt's roadmap is to move from its own aci spec to oci as soon as the latter is "ready"

maybe i have the wording of this wrong, rkt people please advise

rkt implements and can pull OCI containers today. appc is deprecated.

goddamnit.

ive spent the last week learning about containers via rkt, having deliberately avoided the docker hype for the last few years.

ive mostly ported my setup to rkt, using acis because thats what all the rkt docs talk about. ive invested time into the 3rd party dgr build tool, which works really well and is based on acis, and cant be easily ported to oci. ive set up CI, deployment etc. now it turns out ive misunderstood the situation and im going to have to throw it all away at some point soon.

this is basically why i didnt bother picking up docker before. or is it moby now? yeah.

should have just stuck with openvz, vagrant and shell scripts, theyve worked fine for the best part of a decade.

I am sorry if the docs were unclear. I filed an issue if you could comment on where you got off track building ACIs we will try to have someone in the community fix it up: https://github.com/rkt/rkt/issues/3745

Just to clarify here: rkt has a roadmap to get full OCI support, and needs core developers (help wanted) to do the work. If anyone is interested please jump in on some of the issues: https://github.com/rkt/rkt/issues?q=is%3Aissue+is%3Aopen+oci...

thanks. i made a comment.

i was worried i was going to go back and look at the docs and see numerous glaring advisories that I'd ignored, having opted instead to read blatantly out of date pages, but no, apart from a few vague parenthetical warnings the docs all talk about building and working with ACIs and the appc spec.

I wouldn't expect a different container tech to have the same bumps, but of course it's gonna have them too.

Reply on news.ycombinator.com