 All right, can I get started? I only got about 10 minutes, so I'm going to be moving pretty quickly. So today, I want to give you a quick overview of what the OCI answer is as to what is a container. So quick agendas, four main questions we're going to cover. Why, firstly, why does OCI exist? Who's working on OCI? What are the standards itself? So what is the container? And finally, how you can play with it and hopefully get into a bit of demos to show you what's inside the containers. So OCI, if anyone hasn't heard of it, it's an initiative formed under the Auspices of the Linux Foundation in mid-2015, I believe. And basically, it's a sort of governance structure for creating standards for containers. It exists so that we can define what a container is so that everyone can implement it, rather than being beholden to a particular implementation so that different people can package, annotate containers, and then run them with other people's tools. And ultimately, when we created this initiative, we wanted to sort of unify some of the best ideas from Docker, which was obviously the most popular, well-known container tool at the time, and other systems like LXC and App-C that were out there. Particularly, we want to emphasize some things that we hadn't been seeing, like content addressability and composability. And then also, we wanted to, again, there was sort of a bit of conflict in the industry around these container tools that were ultimately very similar, very similar goals. So we wanted to sort of end that conflict and try to come to a common solution. So OCI has pretty good cross-industry support. You can see here a lot of the big players in the industry, particularly in container technology, represented and actively participating, some more actively than others. But for example, I'd call out that Microsoft is involved in this container technology, which was historically very Linux-focused. There's also some folks from Solaris involved. So the OCI projects are really working across all platforms. OK, so what the standards are, there's two key projects within the OCI. The first one, what we think of is what we call the image spec. And that's basically defining what's in a container. There's two main GitHub projects there, the image specification itself, and then some associated tooling for working with these things. And then the other side of things, the runtime spec, is what it means to run a container. And again, there's the specification, and then there's RunC, the reference implementation you might have heard of, which is used sort of internally by things like Docker today. Focusing on the image spec for a second. So ultimately, that's sort of the portable archive format of the thing you want to package and distribute around when we're talking about sharing containers. It's pretty boring. It's just sort of a structured table and JSON metadata describing that. Again, one of the key things in developing this spec was this emphasis on content addressability, because that had been missing from earlier container things. So within the image spec, there's a few different sort of components, which I'll jump into in a second. And what's really core to the spec is that all of these components are addressed by a hash of their contents, of their byte stream, basically. And then these are linked together by these content addresses. So what the spec actually defines is just a set kind of of media types, most of which are sort of JSON blobs. As you can see here, these are sort of the most key media types. The starting point is what we call an index. And that provides us the ability to have one image that can run across multiple platforms. So this is sort of a general entry point to the image that can reference platform-specific bits and pieces. The second thing here, image manifest, which I'll show you an example of a section, is kind of what we think of as the image. So that references the next two things. So it references some configuration for how you run the image. And then it contains actually all of the bits that constitute the root file system of your application. This is sort of the hierarchy of the sort of types, just sort of what the hierarchy looks like. As I said, the image index is sort of where we, the starting point of potentially referencing multiple architectures, multiple platforms. The image manifest is kind of what you think of as the image when you're referring to an image. So when you say I want to run busybox or something, that's ultimately referring to an image manifest. And then that manifest itself will refer to two kind of key axes. One is sort of the config. So again, like the runtime information, stuff like that. And the other side of things, just your actual root file system, all the files that you need to run the application. The key thing to note about the image spec is that it was designed to be backwards compatible with Docker. And the key point here was that we wanted to be able to use all of these root file systems that are already out there, these Docker images there, and be able to, anyone who already has a registry, for example, to be able to use those seamlessly within OCI implementations. But quarter of this idea, again, was that this image format wasn't well specified before, the thing that Docker was using internally. So really, this is just about taking that de facto standard and writing it down and clarifying it so other people can build against it in a predictable way. On the other side, the other specification project I talked about was the runtime side of things, where runC is sort of the default implementation there. That defines what a container looks like on disk after you've pulled it down from the internet, verified the signature, extracted it. And then what it means to start the container, to stop it, what it means to constrain it with different sort of C groups or process isolation, things like that. And then it also defines a way to expose state for containers that are running on disk. And I'll show you that in a second in the demo. OK, so I'm going to jump across into demo and show you some sort of common, some tools that have emerged to work with containers and how we can tie these different pieces that I've just talked about together. How are we doing for... Can everyone read that? Read that, OK? OK, so the first thing I'm going to do here is just use a tool called Scopio, which is for working with image registries. And I'm going to use it to pull down an image from the Docker registry and write it to disk in the OCI format. This sort of brings me to one of the points to note about the OCI format at the moment is that unfortunately it doesn't specify distribution. There's various lengthy political reasons for that. What this means is that in practice today, we're still using sort of a Docker registry to store images and then we have tools that are capable of pulling Docker images and converting them on the fly to an OCI image. So now what we have in this directory is this... Let me just do that again. Is this pretty straightforward layout? You can see things I call out this index file, which is that index file that I talked about, the top one here, which is sort of the general entry point to the image, and then that in itself will reference a specific image manifest. So if we look at this index file, we can see a bit of metadata here. What I would call out is that in this case, as I said, it can be a set of manifests. In this case, it's just one. So we just have a single platform here, AMD64 Linux. And then this is, again, the cryptographic hash of that actual underlying image manifest because that's the way that we reference everything within OCI. If we look at this hash and then we go up and look in what's come along with the image, we actually see that that file is in the directory here. So then we can go ahead and look at that one and we see sort of the next layer of interaction. This is the platform-specific manifest that was pointed to here. And this contains the image configuration and the table. So once again, this is just cryptographically addressed. So if we wanted to see the image configuration, we can do exactly the same thing once again in that directory. Where are we? Sorry. Blobs. And now we're down to the new greedy of like how we actually execute this container and what was in this case is a very simple example since it's just busybox. But we can see some information around the environment to set up when we actually wanna run this container, the command to run and the history of how the container was created and stuff like that. Again, this is quite a simple example, the busybox one. And then if we have a look again at our directory, so we've already looked at two of these blobs, one of which was the initial image index here, the second one which was the image manifest, and then finally the last one was the layer, the table that contains the actual root file system. So now we have this image on disk and this is kind of the canonical OCI representation of it. We can use a tool called Umochi or Umochi to unpack this image into a runnable version. So the runtime spec that I mentioned earlier. So we just give it a reference to that local directory and then we'll tell it to put it in, I don't know, busybox unpacked. Now what that's gonna do is it's going to look in this index JSON for this reference that we just specified, so this latest reference. So you'll see if we go back up here, whoops, the index JSON, you'll see that there's this annotation here saying this is the latest. So if you're used to the sort of the docker world of having like a name and a tag, this is analogous to that, but the OCI version. So basically what Umochi will do is it'll look in this index, it'll say okay, I'm looking for the thing with the reference latest, it'll see what that corresponds to, and then it will follow that to figure out what the image is that it should unpack. Then what is Umochi done? It's go ahead and applied all those file system layers and the associated config to create this expanded version of the container on disk, which conforms to the OCI runtime spec and then that gives us a container that's ready to run. So just to give you a quick idea of what the runtime spec looks like, whoops. This is a lot more low-level information, things like capabilities, UUIDs, environment, all that sort of stuff, ready to run. So now we're ready to run, we can jump in here and use RunC, I think, whoops, if I can remember the syntax, there we go. So I've just told RunC to run, but give it a container name of foo, and then it's read this configuration that I've just printed out and that has all the parameters in there that it needs to go ahead and start running container. Now if we look in the run, so now we're inside this container, as you can see here, contained from file system. If we look into the RunC metadata directory, we can see the runtime state that, again, the OCI spec defines. So this means that any other tools that understand the runtime stake can then go ahead and inspect running containers that are conforming to the OCI spec. I think I'm right up on 10 minutes. That's all I have, but I'd be glad to chat about any more of this than I would like to afterwards. Thanks.