All righty, we'll write them at just a few seconds, with fans going to talk to us about
container day.
All right, hi everybody, I'm trying to change it up because many years have given like
the container day 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 snapshoter, which
this is not a talk about arrow-FS, but it's an interesting new-ish file system in 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, folks may have heard of that, but
I'm going to switch to a terminal that I think is big enough, here is just the messy output
of container D, and if you can see all the way up here, this is a Macbook running Mac OS,
it's phoastems of booth, 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, pod, man, 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's
as I'm arm 64 Linux, and again, all the usual commands work.
If we grab for a shim, here's where you see that there's a container D shim called
NERBOX V1 that's actually running, and this is instead of run C, so NERBOX is using LibKrun
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
at 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 that 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. So 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's 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
plugable, so you could do a registry to registry, copy plug-in, you could do all kinds
of interesting things, and 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 is one of the features that uses that, or having a custom algorithm.
In 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 broader 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 a 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, try 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, butter, fS, DFS, device
maper, 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, RFS.
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 error-fs 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
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 GRP 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 Spector Run, we passed that down
to a shim, the shim interface can be implemented by something like RunC, obviously, or
C Run, or on Windows, HCS Shim, and so that process, that binary gets to decide how
to turn that OCI Spector 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, Nerdbox
as a new non-core project that I showed you.
I'm trying to think of any of the others are actually in the containerized organization.
But again, 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 Spector process isolation steps within itself as a rust program.
RunC, 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, you know, macOS, using lib.
K-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 shims 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, et cetera.
Many of them will look similar to what runC does when it starts and stops isolated container
processes.
So, you know, part of my idea for this talk was just 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 a way to create your own custom resources, or to plug in
your own interfaces for egress or ingress, you know, how valuable would that project
have become?
So, I think container D and Kubernetes are both good examples if you think about your
design, you know, one of the use cases that I can consider today that I could enable
by making an interface plug-able and have reduced friction for people using your project
when it's mature and stable, and maybe you don't want to be adding, you know, 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 gets, please stay very quiet doing the questions, the microphone
for the question is not particularly strong, so if we have any chance for fail actually
understanding anything, please pick up and rest a few please be quiet.
Okay, so I haven't had really chance to follow the Transfer Service work, but is the idea
that the snap shutters are going to use the Transfer Service for our going to use which
service, the transfer service, so basically right now most snap shutters implement their
own like pulling 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 snap 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, it'd be us, there are friction
points, that's something we should probably talk about as a community, especially as more
and more people are playing with lazy loading.
So my impression generally is the continuity tends to the extent of the ability to design
a continuity tends to revolve around having like pulling out to a different binary that
does this different implementation.
In OCI, the way we did the extensibility for run time was through hooks, which doesn't
give you everything, but I guess the thing is that it seems to me like for my business
to actually want 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 and they did a very
specific that are from paini directly, I think that you, I don't, I'm sorry as my way
a community 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 the 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-pole or pole, yeah, it's an
interesting idea.
And we, we've seen a question from the chat as well, and I've got to read it.
How well this performance compare with the native Apple container runtime and what the
line is, does this happen or what's the other solution?
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, that we're still experimental with nerdbox, I don't think anyone has real
performance data at this point.
Any other question?
Anyone missing a key call to something?
I might have already left.
No, I don't think there's a lot of them found in K.
I think building K might have lost their phones otherwise.
I guess we're going to be wrapping up the nerds already.
All right, thanks a lot.
Thank you.