 Hello, welcome to the ContainerD subproject lightning talk. Today, we're going to give a brief overview of ContainerD subprojects. We will quickly go over the different projects and what it takes to become a ContainerD subproject. We will also have a demo of ContainerD's latest subproject called NerdCTL or NerdCuttle if you prefer. First though, let's briefly go over what ContainerD is and what its architecture looks like. ContainerD is a container runtime designed to be simple, stable, and easily customized using plugins. Think of it more as a resource manager for everything related to containers. Whether that is container file systems or the container execution environment, ContainerD keeps track of it. Architecturally, ContainerD is divided into simple components and access via gRPC APIs. It communicates with lower level container run times, which do the actual container execution via a gRPC like protocol called TTRPC. Different components of ContainerD can also have plugins as well, such as custom snapshotters or content stores. ContainerD also has a fat client model, meaning clients can import the go library and use different interface implementations. The client can directly use ContainerD's components to implement whatever it needs, which allows it to do things like building or distributing images any way at once. This leads to the first subproject, ImageCrypt. This tool in Library makes use of ContainerD's extension points to support encrypted containers. It contains a command to encrypt and decrypt images from a client. It also has a stream processor, which allows ContainerD to decrypt images during the unpack phase of a pull. This can be enabled by configuring a stream processor plugin in ContainerD, which is configured to handle specific media types and images. In this case, the media type is an encrypted TAR archive. Next, let's take a look at the StarGZ snapshotter. This snapshotter enables lazy pulling of any image which has layers in the StarGZ format. The StarGZ format is a backwards compatible form of a GZIP TAR, but with an extra index that allows retrieving individual files. The StarGZ snapshotter utilizes this design to quickly start a container before all the file system content is locally available. You can see by the benchmarks that this has a huge impact on container startup time. This is also advantageous since in many cases, the container processes never even read a majority of the container's file system. This can be enabled in ContainerD as a proxy plugin, which allows StarGZ to run in a separate process and have ContainerD connect to it via GRPC. We also have the Rust TTRPC project. This is a Rust implementation of TTRPC, which enables Rust Container Runtimes to implement ContainerD's Shim API. There's a lot of interest in multiple projects right now that are implementing Container Runtimes in Rust. This library enables them to easily utilize them in ContainerD in the most efficient way possible. Lastly, I want to discuss NerdCuttle and show a quick demo. NerdCuttle is the latest ContainerD subproject and aims to make ContainerD more accessible to end-users and developers. It provides a CLI experience familiar to Docker users with a higher-level functionality than implemented in ContainerD's core. This includes the ability to create and manage images, do higher-level container management, and even support for compose. All right, let's demo it. All right, now let's take a look at the NerdCuttle command. So if we run it without any other options, you can see what commands are available. So you have run, you have exact, you have build, pull, push, everything you might expect if you're familiar with Docker. Now if we run NerdCuttle Info, we can also see what ContainerD version we're running. So we're running ContainerD 1.5, the RC2. We're also running in rootless mode. So what that means if we take a look at our C groups here, ContainerD is actually running as a local user and a local user's C group. It's using this rootless kit, which is this amazing work that's been done by AkiHero to enable this. All right, let's look at what images we have available. So right now we don't have any images, so let's go ahead and pull Alpine. You can see the output here is the output that you might be familiar with from ContainerD, not necessarily the output from Docker. This is because it's using ContainerD's client library underneath. So now let's take a look at the images. You can see we have Alpine. So let's go ahead and run a container. So we're going to make it interactive. Let's give it the name MyAlpine. All right, now we have a running container. So we can look around it. See it's inside the container running as root. You can see what version we have Alpine. We can go over and see what processes are actually running as my local user on the machine. You can see that ContainerD, as well as the container are all running as my local user here. All right, now let's make a modification inside the container. Let's write hello there to some file. Let's call it atcGreetings.txt. Okay, we're going to exit the container. If we look at the status, you can see that the container has exited. Now let's go ahead and commit that container. So what commit does is it takes the changes that we're done inside of your container, and it creates a new image out of them based off the container that was running. So we're going to run commits from my Alpine. We're going to call it dmgallonAlpine modified. All right, so that created a new image. So if we run your cold images, we can actually see that image there now. Let's output that image to the file system. So we're going to save it into a modified.tar. Okay, so if we take a look at that file, you can see it's a normal OCI image archive. We have all the blobs. We have the index. We can take a look at that index as well. See, you can see the image name that it was created from. We can also see, we can see the manifest. So let's take a look at manifest as well. So in here, this is going to be under blobs. Okay, so if we look at this manifest, we can see it has two layers. The smaller layer is going to be the one that we just created. We can take a look at it real quickly, just to see the change that we just made. So let's take a look at the actual tar. All right, there we go. So we can see that Greetings.txt that was created. So there's also your cuddle build. I don't have build kit installed right now, but if you have build kit set up, you can go ahead and do your normal building container building that you'd expect if you were using Docker build. All right, that's all for the demo. If you're building a project which uses container D and want to propose it as a sub project, please reach out to a container D maintainer sub projects can be run independently with their own maintainers. Our hope is that becoming a sub project may help with visibility and getting new contributors. Even if you aren't building a new project, please get involved in using and contributing to these projects. Thanks everyone for joining. Bye bye now.