Cloud Native Computing Foundation Crossplane Community Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: OCI Images for More Than Containers, Jon Johnson, Google

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: OCI Images for More Than Containers, Jon Johnson, Google

OCI images have become synonymous with containers, yet the fact that they are used for running containerized processes is nothing more than an implementation detail. In reality, OCI images are capable of packaging arbitrary data, and because of the wide proliferation of registry offerings, they are an attractive distribution mechanism for hosting and sharing standardized artifacts. In this talk, Jon and Dan will peel back the layers of the OCI image specification, exploring what components are required and which are optional, as well as how to build your own images by hand. The Crossplane package manager’s usage of the go-containerregistry library will serve as a reference for how these concepts can be used in practice. Attendees will leave with a greater knowledge of how Crossplane works under the hood, and how OCI images may be used to solve their own artifact distribution problems.

A

Hello, uh this is the oci images for more than containers. Lightning talk, and I am john johnson a little about me. I have been working at google for the last five years on various container things, starting out on the gcr team and recently focusing on the generic artifact registry service since 2018, I've also served on the oci technical oversight board, which is where I formally argue about semantics on the internet, mostly around containers. I also maintain a couple projects on github and on the right.

A

You can see our dog graceann grace.dog for more pictures of her. If you're interested, uh we will eventually get to crossplane, but uh first we're going to go over some oci data structure background the registry and this go container registry library at the end, we'll talk about how cross-plane ties all this together to manage packages and just as a disclaimer. This was originally going to be a longer talk with both me and daniel mangum, but it has been squished down into a lightning talk. So I'm going to go really fast and I apologize also caveat.

A

I am not a cross plane expert, so I will hand wave over some of those details while focusing more on the oci stuff.

A

Moving on to the image specification, so I would assume most people watching this are somewhat familiar with merkle dags. But if not a dag here is a directed acyclic graph, which means there are no cycles.

A

A merkle dag is a graph constructed out of hashes, which means the entire thing is immutable and also enforces that acyclic bit.

A

This is a very nice property for a data structure, you're, probably familiar with things like git and bitcoin, which use merkle dags, but you may not be familiar with the fact that oci images also are built on top of merkle dax. So on the right we have this example graph. That represents an oci image.

A

The arrows between nodes represent hashes, and so, when I say digest, I'm talking about these arrows pointing to content as the hash of content.

A

So the the fundamental primitive of oci data structures is called a content descriptor. This is just a simple tuple of media type size and digest these properties together. Act as this strongly typed immutable pointer to arbitrary things right, this is this generic data structure, that's very useful, so the media type tells us the format of some bytes and how we should interpret that the size tells us exactly how many bytes we should expect, which is helpful mostly for safety reasons, and the digest. Is that immutable content identifier from earlier and so for this example.

A

If you were to find this descriptor on the ground somewhere in isolation, you would know that it is talking about an oci image manifest which is encoded as json. That has exactly 7682 bytes and has this shot 56 blah blah blah right.

A

Usually, though, we don't find these on the ground, they're, actually just embedded in other data structures, for example the image manifest.

A

So the image manifest is what most people will be familiar with as say like a docker image and is equivalent to the docker v2 schema 2 image format. Roughly simply put, it is two things there is this config descriptor and that points to a json blob with various information about how to run the image. For example, what environment variables should be set, the user that should run the process.

A

It also contains some other the metadata like the creation time and also how the image was built. Then there are also layers which are just a list of descriptors that describe the container images file system.

A

These are represented as a special change set, tarballs they're, usually gzipped, but they are flattened into the representation of the file system using some union fs mechanism. Usually the last interesting data structure is an image index also known as a manifest list. So this is just kind of like a meta manifest that references other manifests or really anything that you can describe with a content descriptor. So in my head, I think of this as like a folder right, but the most common use by far for these is to distribute multi-platform images.

A

So in this case, we have a manifest list that points to a powerpc image and an amd64 image and so clients when they encounter this. They can look at those platforms and select an appropriate image for the target. Runtime.

A

Now, briefly onto registries, so the registry protocol basically is just a protocol for uploading and downloading stuff via http, and it is pretty similar to like the dumb and get protocol.

A

um We don't have too much time to get too deep into it, but roughly there are two handlers, the manifest handler, which is for structured content like the data structures we just discussed and then there's the blobs handler, which is for opaque content.

A

That registries, don't try to understand things that are uploaded, as blobs are usually leaves in a merkle, dag and things uploaded as manifest, usually have outward pointers to those leaves, and so registries tend to parse things uploaded as manifests so that they can do ref, counting and garbage collection and enforcement variants, like you, don't want to upload something that points to a blob that doesn't exist.

A

Both manifest and blobs can be referenced by their digest, but manifest can also be referenced by mutable tag identifiers which we'll get to later. The reason we're talking about this is that registries are interesting to us.

A

If you're running say images on kubernetes, you need to pull them from somewhere, and so we have this service that stores artifacts already that we're already using from a cluster which we'll get to later, um I can demonstrate with a tool I have built what these look like in an actual registry, so um here I'm showing a manifest list on docker hub. um We can look at this first, one which is an amd64 linux image, and this pulls up just the image manifest which again points to a bunch of layers and some config.

A

The config has various things. For example, here's the environment variable set via the path.

A

And then the file system again is just a tarble right, so we can look at this just like any other file system.

A

uh Moving on to my magnum opus, which is the go container registry library, so the reason I was asked to give this talk is that I maintain this. Go library and crossplane uses it um and more than that, many other tools depend on this. So, for example, my own cli called crane is a generic registry client, which I have just shamelessly plugged more interesting for this uh kubecon.

A

Talk, though, is that there are various kubernetes controllers that use go container registry. So the first of those was the k native revision controller and that roughly just would resolve image tags to their immutable image, digest references.

A

You can read more on this kubernetes issue about why that's a useful thing to do.

A

The second adopter of go container registry was techton and it used the library for basically rewriting a pod's entry point to enable interesting uh features that kubernetes doesn't allow like ordering tasks. Christy wilson and jason hall gave a really great talk on this already. You can follow that youtube link, but more recently is uh techton's use of go container registry for something called tekton bundles, which are basically just oci images that contain a bunch of yaml describing tecton resources.

A

um That's very relevant to this talk because that's basically the exact same thing that crossplane does to manage packages so uh crossplane same thing, right, yaml and an sdi image across my packages, so finally tying this together- and this is where I will hand wave, because I don't really understand it, but basically packages come in a couple varieties: there are providers and configurations. I don't really know what those are, but I do know it's a bunch of pml, given that this is kubernetes.

A

um The cross plane controller has two reconcilers a revision, reconciler and a manager. So the revision reconciler is what actually talks to the registry. It pulls down these images, caches them extracts the animal and does all the actual work of like installing a package, all the business logic. The manager is quite literally a package manager.

A

It is responsible for pinging the registry to detect, updates to images and also garbage collection, old package images that are no longer needed again really hand waving over this, uh but I do have a couple examples that I think make this clearer a little bit. So here is the example: gcp provider right there's this very special animal at the top, and then there is also a folder of crds again or yaml. um If we look at what this looks like in the upbound registry, um you can see that there is this one layer.

A

It contains this one package.iamo file- and this is just all of the aml concatenated together. So the controller just pulls down that image extracts the ammo and processes it.

A

So to summarize, you can use oci images for more things than just containers like camel go. Container registry is very cool. It makes this easier and cross-plain packages are one example of that. There are three other projects here that do similar things that you should check out as well.

A