Huge props to the other maintainers of the various OCI projects, the contributors to the OCI, and the wider community (special shout-outs to the AppC folks). It's been a very long time coming, but finally we pulled through and have hit this milestone.
I'm very excited for all of the ideas we want to work on now that this milestone is out of the way, and we have a solid base to improve upon. But of course we should have a moment's rest to appreciate how far we've come.
I'm really digging the end result of the spec - it mostly defines a bunch of conventions on top of easy formats. Kind of wish the marketing around it would be less buzz wordy, because the end result is quite straight forward.
* (It's usually a tarball; nothing stopping you from sharing images over torrent for example.)
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.
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.
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
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!
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.
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.
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
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.
It is sad how much waste will occur because OCI used Docker's flat layer list instead of appc's dependency graph. This will lead to a tremendous amount of unnecessary network traffic and disk usage globally. I think this is a Betamax vs VHS moment on a much smaller scale.
There is no real advantage to a dependency graph versus a list of layers. Originally, Docker images were actually fetched in sequence, similar to the ACI approach, but this blocked parallelization on each subsequent step. What has become OCI uses a list of layers to avoid this bottleneck.
As long as images share layers, network traffic would be the same in either scenario.
Reduced transfers will be achieved by formats that have a more granular filesystem representation. Right now, we are really held back by the continued use of tar, but that is another problem.
Yes, I agree that the method that OCI v1.0 & Docker v2.2 has of telling you ahead of time "you must fetch all of these objects and they will be this size" in a compact single metadata only format is the best option. Then it is up to the fetching code to choose the best way to pipeline or parallelize.
I think that lack of parallelism has almost nothing to do with graphs vs lists. It would be pretty easy to either store the entire dependency graph's fetching-critical metadata in each image or to make it possible to fetch the metadata separately from the core data. Both of those would allow you to parallelize downloading of image data in the graph-based system.
Having more granular layers can help a bit but in practice it hits its limits very quickly because higher layers will necessarily get swept up and have to be rebuilt when layers below them that they don't actually depend on get rebuilt. This rules out having a core image and a set of modules that each downstream image may or may not need (to be mixed in or not per-image). Thus, when you use the layer-based system in practice you usually end up with very little layer sharing between images, outside of the core Linux distro layers.
Note that I did not say "more granular layers" but more "more granular filesystem representation". This is a key point in achieving better data sharing. In fact, these use cases are not ruled out, but bolstered by OCIs approach. The introduction of alternative systems will be much easier to do when OCI is broadly implemented.
As far as metadata is concerned, your suggestion is exactly what OCI does. The problem with ACI is that it embeds a large part of the metadata into a tar file, which has to be fetched in its entirety. OCI is mostly metadata scaffolding, made up of indexes, manifests and configs that can all be fetched without large bandwidth requirements.
The compositional aspect that you've brought up has been explored and it doesn't make a whole lot of sense to cram that into images. Typically, such a system requires composing container filesystems through named references, allowing components to be independently rebuilt. Because this composition often relies on details of the target deployment media (orchestration system, container runtime, specific operating system, etc.), especially in how it deals with the security of name resolution, baking it into an image format leads to massive inflexibility.
Moving it up the stack works much better and avoid the technical complexities that come with doing it within images. We can see this image composition in action in k8s PODs, docker stacks and other systems. Such constructions can be distributed through OCI images, through media types, but they are based on the compositional capabilities of the target system.
Not the OP so I'm just speculating, but being able to "mount" content-addressable blobs into different locations in the resulting rootfs would enable more incrementality and sharing of blobs.
With a flat list, the same logical set of files will have a different checksum depending on where in the final rootfs it needs to end up, right?
These blobs are already shared.
(In Docker) Since each layer is only the diff from the layer before it, the content address is only from the change set.
Technically you can share blobs even between an image that is `FROM centos` and one that is `FROM ubuntu` as long as the layer hashes are the same.
If you have a hierarchical dependency chain, and addressing content based on the content that comes before it in the chain, you can only share blobs between images if they have a common ancestry.
One image has a large file at a specific path, added via something like: "COPY largefile /etc/path1".
Another image wants to add this same file to a different location:
"COPY largefile /etc/path2/".
My understanding is that these two blobs will have a different hash and can't be shared because the changeset includes both the file itself, and the destination location in the image.
Been a hot minute since I've sat and thought about cloud. Curious how containers fit into the "serverless" (lol) movement? Also, does something like Invision straight to lambda poses an existential threat?
Honestly I think that containers are a transitionary technology. Lambda and its ilk are the future of application development. Those systems will likely run on top of container based infrastructure so you can have a variety of lambda environments but not something the application dev worries about directly. Managing the full operating system stack is just not something application developers should have to worry about.
It's funny how PHP had it right all along. Serverless/lambda -> stateless "functions" being passed arguments -> same as PHP (w/o sessions and junk).
To be honest, when I jumped from PHP dev to more app-based backends years ago, I thought it was fairly crude to have a stateful server handling everything. Now everyone's starting to move back to (hosted) versions of what amounts to "bring up and tear down the entire app on each request."
That's not what it is at all. Lambda functions persist, unless traffic drops, then it is killed. But if traffic is going to it, they try to be smart about reusing a hot app.
PHP is even moving toward "stateful" server handling. Just look at hhvm
php-fpm does the exact same thing. It scales up/down the number of workers (down to 0 if configured) with the incoming load, reusing workers up to a certain threshold.
Lambda == PHP. It's full circle. Don't try to pretend otherwise.
Never heard of HHVM (I've been out of the PHP world for a while), but I know PHP's default operational mode is complete start up and teardown on every request.
Yeah, I guess that's true for app devs. I suppose you're right in that they make a lot more sense for infrastructure developers (who I ironically always forget about oops).
The Cloud Native Computing Foundation (CNCF) has a serverless working group discussing the topic. Please peruse their docs and participate: https://github.com/cncf/wg-serverless
I think a better but os specific alternative would be to simply have an elf section in a binary per 'container' technology (mounts, unshare, seccomp, etc) that is simply a called at the earliest .ctor. State would be per binary and could potentially be per application as well in say /state/$prog/$app.
The upsides of this is simplicity, permanent 'containerization', better handling of state, automatic updates if all this is handled with a package manager and finally the potential to have more locked down containers via analyzing the dep chain.
I'm very excited for all of the ideas we want to work on now that this milestone is out of the way, and we have a solid base to improve upon. But of course we should have a moment's rest to appreciate how far we've come.
Also, here's the official press release from LF: https://www.opencontainers.org/blog/2017/07/19/oci-v1-0-brin...