All righty, I'll write them at the start in just a few seconds with fans going to talk
you to us about the container today.
All right.
Hi, everybody.
I'm trying to change it up because many years have given the container to update, hey,
it's our new version.
Here's the new features.
And rather than bore you with that another year, this talk is going to be a little more
about the project itself and some design decisions, I think we've made that have been
beneficial to the success of the project.
And I'm actually going to start with a demo because I may get long-winded rather
show it to you now and it may help set the stage for what we talk about.
There's two new-ish features that this demo relies on.
One is the arrow FS snapshotter, which this is not a talk about error FS, but it's an interesting
new-ish file system and the Linux kernel that's valuable in the container space.
And the nerdbox shim, which we'll talk about shims, it's actually using the LiveKrun project
that folks may have heard of that.
But I'm going to switch to a terminal that I think is big enough.
Here is just a messy output of container D. And if you can see all the way up here, this
is a Macbook running Mac OS.
It's phosdoms of Boo if you need to for a minute.
But this is container D running on this Mac.
And we've had Mac support in container D. You might question why, because there's not
been a runtime that could isolate processes in the same way that we do on Linux, but
needless to say there have been people working on that.
So rather than I'll show you the command, I'm going to run CTR is a simple client similar
to Docker podman, et cetera.
I'm going to run the Alpine image and run a shell, obviously not.
An exciting demo, but again, try and remember that this is a Mac OS laptop.
I'm not running this inside of VM.
If I, you know, you name inside the container I'm in, it says I'm arm 64 Linux.
And again, all the usual commands work.
And if we grip for a shim, here's where you see that there's a container D shim called
NERBOX D1 that's actually running.
And this is instead of run C. So NERBOX is using LibK Run to run a lightweight hypervisor,
which then inside that has a NIDD process that is listening to communication that actually
obviously uses run C inside the container.
So the reason I show you all that, and again, simple demo, not all that flashy, because
I think decisions we've made that container D's code base didn't have to change it
all for this to work.
I think that reflects a set of design decisions that have made us successful.
We're running everywhere, I won't belabor this slide, but, you know,
container D is pretty much in all the managed services of hyperscalers, many of the
build your own role, your own Kubernetes solutions, all the Chinese clouds, many of them
are very involved in the project as contributors.
They're also using it in their solutions.
And then my company, Amazon, AWS, is using it, and I guess this is maybe the first moment
that this has been mentioned, but Lambda managed instances, which was announced at reinvent
in December, actually uses container D in the data plane.
So your Lambda functions on manage instances are actually running as containers on container
D.
Again, container D is running a lot of places, and again, my positive, my argument for
today is that some of the extensibility we baked in early on and some of the things we've
refined have made it possible for it to be useful in a lot of different ways.
And so we're just going to talk briefly about clients, snapshotters, and shims.
There are some other interfaces in container D that are also kind of interesting.
We built a transfer service about two years ago that allows you to do pull operations or
copy operations, any source to any sync, and that actual source and sync objects are
plug-able.
So you could do a registry to registry, copy, plug-in, you could do all kinds of interesting
things.
We also prior to that added stream processors, which means I can plug my own binary
in to the stream of bytes from or to a registry.
So think about decrypting encrypted layers as one of the features that uses that.
We're having a custom algorithm.
On the client side, again, there's a small kind of very, very simple diagram.
So clients think of Docker using container D, the CTR tool we just ran.
Build kit is a client of container D. There are higher layer ones like Kubernetes, use of
the CRIPI, so container D presents the CRIPI, so that Kubernetes and the Kublet specifically
can drive container D.
And again, so we have a Go SDK that's kind of this rich client.
Obviously you can talk directly to GRPC, so anything you can generate bindings for.
We've done that for Rust and Go obviously so that you can use GRPC services properly.
And then as I mentioned, there's this more kind of thick client in Go that build kit uses
CTR uses.
Again, this is given us like a broad array of potential ways to drive container D,
either through Kubernetes or without the CRIPI, and that lambda managed instances product
I talked about uses container D via Rust client.
And so there's a few groups that are starting to use Rust in and around the container
D ecosystem.
So snapshotters again, trying not to take up too much time, you know, belabering kind
of the architecture overall, but snapshotters are the way that we represent the container
image that you've pulled from a registry, how it's represented in the file system.
And so the snapshotter interface abstracts away the file system details.
So we have a bunch of long time built in snapshotters that you recognize overlay but
are a fast ZFS device mapper.
We have a native snapshotter and the Microsoft team has a couple for Windows and Linux on
Windows containers.
More recently we added a block file snapshotter and as I mentioned, errorFS.
The cool thing, again, here is that we built the snapshotter API, I'll show it on the next
slide, to be very simple and straightforward.
So you care about the details of your file system and container D just needs basic information
like the list of mount commands to run, that you've assembled for it.
But the other thing we did is we built a proxy interface.
So you can build a snapshotter that isn't even part of the container D code base.
And so AWS, we built something called sochi that does lazy loading, GKE also has something
called image streaming that's built as a snapshotter.
There's NIDAS, StarGZ, overlay, BD, these are all kind of lazy loading, new initiatives
from various teams around the world.
And again, because we built this proxy system, they don't have to wait for our release,
they don't have to wait for us to merge their changes.
You can just build a snapshotter and start using it with your custom file system, with your
ideas about how to do lazy loading or fast polling.
And again, that's just a feature that allows container D to be extended without the core
team being involved at all.
We did, as you can see, merge errorFS directly into the core, but it could have been, it
did start as an external add-on snapshotter.
As I said, I'll just show the interface really quickly.
These are the RPC.
This is the interface that you would have to implement if you wrote your own snapshotter.
Again, I don't have all the details here about what these requests, responses look like,
but again, these are simple interfaces that allow you to handle the file system interface
and let's container D only worry about what it needs to know to set up the container or
file system and mount namespace.
Shims are a little more interesting.
So the demo we saw at the beginning was built around this idea that container D has a set
of objects that it manages in its GRPC services that you would expect things like
a container process, the task, the images, the content store.
But once all that's assembled, and there's an OCI spec to run, we pass that down to a
system.
The shim interface can be implemented by something like RunC, obviously, where C run or on Windows
HCS shim.
And so that process, that binary gets to decide how to turn that OCI spec and the bundle
into a isolated process, obviously that what's different on Windows than it does on Linux
with RunC.
But this is generated a very long list of interesting side projects.
Again, we don't have to control whose creating shims, whose offering shims.
Some of them have been contributed into our project, and we call them non-core, like RunWazee,
nerdboxes, a new non-core project that I showed you.
I'm trying to think of any of the others are actually in the container D organization.
But yet, many of these are third-party, they're managed by a group that cares about
this technology.
Some of them are fun, you know, single-person projects like the BSD Jails.
Yuki is a rust.
Shim implementation that doesn't even need runC, because it's implemented the OCI spec
to process isolation steps within itself as a rust program.
I'm going to see Google put that together for G-visor.
And again, the list goes on, Cata, Incubare, Quasar, which actually is interesting, because
it has a runC variant, it knows how to do lightweight virtualization.
And so using other annotations and knowledge about the container, it can decide on the isolation
mechanism.
There's an EBPF, Shim, and then Firecracker, container D, again, something we had put
together when AWS was using Firecracker for lightweight virtualization.
So again, the point here, the Shim interface has allowed people to do their own interesting
things about what it means to isolate a process, different operating systems, what I showed
you was Mac OS using LibK run.
But again, this is a lot of people to do many interesting things that we as container D maintainers
would have never dreamed up ourselves or built ourselves, or maybe would never have merged
into the core project, because maybe we wouldn't know how to maintain them or keep them
over time.
The Shim's implement the task interface, so this is a little bit larger, but it's all
the things you would expect to have to do with an isolated process on an operating system,
create it, start it, delete it, etc.
Many of them will look similar to what RunC does when it starts and stops isolated container
processes.
So part of my idea for this talk was if you're creating something you believe is shareable,
this may not apply if I'm building a command line tool, it's not something I'm expecting
to be extensible, but if you think about Kubernetes as another great example, if there was
an away to create your own custom resources or to plug in your own interfaces for egress
or ingress, how valuable would that project have become?
So I think container D and Kubernetes are both good examples if you think about your design.
One of the use cases that I can consider today, that I could enable by making an interface
pluggable and have reduced friction for people using your project when it's mature and
stable.
Maybe you don't want to be adding many, many things into the core project.
So wow, I'm way ahead of time, so we have lots of time for questions.
We can even show more nerdbox, but not that exciting.
We do have some channels on Slack.
If you ever have a question, if you're interested in adding a feature to container D, come
chat with us there and again, we have plenty of time for some questions right now.
And just before everyone does, please stay very quiet doing the questions, the microphone
for the question is not a particular strong, so if we have any chance for fail actually
understanding anything, please pick up and rest a few please be quiet.
Thank you.
Okay, so I haven't had really chance to follow the transfer service work, but is the idea
that the staff shutters are going to use the transfer service for our going to use which
service?
The transfer service, so basically right now most staff shutters implement their own
like polling logic, which kind of like messes with like CI or I mirror configuration
and stuff like that.
So is there a plan to like get it's not shutters to use this one unified solution?
Yeah, that's a good question, so when you configure the transfer service, if you're calling
at the API, you can specify, here's the snapshotter that will handle, you know, unpack,
etc.
It does get tricky with like a lazy loading technique, so yeah, I'm not sure we have a great
answer for that yet, definitely our work on SOCHI, AWS, their friction points, that's
something we should probably talk about as a community, especially as more and more people
are applying with lazy loading.
Yeah, people, so my impression generally is the continuity tends to the extent that the
ability to design a continuity tends to revolve around having like calling out to a different
binary that does this different implementation.
In OCI, the way we did the extensibility for runtime was through hooks, which doesn't give
you everything, but I guess the thing is that it seems to me like for my business
business it actually won't both rather than just one of the other, because like for instance,
if you wanted to, if some service wanted to hook into getting metrics from the data,
a very specific data from PINDI directly, I think that you, I don't, I'm sorry as my way
of PINDI doesn't really have that many of like the hook style extensions, it's mainly
the pulling out of the extension.
Yeah, so, you know, some of that configurable and containerities config, like a set of stream
processors that I want you to call data dog contributed to plug in for, container, or image
signing, and image verification actually, again, it's similar, you say here's my binary,
go call it when you've pulled an image, it's a good question, I'm, you know, hooks fit in
the life cycle aspect, I guess it'd be interesting to think where they, where they
could fit in the rest of those, I guess images have a life cycle, you can say, you know, trigger
on pre-pull or poll, yeah, it's an interesting idea.
And we've seen a question from the chat as well, and I've found it created.
How well this performance compare with the native Apple container runtime and what the
runtime is, does it have what would say out of some machines?
Yeah, I don't think I'm ready to make any performance comparisons.
I think Eric will be giving a talk in here pretty soon on containerization, obviously
there's lightweight virtualization involved in both, but yeah, we're still experimental with
nerdbox, I don't think anyone has real performance data at this point.
I need a question.
Anyone missing a key call, that's okay.
It's not, I think it's a lot of fun found in K, I think building K might have a lot of fun found,
otherwise.
I guess we're going to be wrapping up the NASA, all right, thanks a lot, thank you.