So my name is Dan Walsh. I work for Red Hat. Um, I actually am the, my title, my official title is Lee. My job role is a consulting engineer at Red Hat. My title is lead architect of the runtimes team at Red Hat.

So we handle everything underneath Kubernetes and underneath open shift needed to run, uh, containers. Um, so we have a whole bunch of people working on our teams. Um, and we've been developing a whole bunch of, uh, really we should call them container engines. The runtime term is overused. Um,

really what these are is container engines and I see the low things like run C and Kata containers as being, is really being the runtimes. So really these things are container engines. Um, so this talk is called replacing a Docker with Podman. Um, really what we have view of the world is actually replacing,

tearing apart what Docker did into a series of sub components. So Podman really is, is replacing the Docker CLI. So sort of the traditional way you ran Docker commands is what we're looking for for with the Podman command. So, um, first you, uh, DNF install, I could have put app get up, up here. Uh,

you DNF install Podman, then you do this. Any questions? And to show you that's true. Uh, this guy, Alan Morin, I, who I don't know, a couple of months ago said, I completely forgot that two months ago I set up an alias of Docker equals

Podman and it has been a dream. No big fat demons, project atomic. Um, down below one of the comments to him was, how did you figure out you were using Podman instead of Docker? And he said, I did, um, um, I did Podman help. I had Docker help and it came up and gave him Podman's help message. So that's how we figured it out. So obviously I can't stop at that.

Yeah. So at this point everybody has to stand up. If you've seen me do the talks before, I make you guys participate. Okay. So please read out loud anything that isn't red. Excellent. Nice work. I containers is a Linux thing or it's, you know,

it's basically a concept. And, um, do you guys go make copiers and say, I'm going to make a Xerox?

Or do you take a tissue paper out and say it's a Kleenex? Or do you take an aspirin out and say it's an aspirin? Oh, that's a bad point. Uh, but basically, uh, and at this conference, I cringe in the back of the room every time I hear someone, you know, basically use the D word. And I actually have another talk where I have a swear jar that I put up.

And, um, every time I say the D word, I have to put money into the swear jar, but I'm not going to do that today cause I don't have much money. Uh, but anyways, what do you need to run a container? Okay. What do I, what does it, what does it mean when I run a container? And the first thing you need when you want to run a container, you need to identify what the hell is a container and a container in this

case, um, it has been standardized or at least the image format of what people mean when they say I'm going to run a container. And they're talking about something that sits at a container registry like Docker IO or Quay dot IO or, you know, there's probably a hundred different people out of factory, um, are all doing container registries.

And there's these, these images or tarballs that sit up there, um, and container images. And a couple of years ago, thanks to Core OS, if you saw the talk earlier on, uh, um, uh, Vincent's talk, talked about, you know, sort of the history of container runtimes. Um, Core OS introduced the app C spec caused a fracture.

All of a sudden there were going to be two different types of container images. I mean, it actually forced all of the companies, the big companies that are involved in containers like big companies and startups to get together and say, we're going to standardize on what this, what it means to be a container image. And that's where OCI came out and the big companies I'm talking about, Red Hat, IBM, Google, Microsoft, Docker, um,

Core OS at the time who we've now acquired as most of you know, um, got together and they standardized on what it means to be a container image. Last year, um, uh, last December actually, they came out with the OCI image bundle specification and now we sort of have a good idea of what it means to be a container. So I,

and I say I want to run the Fedora container. I know what I'm going to get when I pull it down or I have an idea of what I'm going to get. So the next thing I need to do is get a mechanism for pulling images, pulling the images off of a container registry to the host. Um, and again, some of this was covered earlier this morning, but basically we built a tool several years ago, actually Antonio,

in the back of the room did to, uh, we actually did a pull request upstream cause we found is that people were pulling images off of a container registries and they were huge. I mean, we're talking some images of 1.5 gigabytes, two gigabytes, right? These are huge images. And there's a JSON file that basically describes what's in the image.

So we said is why not, why don't we build a command like a Docker inspect dash dash remote to pull down the JSON file associated with the image that I could then look at and then figure out if I actually want to pull down the image, right? The only way to get an image and look at what's inside of it right now is to pull it to the host. You have to pull that two gigabytes to your machine before you say, Oh,

that's not really what I wanted. Let me get rid of it. Um, so we went to upstream with that pull request and they said, sorry, we're not interested. It confuses the API or the CLI too much. But he said, they said, but it's just a web interface, right? These are just container registries. Container registries are nothing but web services with tarballs on it.

So it's all web protocol. So they said, go off and build your own tool to go out and pull down the JSON, look at it with your own tool. So we built Scopio. Scopio means remote viewing in, remote viewing in Greek. And that's why we have a Greek hat and a telescope. And so after we built Scopio Antonio actually went off and he started

implementing more of the protocols for pulling registries. So instead of just pulling down the JSON, he also pulled down the image and he also figured out he could use Scopio to push images and Scopio basically slowly evolved into this really cool tool that you can start to move images around the environment and you don't have to be rude to do this.

So you can actually copy off of one registry, copy to another registry without ever having pulled the machine, pulled the image bundle to your, to your host. Um, so it really evolved into a cool tool and we were actually working with CoreOS before we acquired them and we were trying to get, convince them to use Scopio to move images in and out of Rocket. And they said, well, we don't really want to be exacting a tool.

Why don't you make it into a library? So we created a containers image. So containers image is a library that now is working independently. Other people are contributing lots and lots of, uh, pull requests into to be able to move images around. Okay. So it's a really a base level image. The number one contributor outside of Red Hat is actually Pivotal. Okay.

Who's one of Red Hat's biggest competitors in the OpenShift space. But Pivotal is using, you know, basically containers image for moving images and out of, um, I think they call it garden is their, their source for that. So the next thing after you pull the image to the host, you need to be able to explode the image onto disk. Okay.

And usually in Linux world or in a container world, we call it, we use copy on write file systems because basically an image tends to be a layered thing. So you basically want to install a layer of an image. Then you're going to create another type of file system or another mount point on top of it. You put the second layer and you put another layer on top of it and to do that, you use copy on file, copy and write file systems.

So when way back when, when, uh, we were starting first time to work with Docker Red Hat, um, actually Alex, if he's here somewhere, did most of the work. The guy that's in charge of flat pack now, um, basically introduced a whole bunch of, uh, different types of copy and write file systems into what was Docker at the

time. Um, that was overlay FS, butter FS, device mapper. Um, and so what we did is we took the, all that code and we moved it into an independent library. So it was independent from basically the upstream Docker project. And then we went and started to evolve, uh, that library. So all these things are independent. The next thing you need to do,

so you could basically, you'd find an image, we pull the image to the host, we store it on top of top of some kind of storage and then we need a standard mechanism means what does it mean to run a container? Well, luckily OCI standardized on that. So the OCI specification was a runtime. The second specification was called the runtime specification,

which basically says, I'm going to write a JSON file. Everybody has to understand what that JSON file looks like. And then I need to basically launch a program that reads that JSON file and creates the container on the system, all the container processes, the sets of the C groups, security settings, namespaces, right? So that's the last part of running a container on the system.

One other thing we needed is we needed sort of a monitor. When I'm running a container, a container can just exit. Okay. So when a container just exited, right, it doesn't know what's running in a container. It's just a process on the system. So you need something to actually watch that process. If the process exits, you want to grab its exit code and store it somewhere. Okay.

Put it on the system. You actually want to keep open the TTYs that are connected to it because people are going to come to you and say, Hey, what's going on inside of that container? So you need a process that sits out there and sort of monitors it. And that's called Conmon, right? So if you went to the earlier talk, by Antonio, he talked a little bit about Conmon and how it's used inside the cryo.

But Conmon is a simple C program that basically is the parent of the container. So it can parent to the PID one inside the container. It just sits out there running till the container exits, catches, catches the SIG child and then it exits. Well, it basically stores away some last minute stuff and exits. That means that any one of these container engines that we're going to be

talking about, like cryo and like Podman can go away, right? They don't have to stay running on top of the container to watch what's going on. So there's a little Conmon process out there running. Did I skip ahead? Oh yeah. I just explained Conmon and the CNI was up there. Sorry about that. Someone should have said that.

So CNI is basically a way for, it's an interface, again introduced by CoreOS that basically defines a network protocol for the container engines to set up networking. So other people can come in and basically get a plugin interface to plug in different kinds. And it's really heavily used inside of Kubernetes.

We use it inside of cryo. We're going to be using inside of Podmon. So basically all different types of people tooling can basically build a CNI plugin and then we can use it with these tools. So basically we have the four building, or the five, six building blocks here that allow us to experiment with different types of container engines.

And we're not talking about a container engine. That is something that you talk to and say, pull me an image. So I know what an image is. Pulls it down to the disc, puts it on the storage, configures the run C specification or the OCI specification and then launches the runtime. Saves data, like what happens when the, you know,

container exits and reports it back to the human. So it's the basically it's the human interface or the tooling interface for running containers. So one of my problems with Docker is it has become a big fat container demon. Okay. It's become basically a roadblock for innovation. Okay.

Having to have a demon to basically launch processes on a Linux system just seems to be wrong, right? Everybody that runs the Docker CLI, thinks that the container is a child process of the client. What's actually happening is the Docker program client is talking out to the server, talking out to a demon.

And actually the process that gets launched is PID one ends up being a child or a grandchild of the Docker demon, not of your process that launches. I'm going to show you some interesting things about that. But what's also happened is if you have only one way of doing containers, it stops all innovation, right? If I want to do some special things,

if I want to move those container images around, I have to go to the one entity and say, may I please do this? And they say, that's not really of interest in this upstream project. So you get denied. So what I want by breaking it apart, we basically get the best of both worlds. All different tools can use all, basically can contribute to these different components.

And all of a sudden you can start to build some interesting tools on top of it. So this talk is talking about pod man. So pod man means, does everybody here know what a pod is? All right. In Kubernetes world, Kubernetes launches pods. They don't launch containers. What a pod is, is a,

is a process on the system that has one or more containers inside of it. So what they, what Kubernetes wanted is they want to launch these multiple, one or more processes all locked together in the same namespaces and then be able to move them around the system. If people came the other night, there was a,

there's been some talks that talked about these sidecar containers. So you might have your primary application and you might lock into it another container. And that second container is basically monitoring the first container, basically figuring out whether or not that container is, or if it's doing something on behalf of that container. I think someone was talking the other night about basically it does all the

authorization for it. So the application, the primary application can do stuff and not have to worry about authorization. It's just a sidecar container that does it. So Kubernetes wanted this concept where I could run more than one container at the same time around the environment and it just manages pods. So when we built pod man, pod man is part of our lib pod effort, which is basically a library to build pods.

And so we wanted to build pod man as a tool for managing pods and containers in the environment. But what we didn't want to do when we built pod man was basically give you a brand new UI or a CLI. So we wanted to basically, we started out by copying the Docker CLI. So to run commands inside of pod man,

it basically uses pretty much the exact same CLI that you use when you run Docker. So if you find any Docker command in the world, theoretically, you should be able to just substitute pod man for it. So lastly, before I get to the demo, we show, this is the architecture. And again,

this is the same architecture that was shown earlier for the same picture that was shown earlier for a cryo. So we have, when I'm running a pod, I have a series of con months. So when I'm running pod man, it's going to go out and create this environment. So I have a con mon that runs. So if I'm running a pod directly, I will have an infra container that basically just holds open all of these

namespaces and C groups. And then I have one or more containers and running inside of it. So pod man can run pods, but it also can run regular containers. This is sort of the traditional way you run containers. So at this point, we're going to demo it. By the way, the icon here, a group of seals is called a pod. So that's where we got the,

okay, so the, so first, first we're just going to do a pod man version.

We're going to be running pseudo to run it as root. And of course, like any good security engineer, I don't have pseudo without password. So here we go. We just launched, this is a version 0.9 of pod man. It's all written in Go cause that's what the cool kids want to write in.

And what the reason it's 0.90 is this was, well we've been releasing pod man on a weekly basis. So the it's not a one.o yet. And the nine stands for the month and the one stands for the week. So this is the first week of September version of pod man.

And so I'm going to show you info to give you, so it's using container storage. Containers are stored under via live containers. We basically have some additional features up above. You probably, I scrolled off the screen,

but I'm not going to go up cause I'll probably screw it up, but it's running on top of overlay file system. And some neat things that we've added is actually, this is something different than Docker from a security point of view. We actually mount all the devices with no dev by default. So even the images and that's showing you that you can pass in special

overlays, but this is all stuff that's built into container storage has given us all sorts of new features that we can take advantage of. So I'm going to cut out a darker file. So we're about to, this is a darker file that I used when I'm about to demonstrate right now is actually pod man running a container that has builder,

which is builder is another one of our projects, which is a container. It's going to run a builder and build a darker file build based on the top of a darker file inside of a container without giving any privileges to it. So here we go with the demo gods, hopefully this,

so it's going to pull down Alpine image cause that's the smallest image available. If you look at it, we're actually volume mounting in here. I have a my vol directory and volume mounting it in. I'm actually using se Linux. So we're changing the label on it. And then I have via live my containers. I'm bound bounding that into via live containers.

So builder inside of the container in this case is going to be writing to a host directory on the system. And then I'm using a VFS. So I've changed the type of the storage and there it is. So it's now finished. It actually built a container image with no big fat demons.

So there's no demons running on the system. There's nothing up my sleeves or whatever. Basically, I ran inside of a container, another container on side of a lockdown container that basically built an image. And now that an image could actually be pushed to a container registry all without any special privileges. So you can imagine it when we talked about cryo earlier,

you can actually use tools like pod man and build up inside of containers that are locked down. So you can actually run really interesting workloads inside of a Kubernetes distribution. This kind of shows it. So here I'm going to actually, I'm going to show the image that was just built.

So oops, that's interesting. It doesn't enjoy that, but here we have, I pulled down an Alpine image. It actually had a couple of layers that got installed and then basically it ended up creating my image inside of it.

So clear that screen. So interesting thing here is one of the things I get asked often when I, you know, I'm a supposedly a security guy. When I go to customers, customers are all worried about their, their engineers are coming to them all the time and saying, I got to build this darker thing. I got to build this darker thing and I have to get access to the darker socket. So the darker socket is running as root.

And you can actually do things like Docker run dash dash privilege, dash V slash colon slash host fedora chroot slash host. And boom, I have full root on the system. It's actually worse giving someone access to the darker socket. Is that worse than giving them sudo without a password because there's no

logging. As soon as I screw around on your machine, I can go and blow away that container. And as soon as I blow away that container, all the logging gets eliminated from the system. So what they want to do is they want to be able to use the darker CLI on the system without requiring root. So here we are show, I'm about to show you running pod man without root.

So I'm going to pull an image and again, hopefully the network stays up. Everybody that's doing a yum update on the system, please stop right now. So it's going to pull down an image to the system. Usually this is very fast, but this network is talk amongst yourselves.

Right? So this is pod man running without root. There is no demon out there. And what happens when I run pod man as a non root user, it actually creates the storage. So instead of the storage being out on via live containers, it actually ends up being home directory dot local slash share slash containers

slash storage, I believe. Okay. So actually I'm going to show you that I just pulled down an image to my system. And just for, that shows you the images on the host. So there's a lot more images on the host is only one image in my home directory. If I want to run a container on top of,

so there I just ran Alpine container, ran the LS command inside of a container in my home directory, no root needed. So what are we doing to cause this? So how are we actually doing this?

We're taking advantage of the user namespace, which most of you have never seen before, or at least had very little exposure to. So we actually have a tool under builder called builder on share. I just want to show you, it's basically puts you into a user name space without being inside of a container. So I am right now,

I'm logged in as D Walsh on the system. That process right now that now that's showing you the root on the home directory, that's D Walsh. Okay. So it basically did a swap and turn. So what happens in the system is there's actually a program going on here. So if I did ID right now,

you will see for as far as it's concerned, I am running as root on the system. If I did a cat of proc UID map, you would see the mapping that's going on inside of the user namespace.

So if you logged onto a Fedora system and probably Ubuntu has the same thing, shadow utils now puts every user that logs into the system and puts an entry into SC sub UID and SC sub GID that defines the mapping that is available to the, this user on the system. So my system, you'll see, as I said, my UID is 32 67.

It maps UID zero to that and it said there was one mapping in the range. Then it says, I'm going to map UID one to a hundred thousand and I'm going to do it for 500,000 UIDs. So that means in my home directory now I can map 501,000 UIDs.

I can create UIDs from my own UID as well as 100,000, 100,001, 100,002 all the way up. And those would be mapped to one to 500,000 inside of the container. Pretty cool, huh? It leads to some interesting problems though. I can create content in my home directory that I can't delete after I do it

unless I'm in the user namespace. If I exit the user namespace back to my regular UID, I have files in my home directory that I can no longer delete. So I actually just wrote a blog on this this past week. Okay,

so Podman has some interesting user namespace. So user namespace has always been this nirvana for container isolation. I just showed you how you can use it in a home directory, but what would be really nice is if I could use it on the system for separating containers. So if I want to, you know, right now when I run a Docker or a Podman,

I'm using different se Linux labels for each one of them. That gives me isolation. With user namespace, I want to be able to isolate, basically have this container, have this range of UIDs, have this container, have this range of UIDs. And therefore, if I broke out of the container, UID 5,000 would not be able to interact with UID 6,000 on the system,

right? Just like normal UID separation. The problem is the reason we've never used this, user namespace predates Docker. But up to this point, there's never been a file system support for this. So user namespace has been really, really cool, but no one's ever used it.

So what we did with Podman is actually we built, since the file system doesn't support it, what we've done is we're using, we're actually toning files underneath the covers to be able to make user namespace work. So here I'm going to create, I use the namespace for UID 0 to, well, starting at a hundred thousand to 500,000.

That just created one container. Now I'm going to actually look at it. So one of the other things we've done with, actually guys from Susie did this with this work. When I run a container, the Docker had this command called Docker top to show you the processes running inside of the container.

So we've actually used this new library called psgo that actually can do something really cool. We can actually show you the UID inside of the container as well as the UID outside of the container. And this is a brand new tool, better new enhancement to Podman that basically allows you to see that inside of the container, it says I'm user root, but outside of the container,

if I actually looked at that process, the pit on that process is running as a hundred thousand. Matter of fact, I'll show you that right now. So here we see, you know, the sleep program that I launched inside of the container is actually running as a hundred thousand. So if I looked outside of the container, so now I'm going to run another container and this time, instead of using a hundred thousand for the first process,

I'm going to use 200,000 for the first process. So now I have the container and if I look at that container, I'd see that I'm running as root inside of the container. I'm running as root outside of the container. And if I look in the system, I will see that one sleep is running as a hundred thousand. The other one's running as 200,000, but from inside of the container,

they both think they're root. What's happening on the file system. Underneath we've taken the Alpine file system. We're actually choning it on the fly. And we have some really interesting tools that we're adding to make that choning faster and better. All different. Okay. So I talked earlier about darker being this client server model where you exec a program on your file system and it talks to a client,

it talks to a server and that causes lots of issues. It causes things that we can't do, like things like SD notify, right? Everybody knows what system D does with SD notify. Basically you're going to run a process inside of a container and it's going to call back to system D and say, I'm ready to receive a request. Well,

that never worked inside of Docker because you can't get the SD notify is not a child. You put the darker command inside of a system to uni file. It's talking to the darker demon away on a, you know, on a different socket. And the process is saying, I'm ready to Docker. It's not saying it back to the darker client.

It's saying back to the Docker server. So what I'm going to show you is Podman is actually does exactly what you think it does. So the way I do that is there's a pro, does anybody know what this login UID is? When you log onto a Linux system what happens is there's a UID. Part of your process system records that you are Dan Walsh,

right? That you had logged in as 32 67. So this will show this on the system. It basically says I logged in as 32 67. I can't change that. I can become root. I can do anything in the system, pseudo anything else. This login UID tracks me. There's no way for me to get change that login UID once it's set.

That means that the auditing subsystem can record the fact that I did something, whether I was root, a different user or anybody else, but it was Dan Walsh that did it. So here we're going to run a container. So we're running a container and the container is basically showing you inside of the container process right now, it's running as login UID,

Dan Walsh, right? It's running as 32 67. If I run darker, it shows that it's running as UID, that happens to be UID minus one. Okay? Because that's an init system, darker daemon never logged onto the system. So if I do something evil on the system, it comes back via darker,

it comes back and says, darker did something evil. If I do it through pod man, it's going to come back and say, Dan Walsh did something evil. So what I got to do here is I'm putting a watch on Etsy shadow, which hopefully worked. You didn't even know to show that. Oh, it says the rule already existed, which is good.

Cause I ran this earlier and now inside of pod man, I am touching, I am trying to rewrite Etsy shadow, right? And if I do this down here, I got trapped. Shows that a UID D Walsh did something to Etsy shadow. Now if I do it through darker and it shows a UID on set,

did something to Etsy shadow. So what that's demonstrating from a security, point of view, pod man executing a command basically tracks that what the user did on the system as opposed to darker. And this is why I say when you give people access to the darker socket, it's more powerful than sudo because if I go through sudo and I do something

in your system, the audit system knows that Dan Walsh did it. So we showed a little bit of pod man top features. I'm going to run a container. I can see the se Linux label for your pod man top. I can see, this is something that no one sees when they run darker.

No one has any idea. These are the Linux capabilities that are on by default when I run a pod man. So we bought it right shown. People are always asking what capability, everybody's talks about capabilities. What should I drop? What should I add? Well, these are the default lists that you get in almost every container you run in the environment. If you run trial, we run with a lot less, right? A lot of these capabilities are there just to be able to build containers.

Okay. Make node. That's so I can create device nodes. If I'm running containers underneath cryo and production, I'm not expecting people to build device nodes. So we take it away by default. You don't get make node. There's a couple other ones that we get rid of when we're running it. But basically there's different, you know, if you look at running applications,

there's different ways of running applications. In this case, we need more privileges because we don't know what you're going to do with pod man. So we call it pod man for a reason. One of the things we want to do is be able to manage pods. What I've shown you so far is basically all the CLI that matches up with Docker, but here we have pods. So if I want to create a pod,

I'm going to use pod man pod. I'm going to name the pod. And it's going to create a pod in the system that actually the echo line there is wrong. I didn't fix that, but don't worry about it. I'll make this all available and hopefully clean it up. So pod man, now I'm going to actually create another pod and I create a sleep pod,

but in this time I'm going to tell it, I mean, I've got to create a container, but I'm going to put the container inside of the pod. Okay? So this is basically creating a pod. So I created a pod. Now I'm assigning a container to the pod. Now I'm going to create another container and assign it to the pod and guess what I'm going to show on the system. Okay.

These are all the containers I ran earlier, but basically right now it would have worked a lot better. I should have killed all the containers. But basically I am about to start the pod. The two containers I just created did not create containers. So at that point, now you should see two more containers. So you've seen containers that just got second got created. They were

created on the system, but basically they just start status. They got up one second ago. So you can see when I started the pod, now I started both of those containers. If I want to stop the pod, now this is actually a bug. When I'm stopping a container waits 10 seconds for the container to actually

exit. If the, if the tool catches that and sleeps, sleeps actually catching it is a bug in pod man right now that it actually waits on the first one before it sends the signal to the second one. So we actually have to fix that. So it sends the signals to all of them. So it's going to wait about 20 seconds. So there we did it, and we should be back to three containers running on the system. And again,

it'd be better if I killed all the containers before I ran it, but basically it's running. So that shows you pods running on the system. If I want to remove all the pods, I can actually force it to remove all the containers that are created for the pod. And now if I list out the pods, I'm back to zero, pods running on the system. So that is a real quick demonstration of some of the features that you can do

with Podban. So let's talk about other things. I've mentioned some of this stuff earlier since a lot of people here are interested in system D. Over the years, I came to system D conf a couple of years ago, and I gave a talk about the CTO of Docker versus Leonard,

and both of them were being very hard on working together. So one of the things I did when we built Podman is we wanted to have proper system D integration into it. So proper, you can just run a container that has system D and it will just work under Podman without any modifications.

We support, as I talked about with login UID and demonstrator, we actually can do proper SD notify. So we run a container, the container does SD notify, that triggers all the way up into Podman, Podman that reports to system D that the container is up and running and ready to receive actions. We also do

socket activation. So you can actually put Podman into a container, Podman into the system and have system D automatically fire it up and it will pass down the socket down to the process that's running on the system. So other things we wanted to do with Podman is we wanted to have some kind

of, right now it's written in Go, we wanted to have a interface to it that people could use other than Go. So we added a remote API for it. So we wanted to basically say, well, I can run Podman, I can set up a system D socket activated Podman instance, and then have a API that talks to it.

So we actually decided to use VARlink. So VARlink is a API communication tool, a library that we can use to actually do socket activation and communicate to a Podman running on the system and allows you to socket activation the Podman. I mean, here's a unit file that we provide. So if you install Podman, you will get a Podman,

it's actually IO Podman service file, create a socket file and a service file. If you enable those, then you can start to run remote commands with Podman. So here we have a Python. We also provided a Python library that you can build Python programs to communicate with containers. So you can do an input.

This is showing importing a Podman and it's listing, I think it's dumping information. So this is lumping the information about Podman on the host, but basically it's a full API that you can communicate with Python via Python to it. We also have, so we built a program called PyPodman that does all of the Podman commands,

but it's all written on Python. And the Python command talks to the VARlink through VARlink to the server. And so you can do all of Python. Why did we write Python command to do this? Because we wanted to do Python on different operating systems. So here is a demonstration of using PyPodman.

Hopefully this you're not going to be able to see it, but basically it's going to run all the commands on the system. So it's basically doing PyPodman there to list the containers. It's showing you some of the config information showing info.

That's the Podman info command that I wrote. So this is doing it all. And rather than, since most of you people can't see it, the last step of this is it actually shows, this is all running on top of a Mac. Okay? So this is running a Python script on top of a Mac that's talking to a virtual

machine that's running VARlink into a Podman client sitting in a systemd unifile. So we built this protocol to be able to talk from the Mac to the server and we called it SSH. Okay? So we take an advantage. Basically we built, we're basically taking advantage of SSH on a Mac or on a windows box or a

remote Linux box to actually talk to VARlink over the system. So if you have all you have to do to make this work is actually use SSH, set up SSH to communicate between the two boxes and it'll work.

We're adding cockpit support since we have clients. So this is this, this is for Steph. So we're adding Podman support into cockpit.

Sadly, I have it running on here and it didn't show any images. So I, we're not going to show you that, but basically I have someone mountain pits been working to help us get this working. But basically we're getting full integration between cockpit and Podman. And in this case we're using node JS to actually talk to the VARlink

protocol to a Podman running in a systemd unifile. Now I say no big fat demons. I'm kind of cheating a little bit. But the thing here is that Podman is just running for the connection that happens. Okay. So we're firing up multiple Podmans every, for every single connection. So we're not doing any kind of monitoring of,

you know, multiple containers or anything like that. So what don't we do? What we don't do. Okay. Right now, so I've talked about us replacing Docker, but the stuff that the Docker demon did that we're not doing inside of Podman. So one of the things we don't do is we don't do auto restart.

Okay. Because there's this thing called systemd, it does a real good job of auto restart. So if you want a container that's going to be restarted, if it fails to blows up, you put Podman inside of your unifile, and it just works. We don't do Docker swarm. We work on Kubernetes. You want to do, if you want to orchestrate lots and lots of containers,

use cryo on top of Kubernetes. We don't do notary right now. Okay. But we'd be very willing if someone wants to open up patches to make Podman work with notary, we'd be very willing to do it, right? That's probably not going to put the engineering into doing that. We don't do health checks yet. Okay.

Health checks could probably be done as a sidecar container, or they could probably be done in, as a systemd unifile, or like a unifile we create. Basically a health check is supposed to come up periodically and make sure that the container is running properly on the system. But we haven't quite figured out how we're going to do about that. We don't do the Docker API.

So if you have tools that talk the Docker API to the Docker daemon, we don't have a tool for that. Lastly, we don't do Docker volumes yet. So Docker volumes, we do most of what you think of regular volumes, file system volumes, but there is people that have built Docker daemons for the Docker daemon

that do volumes. We're looking at doing that very soon. So that's planned on the roadmap to be able to support that. This point, this is the real point where we ask questions. Anybody have questions? Yes. Oh, a lot of people have questions. You're going to be running around.

So first thing in terms of the implementation of Docker API, there is one reason for doing that. Maybe not in Podman itself, but we can just provide some wrapper on top of the far link API because

without that I don't have a integration in all of the IDEs, IntelliJ, whatever. And without that I can, I am unable to get rid of the Docker from the developers workstation.

Because what do you, what do you need? So you're talking about like twist lock and stuff like that? No, no, no, no. I, I mean the idea of from the IntelliJ or PyCharm or whatever or Visual Studio Cloud, every ID for the developer is all talking from,

to a root process, launching a root process. Yeah. I mean we'd be willing to accept if people wanted to build something like that on it, I probably would not be hugely complicated. I understand it's not the scope of the Podman, but it's just an idea of wrapper. That's one thing. And the second thing we get rid of the Docker on almost all,

places except one Docker file and Right. So Docker file is, we still, we support the Docker file format. I might do, we're doing a, I'll sign up for a lightning talk later and I'll talk about builder so I

can do a five minute on builder. But basically right now, Podman only supports Docker file format, builder supports anything you want. Yeah. For the builder, I perfectly know that I can just write simple shell script and create whatever I want, but not everyone should write shell scripts.

Right. But the goal of builder is not to, it's basically allow you to build another tool like Ansible container or a source to image and other people to build tools that don't have to generate a Docker file in order to build an image. But it would be nice to have one standard. Let's let other people question that. I'll talk to you forever outside. Okay.

Just yell. Does Podman support a union of file systems like overlayFS?

Yes, it runs on, right now it supports overlayFS. We've actually, we have a bug on device mapper back, so it supports overlayFS by default. We have a bug in device mapper right now. Device mapper was built under the concept that only one process would do it, but we have ideas of how we're going to fix it. It runs on top of butterfs and I don't know if anybody's tested it.

We also run VFS, so VFS layer. And someone's built a overlay file system for, so when you're running in a non root environments, it's actually using VFS cause you can't use overlayFS on it. But one of my engineers wrote a thing called fuse overlayFS that actually works real well for non root. So we're actually introducing that too.

Anybody else? Yep. You gotta wait. One, two. Okay. One of the reasons I've still been using D and it's mostly for decompose. Yeah. So Docker compose. I didn't put that one up.

We've been asked about that and again, I'd be willing to accept it. We're thinking of that's on the roadmap to do some kind of compose and whether or not we support the Docker compose language or we support a Kubernetes composed language or we support an OpenShift composed language. Again, PODMAN is a fully open source project.

So anybody that wants to contribute is welcome to contribute and we will take patches, you know, for that. But right now we don't have composed yet. Anybody else? Up here.

It's actually plus one for the API because Ansible runs via API, the D-World service API. So without that, so Ansible. Yeah. Well, I mean, we're working on, you mean Ansible container or something? Yeah. Ansible container is where they're looking into moving directly to builder

for support for that. So to get out of, basically get out of the Docker team. And right now everybody's, in my opinion, everybody's basically put the Docker socket all over the place. The Docker socket is one of the most dangerous things you can do. As soon as you give the Docker socket,

you give full root to your system without having any tracking. And most of the time you're doing that to do Docker builds, right? And so usually you're basically giving your people the ability to create a Docker file and then build it into an image. Well, I just showed you that you can run, matter of fact, you can run PODMAN non root with builder inside of a container and actually

build a Docker image and push it to Docker IO. And I just said Docker image, so I owe money. A container image. I blew it. That's I think the first time I really screwed up. Okay. Anybody else? All right. I'm out of time anyways.