So we're going to have Mario talking to us, but we're playing with Q, being
pardoned.
Thank you.
Thank you very much.
Thank you, everyone.
So my name is Mario.
I recently joined the Department team at Reduct.
So a few months ago.
And today I'm going to talk about something that I didn't know before
that I think it's interesting, especially if you use Q-branadis.
You may not like to have to set up clusters often.
So let's start.
This is the agenda.
Yeah, we'll briefly talk about pardon and Q-branadis pods.
And then pardon and Q-play.
That is the pardon and command that is actually the main topic of the talk.
So first of all, let's briefly talk about pardon.
So we are as fast and container room.
I don't think we need to talk too much to an introduction about pardon.
So I'm not going to do that.
I assume that most of the people know what pardon is.
I'm just going to provide some information.
So it has been released in 2018 for the first time.
And then it's mostly maintained by engineers from Reduct.
We have a lot of contributions, but the maintainers are mainly redactors.
But recently, so a few months ago, we have proposed to have pardon
as a CNCF project.
And a few weeks ago, it has been accepted.
So this is also because we think that in a vendor,
a neutral organization, pardon, may grow more.
We may have more companies contributing.
We don't want for that to be the only that is governing the project.
So now a few comments of pardon, just to try my slides are actually working.
And also to talk about pardon briefly.
So just a few comments.
The first comment that I run to reset to make sure that the next comment will actually work.
So I'm cleaning up all my containers.
Let me make it a little leak.
Yeah.
Then I will just show a container, just the SHVD image.
And to make sure that it's working, I'm actually going to run curl.
And yeah, it looks like it provides, it works.
So these systems slides, so I will use it.
And these are actually comments that are executed on my machine.
That's a Linux machine.
So let's talk about Kubernetes pod now.
Reality is that even if we like to do podman run into actually manage containers with podman or other containers engines,
we usually have to deal with those emails and to run to test our applications using pods,
the Phoenician or the deployment, et cetera.
And the problem of that is that you need to find a cluster.
So either you run mini-cube or kind locally or you need to actually provision a cluster.
Those procedures may be a don't thing, especially if somebody hasn't been doing that a lot.
Also having a mini-cube close to podman or to Docker on your laptop may start things.
You start having a lot of virtual machines if you are running that on my Quest or on Windows.
The idea is we would like to take those definitions of those objects.
You run at these objects. In this case it's a pod.
And there are a bunch of containers defined in a year.
Let me show it fully.
So first container and it is a ready container.
A second container is the web application and then there is also a volume.
So this is something that usually I test with a cube CTL applied.
So the idea is that with podman we should be able to actually take the definition of those objects and run them locally on the machine.
So in a sort podman is translating that KML in local containers.
So that's the common podman you play.
So let's do a demo.
So first of all let me clean.
I'm cleaning containers.
I'm cleaning also volumes.
And now I'm going to run a Q play.
The pod ML is exactly the same pod ML that I showed before.
Okay. And if we make it.
Yeah.
There is actually a podman out which shows that there is a pod that has been created.
And then two containers.
The containers are the containers we are familiar with.
So the two containers that were the final year.
And the pod is actually an object that podman.
So it's another container that actually we call it infrastructure container.
That's set up the namespaces and C groups for the other containers that will actually be executed.
So the little difference is that to support the pod object.
We need to start first an infrastructure container that does nothing.
Meaning that it doesn't run workloads.
But it's actually setting up namespaces and C groups so that those can be reduced.
By the containers that will be added to the pod.
So if we do now a podman, yes.
Let's see what we have.
So we have a first.
I'm just showing the images here of the three containers that are running.
And I see that the first one is a podman post something.
This is the infrastructure container I was looking about.
And then there are the two ready and the web application.
The two container that I was expecting.
So actually podman has been able to start that pod.
Yeah, I'm locally and I'm going to be able to test it right now.
Another thing is that I expect the volume to be created.
And yes, create the volume.
So that's the state of a ready in this case of the container that is using the volume.
In the pod, yeah, it's actually persisted locally.
And if, finally, I try to test the application.
In this case, it's just the application that does a counter of how many visits it has done.
We have done.
And yeah, you see that it's actually, yeah, if I make it.
Even smaller, I should be able to execute that.
You see that the counter continues, et cetera, et cetera.
And this is cool.
But it can also actually, since we're running locally.
And since podman is able to build images from Docker files,
we may want to actually, and we may are in development.
We may want to build the images before we actually start containers.
And this is an option, a build option that the podman,
Q play, the command, Q play has.
So let's clean everything up before doing the demo.
And what I'm doing now is that I am removing from my local machine,
the image that is used on in the pod, the ML.
So that I'm sure that we need to rebuild it otherwise pod, the ML will,
so podman won't be able to start the container.
Okay, so that has been done.
And now I'm running, I'm going to run pod, Q play.
We'll have the same pod, the ML is before, but we have the build option.
Okay, you see that the first thing that it does, it starts actually doing a build.
And you need to make it really small to actually see all the output.
But I should have completed successfully, and I can check now.
Now if I do, if I run this podman images, I should see that the image that I just removed now is back,
because I just really, let's test it.
Okay, so it any says, it has been created three seconds ago.
So the command podman Q play as build the Docker file before, to be able to do that,
there should be a folder with the name of the image where the Docker file is.
That's how podman works.
That's what podman expects to be able to build an image.
So you provide the build parameter, then it checks if a folder with the name of the image exist with a Docker file.
And if it funds that, it tries to build that.
Once you have a build that is started the container, it's worth the new image that it has just built.
So if we run PS, we see again the same container, so our pod has been started successfully locally.
And we should be also able to see the volume and.
Yeah, and the counter again.
So the application, I'm able to curl, so I'm able to actually access the application.
All right, so this is was podman Q play.
Now, we rapidly, another comment that is Q generate, that is actually the opposite.
So what we do is that we are going to clean the system again, remove all the containers.
And I'm going to do to run a simple simple HTTP server.
It started, okay.
And now, yeah, if I do PS, I see that it actually, it's the HTTP.
The container is running.
And I can run this comment, generate.
Let me be bigger.
So it takes as a parameter the idea of the of the container that I just started.
And if I execute it, it will output the pod definition of the container.
So I can pipe the output and I can to to keep CTL and I can just deploy to Kubernetes.
So these are another feature.
So as though they're way around, so from local container to pods in Kubernetes.
All right, so these are the different objects that are supported right now.
So we support pods, we have seen that, we support deployments,
persistent volume claims, config maps, secrets,
demo set and jobs.
So I showed something that I did a new before joining the team.
There are other things that are really awesome of podmen that not everybody knows.
Routeless a demo less.
This is really popular.
I think most of the people know that podmen can be demo less and can be roofless.
But maybe everybody knows about build farms, image volumes.
So you can use images, mount images, input as volumes.
Podlets, podmen is age.
Those are like, yeah, the interesting things that you may not know.
And finally, just a few resources for if you want to learn more about it.
And there is a talk about podlets in a few hours here from Axel.
So don't miss it because it will talk about another cool feature of podmen that is not super well known.
And I think we may have two minutes for questions.
You can probably do one question if someone has something.
You can take those.
Where?
There is.
The left.
Oh yeah, I see.
Hey, thanks for the talk first.
And I was wondering if podmen also handles the life cycle of the pod,
meaning it checks for the lifeless probes and all the rest of the people that does.
Yeah, this is a feature that we.
The, the, yeah, the.
The lifeiness probe, the health check are our feature that we support and can we can restart pod.
Automatically if.
If so, this is something that we support at the container level anyway.
So this is not just the feature of pods, but it's a feature of containers.
So it's you can define an L check and you can specify to restart the container.
If the L check.
Doesn't be as as expected.
All right, thanks a lot.
Any more questions?
You can.
Thank you.