Thank you, everyone.
Thank you for being here today with us.
My name is Perif Shivon.
I usually go by Pingu and this is Eric Kertin.
As an honest, we are going to talk to you a little bit about
bootable containers and image mode.
What are bootable containers?
Well, we know what containers are.
They have been around here for decades,
and they have been the de facto standard today
about how we want to deploy Linux use a space application.
And they have been there for a long time,
which means we have built, I need to speak louder.
All right.
I need my microphone.
And in the microphone.
That's going to be a challenge.
That the microphone doesn't repeat in the room.
It's just what I'm going to call it.
So I'm going to try to speak to Spiny over there.
If you can hear me, don't say anything.
So containers have been there for a long time,
which means we have built the only system around them.
We have built tooling, we've been infrastructure,
we've been platforms to build to leverage all of the capacity that it does.
You know, we've known this as the container native or the cloud native
to links and practices.
The idea of bootable containers is to go one step further than that.
And we don't want to include just the applications and its libraries,
but what if we include the kernel with it and the bootholder and everything.
So we basically no longer have an application image.
We have an OS image.
And that's why it was a call that image mode.
And we can reuse all of the existing tooling and infrastructure
to inspect but to build, to distribute, to deploy, to start, to inspect
all of these containers because at the core of that technology,
we remain in the OCI container standards.
And the question becomes, say, why do we do that?
Well, interesting to do that because suddenly we are managing our operating system
in the same way that we are managing any of our applications.
We allow to, we allow our system,
our users in general, to have a single workflow to build anything.
Be that an operating system, be that an application.
As long as it's a container, it's going to be using the same approach.
We can have, then, you know, all of the tooling that has been built around
container security, being able to do audit container images,
being able to check out for CVs, non CVs in the container images.
Well, we can do that now at the OS cell.
We can load that a little one-step further.
We can look at it from the immutable OS perspective,
you know, container images are immutable.
You can write on them, but then you stop your container,
you restart, and you start from a plane slate,
which means you have increased security,
which means you're maintenance using to be a lot easier,
because that one container image that you're deploying
is going to be the same container image,
regardless of where you deploy it.
So, that one operating system image, as you've built,
is going to be the exact same one that you deploy everywhere.
And we're using something called ComposeFS to increase the security of these images
to ensure time are proofing.
So, ComposeFS is a layer that's basically allows us to leverage
FSVRT at the kernel level to ensure that the image that you're building
is the same one that you've built, and it doesn't change
since you've built it.
And we can do that with all of the ecosystem that we've talked about before.
We can do CICD, we can build things, we can audit them.
So, to come back about immatibility,
it's something that's scary, because well, I want to play with my image.
I want to change it.
While immatibility is not about preventing changes,
it's about controlling that change.
Being sure we secure from the get-go, we secure by design.
It's about being intentional about a change.
Not having a change happened by accident,
or having a change that happens as consequences of something else.
So, that's a quote from Matmoord, the city of Trangard.
I basically give you the sense of it,
I'm not going to read it entirely.
But so, bootable container.
We've mentioned it.
We know what container images are.
You have a basic image, and then you leave your libraries
and application on top of this.
Well, bootable image is the exact same thing.
The average is the same technology.
Still honestly, I compliant container,
except it includes a kernel with it.
It includes bootloader with it.
But all of the tooling are on all of the infrastructure on success,
which means we can build these workflows.
And this is nothing new.
You've seen this for a decade now.
You have a container file.
You build it.
You push it to registry.
Nothing new here.
Damn.
What are we here for?
Well, the beauty here is that now,
with a bootable image containers,
you've heard that container image into an actual disk image.
You can run that disk image into a mesh device.
You can run it onto a cloud public private cloud.
You can run it on a VM on your laptop.
You can run it on your laptop itself.
But the magic happens when you want to update it,
because then you use the same workflow.
You're still after your container image.
You're going to be built to get a new updates.
And then you're going to push that update to a container registry,
just like you would do for a new application.
And then your entire OS here is going to be updated via that container image.
So it's nothing new except it's one step further.
It's we're taking the idea of containerized and using this,
this deployment mechanism, this approach to the next level,
to include the entire operating system.
Imagine not just the application image.
And all of these happens through the magic of bootsy,
which I'm going to let Eric talk to you about.
Thank you.
You know what?
I'm going to hold.
No.
So again, we need to put the video there.
Yeah, I've got it.
Okay, so what is bootsy, bootsy is the tool that basically manages all this.
It's the core tool.
It's in the GitHub containers namespace.
It builds upon over a decade of existing technologies from projects,
such as OS tree and RPMOS tree.
But it abstracts you away from a lot of the complexity.
Because, yeah, most users and citizens of bootsy don't have to worry about the lower level details.
So it abstracts upon all that.
And as all these container like features appear just described.
So yeah, it allows you to deploy bootsy systems.
You can update systems with it.
I should say there's actually a family of bootsy tools.
So bootsy is the main one.
But there's also like sister tools.
You can do rollbacks.
You can even do automated rollbacks.
So let's say your system fails to boot five times.
We have a tool that will that will check the boot counter and say,
Okay, you failed five times.
Let's reboot and rollback into the last version of the operating system,
which was a non-good version and with healthy at least in the past.
There's a stable API and an integrates with podman and all those family of
container tools.
So how does it work?
What is a mutable?
So what is an immutable OS?
Obviously, we have to be reasonable at some point.
So the whole idea is, yeah, it's reasonable at build times.
So there's a base container.
There's a base bootable container image that you can inherit from.
And you can do your DNF installs, copy stuff.
You can run whatever you want to.
Really.
And how does this work?
So there's kind of three different types of file systems in an inability image.
So there's an environment.
This is a persistent but mutable file system because,
yeah, not every device is unique.
So you need something to manage the local state.
So that would start the same on almost every device and
and then manage the local state of that device.
In ETC, what we do is, I don't create it will change,
but it'll also take into account that the local configuration changes you've made.
So to do it three way merge with the update from the container image.
And basically all the other persistent files in the system are read-only
and backed by FF's version to check that there.
And they're intentional changes, like here you've explained.
ETC is actually an interesting one because there's some versions of these boots,
the operating systems where we make that completely read-only.
So that's kind of configurable if you don't want the user to be able to make.
Any local configuration changes, whatever.
Although it's mutable at runtime because there are certain files that
change at runtime, like I think ETC results.
There are a small handful that needs to be mutable at runtime.
So here are some base images we have for bootsy.
We have for door-based ones and for stream-based ones.
Where it had enterprise Linux based ones.
And actually this is just a small subset because there's a universal blue family
of operating systems from the community.
But yeah, a lot of this is repetition, but yeah, you have your base images
in container file, easy integration, CICD ship, that's all CIMages.
Yeah, as I said, this is a suite of tools, this bootsy tools.
This is not a bootsy tool.
This is the one you use basically to build a base image.
You can also use it to convert into the various formats,
like the three virtualization formats specified here,
and a condenser or a raw file that you just write directly to your disk.
Okay, so yeah, this is a simple flow how it all works.
Your system creates the container file, which is bootable image.
He wants to deploy somewhere.
He pushes it to his OCI container registry,
whatever registry he may have in his infrastructure.
And yeah, then that image gets pulled to the various devices
that are looking for system updates, and it's cool.
Thanks.
Yeah, and we've not paid service, and we also have a raw back service.
Say if a certain health check failed in a real life G, that's a bad version.
I better roll it back.
So yeah, that's related to the raw back to health checks.
Yeah, so it's operating systems are obviously growing
in complexity all the time, and more important than ever
is to manage your dependencies in your container.
So I don't know if you've used to, people in the room have used to
as a renovator, dependable, but they're basically these bots that
will automatically check for updates.
And then open a PR in your GitHub or GitHub repo.
And that's actually quite useful, because then the PR is open by the bot.
And then you can go through your CI and run all your tests.
And why this is useful with bootsy is, say, the bot has made the
change to container file, then your CI CD.
You can stack that container file as a container file,
as a container file.
Just with podment, run your tests as you want.
Or if you want to more complete operating systems tests in your
inner CI infrastructure, you can boot up full VM and run your test
weeks.
And the Mac, your PR is green or red, and someone can review it and merge,
or whatever.
So this is one of the most powerful things about bootsy.
I'm about to open a program, use tag, yeah.
Yeah, I think I explained all that.
Container registries.
So this is basically saying when you, once you merge your PR,
if your automation is, if you set up your automation,
you can just push directly to the registry, then all the various nodes
can pull it.
Yeah, it's, if you're familiar with podman scope,
it's all the same tooling, as PR said,
that we've had for like a decade, and also it's all very mature
technologies.
Yeah, you can use a red hack,
quay as an OCI registry, or maybe even in house OCI registry,
which is perfectly fine to use also.
Yeah, so this is just a scribe not, obviously when it's stored in the OCI,
container registry, when you pull it down,
it's actually not a bootable container.
At that point, it's just a normal podman container,
which is actually kind of cool, because you can do your podman
and run and play around with it.
But obviously there's a conversion step that will
convert it to an actual undisk format for
public cloud loadage devices, bare metal servers, that kind of thing.
Yeah, so quadlicious is a tool that's been
around for a couple of years now.
It's basically if you want to start a container as a
system de-service, that's the long in the short of it.
And the cool thing about footsie images, actually, you can
you can boost full operating systems with them, but with this slide,
it's actually showing, you can also run them as containers.
So actually, to say, I'm copy of an operating system
can be the OS, end an application container, also, which is quite useful.
You know, they're very mutable, then you can use the same version of an operating system for multiple cases.
That's your creep on, do you?
I'm going to skip this slide because I'm running out of time.
Yeah, so join the community, get involved, try it out, give us feedback,
open PRs, any questions?
I apologize if I went through something faster than just
very time, but yeah.
No, you're better than that.
Two questions, one is, what's the part on how do you store it on this?
Is that, like, they can't be fine, or is there always the same type of platform
that you eventually have the container unpacked off on this, give it to me?
Um, there's a bit of a question for them.
The question was,
yeah, it's tricky.
It was basically what is the file format on this?
Yeah, it's, it's, we flew by it in the slides,
but it's basically powered by something called composer-face,
which is an arrow-a-face file system.
It's kind of like a content-to-dressed door.
It's a mercury-ish peer-eves stated.
And let's say I come, and let's see, I come,
image is a mercury-based.
So you have, if you have two container image that are using the
sem file, they're going to address that file using the shell, the file, and so on.
So it's a mercury-tree, it's just like your Gitribo,
and that means if you have two files in the same image that
be only present once in a disk.
And the underlying technology for image mode is up here in
with three, which also happens to be based on mercury.
So the idea is that we are leveraging the file that the,
you see, I, containers image is based on mercury,
to be able to deploy in our PMOE-3, mercury-based,
which is then mounted as a regular operating system when you put.
I would say on the last question, Alexander Larsson has
done talks on composer-face.
You should, what?
That's good. That's good. Yeah.
That's good.
I will say on the last question, Alexander Larsson
has done talks on composer-face.
You should watch that because it's hard to answer that well
in 10, 20 seconds.
Okay.
Well, cool.
The question was how do we handle entry points?
In the context of a bootable container image,
entry points are really make as much sense because when you boot
a real operating system, you're stashing from systemD
and all its various services.
It's not just one service you're stashing.
You could add an entry point
and when you start a bootable image as a container,
it would work.
In the context of a full operating system,
I don't think there's much value in entry points because,
you start with kernel and systemD and systemD
that, like, a thousand things, so it's...
What do you expect to ignore any points
or any of the things that only starts as a bootable way?
Yeah.
Unless you start a via podman run,
then it just starts as an normal container,
so it will take the entry point into account.
Yeah.
Okay.
Is your vision of a slash EDC,
slash verse, slash run?
The same as systemDs1,
because they're two are trying to spend a dice
the way exactly as EDC or run are used.
There are differences, yeah.
The short answer is there.
Oh, sorry.
Sorry.
The question was,
is are the way we treat ATC via
and user the same as the way
systemD defines it for their mutability approaches?
There are some similarities, some differences.
That's it.
Yeah.
They're not the same.
Who wants to go to you?
I have to go to you.
I have to go.
Okay.
And I saw that you had the basic image
from federal action.
Is that the way the cabinet is coming from?
Or is it considered the size for the cabinet systemD
and all the other stuff they need to run?
I would say it's not in the document, right?
The kernel is already.
Also, the question was,
where is the kernel in the bootable container?
Does it come from bass image?
You inherit from the from line?
Or is it someplace else?
Where is it?
And the answer is, the kernel is already pre-baked into the bass image.
Actually, an upcoming feature, I'm aware of,
because I'm excited about it.
It doesn't exist, you can actually switch out the kernel
from your bass operating system if you want.
That doesn't exist yet, so I shouldn't talk about it,
but I know it's coming.
Yeah.
Here's his hand up a little under.
So the question is,
we spoke about slash user being read only,
slash fire managing local state,
and slash ETC kind of managing configurations.
And the question was, what happens to var and ETC
when you roll back?
When you roll back,
there's no changes happen in var actually,
as far as I'm aware.
ETC, I don't think there are any changes there either,
but actually, if there is an option to make ETC read only,
and if you're worried about the roll back going perfectly,
I would highly recommend turning that option on to make ETC read only,
because then ETC rolls back just like user would,
like bite for bite.
We still have the previous one.
We still have the previous image.
So in case of a roll back,
we can still mount ETC from the previous one, from the previous state.
But the question about var is,
so it's going to be the exact same challenge
that you would have today on a containerized application,
that on the point of grade changes to database schema.
You're going to have the same challenge and you're going to,
if you want to be able to do a roll back,
you will need to have as part of your roll back.
Many can use them a way to don grade database schema,
just like you would have today on an application that just updated,
the database can be opened update.
So some challenges, different scale, but some challenge.
Just a question.
Could you repeat that?
I don't know, because it's first I've heard of it.
The question was, what's the difference between this and Linux case?
Just being honest, I don't know.
That's the first I heard of Linux case.
Unless, yeah.
Sorry.
All the questions.
So what is it, as we did you talk to the content mate?
And we have an automatic tool to convert a classic,
or does a mesh to put C in a case of elements?
The question is,
the question is, what does it take to move a container image
from an application to a boot C-based container image?
And I would say, it's one line, the from.
Yeah.
So the question is more, like, I want to, you would say that the support
to say the word where that's not what it is about.
You repeat a little bit for the dynamic image,
based on the dynamic image of this distribution.
I want to use my own distribution.
What's the use?
Yeah.
So the question is, yeah.
I'm going to shorten the question because it was long.
But the question was, these are basically pre-backed images
that just work with Bootsie.
What if you like have a classical container image,
and you want to, you want to turn it into a Bootsie
capable container image?
You're basically looking for this tool, Bootsie image builder.
So I would recommend you integrate your distribution
with this tool, and this is basically, yeah, put your,
you'll end up with a container image in a Bootsie format.
And then you can treat it as a normal container,
or a Bootsieable container.
So that's the magic tool you need to integrate
what if you want to create something from scratch.
Yeah.
So the question was, I believe it's possible to put the container
in the container, and if so, how does this interact with the host
kernel?
And the answer is, it's very simple.
If you're doing something like this,
where you want to run two kernels,
you start the Bootsie image as a VM,
just in every day, Qem, UVM, or whatever,
hypervisor you want to use.
It's not something so bespoke, you just start as VM,
if that's, if you want two kernels running.
No, it's not that I want two kernels running.
Yeah.
And understand that you can start the kernel,
and inside the container.
Yeah, so if you're, if you're just testing the container,
and you do Bootsie run container image,
there's only one kernel.
It's just a normal container when you use it in that fashion.
Okay, so it does not boot the kernel in the container.
No.
But the kernel exists as files, but you don't touch it.
It's only when you convert it to a VM format,
or anaconda, or raw, that's when you boot it like
a normal everyday system that you actually use the kernel
from the bootable container.
It's very flexible.
All right.
That's all that I'm here.
So let's take a look at that.
Thank you.