 All right, go ahead. Hey, welcome everybody. Thank you for having me. It's a pleasure. I would like to talk about Portman, the powerful container multi-tool today. So I will speak around about 50 minutes and do some short demos. And then we will have some time to do some Q&A session afterwards. We'll run about five minutes. But before we start with the actual content, I would like to introduce myself. So I'm Sasha. You can find me under that name on GitHub, Keybase, or Twitter. And yeah, I'm mostly contributing to Kubernetes or container runtimes these days. So if you want, then you can drop me also a mail. So feel free to reach me out any time. So I'm happy to get into the discussions with you. So what is Portman? Yeah, Portman is a container management tool. So now we could also ask what is a container management tool. It's really hard to describe tools or the purpose of their tools these days because container management tools are so huge. And there are so many out there. But let's defer that question a bit. So initially, Portman was planned as a debugging tool for the Kubernetes container runtime cryo. But now it's more or less a feature-rich tool which can be used as a drop-in replacement for Docker. So this means in the end that mostly every talk regarding to Portman starts with something like, yeah, just put your alias Docker equals Portman, and then you're all set. That's not completely true. And from my point of view, we have to go back from that common opinion. Portman behaves a little bit different and also has architectural decisions made which are completely different from Docker. So if we want to get started with Portman, we usually just have to install the packages. So we have packages for Arch Linux. We have packages for Fedora and also for OpenSUSE distributions. And we also have packages for Mac OS, REL, Ubuntu, Resbian. And it's already built in OpenSUSE Cubic and for the Fedora Core as well. During the installation of Portman, we see that there are a lot of dependencies. So that are not only built-in dependencies or dependencies which depend on the runtime itself. We also have dependencies which are configuration-based. For example, CNI and also CNI plugins, Konmon and runs C down here gives us an indicator that Portman is more or less based on different other tools or is, from a container runtime perspective, on a level where other tools around gets used. So that brings us to the architectural effects. So Portman is a demon-less container engine. It uses Konmon for container lifetime monitoring. So we will come back to that later. And it supports rootless containers as well. I know that Docker also supports rootless containers these days, but this is more or less an architectural decision made by Portman. It uses the container networking interface, which is a standalone project mostly used in Kubernetes environments for networking purposes. And it also utilizes lower-level container runtimes like Run C, or it can also use Cutter containers. I think there's a talk today about this topic as well. So then, let's come to the demo, pretty good on time. So I wrote a little application which is called Fasten 20, which is a prize. And what we can see, I can also, this should be readable as well. I baked in multiple demos regarding Portman. So the only requirement to run this demo application is to have a Portman installation which supports rootless and root-based Portman executions or containers. So then, let's start with the first demo, which is about the basics. So running a container in Portman is more or less a trivial task. So we can run a container in Portman like we already would expect it in Docker. So we just run Portman run, create our alpine container, and we do some echo hello world. And this works, which is a prize, pretty nice. Yeah, we also have a lot of other command line parameters which are already well known from Docker, like you can give containers a name, or you can detach them to send them into the background. And if you do that with that container which just sleeps forever, then we get a unique container ID bag which can be used to re-identify our container. Oh, we also have a name for sure. And if you now run Portman PS, then we can see that the container's up and running since some seconds. And we can also exec into that container as well. So if we list the processes inside that container, then we can see that our process with pit one is our sleep command, and the PS command has pit nine in that case. So there's no demon running for Portman. So this means that Konmon is the monitoring tool which has to be dispatched to actually ensure the lifetime of the container. So if we now look on my local machine and crap for Konmon, then we can see a lot of command line parameters, for sure. But we can also see that, for example, it uses run C as runtime, as lower level container runtime. And it uses, for example, the storage driver overlay or something like this. So these are all information Konmon needs to actually set up the container and track the container lifetime. So this means we can also use run C to have a look into that container as well. So if we do a run C list and then look for our containers, then we see that we have our container up and running. So the container manager is Lippot in that case and I am the owner of the container, yay. So this works as well. And if we now kill our process with signal sick kill and just the sleep process on the local host, then this succeeds as well and we can see that the container is not running anymore. And it has exited on signal 137. Some seconds ago, this means that Konmon ensures that the signal gets delivered, but it does not ensure that the signal gets delivered and ensures that the status of the container gets written to this accordingly. So let's come to our next demo. We are pretty good in time regarding the isolation principles and POTMAN. So in POTMAN, we have the possibility to play around with the isolation between the container and the host. So this means if we now run a container where we specify that the pit is the host and look at the processes inside that container, then we can see that we have access to the processes on the host. So this means we can also run another container which has a name first in our demo. And then we are able to join that container's pit namespace by specifying minus minus pit container colon first and then we just run another sleeping container in the back. And if we now look into our running containers, then both are up and running. And if we exit into the first container and list at the processes, then we can see that they share the same pit namespace and both sleep commands are attached to more or less the same pit namespace. So they are running in equal containers, but have the same pit namespace. So POTMAN is also able to give us more information about the namespaces by specifying POTMAN ps minus minus ns. And here we can see that they actually share the pit namespace, so this is the same file descriptor. And we, for example, for the networking namespace, they are different. So they have dedicated networking interfaces attached. So let's come to our next demo, which is regarding POTS. So POTS is a concept coming from Kubernetes. So where multiple containers share a set of common resources like the networking interface, and POTMAN wouldn't be POTMAN if it would not support POTS as well. So let's create a POT. We call it myPOT. And we, it's the same like running a container. We just get a unique identified back where we can re-identify our POT. And if we now do something like POTMAN POT ps, then we can see that our POT is up and running. So our POT has only one container attached, which is more or less the infra container. So this infra container is the same like this POS container you maybe know from Kubernetes. It just ensures that the POT is up and running and the network interface, for example, is attached to that POT. If we now run a new container, then we are able to specify our POT via minus minus POT. So if we do the same with our sleep example, like we did in the previous demos, then we can actually run that container and then we can also create another container inside that POT. So we are totally free to do anything we want with that POT. And now, if we try to access that that engine X that we currently started, then we will see that we can create a new container which just, just the W get on localhost. And we can see that the engine X is reachable. Or this is because POTs share their networking namespace. Now we come to a really fancy feature of POTman. POTman gives us the possibility to generate cube manifests from our POTs. So we can do this by POTman generate cube and then we specify our file my POT. And if we look into that file, then we can see that this is a fully working Kubernetes POT manifest with all our containers running in it. For example, we have our W get command here. We executed some commands ago. And if we now remove all our containers from POTman, because this is how the demo should work, then we can demonstrate that we are also able to replay this manifest inside POTman. So this is pretty handy if we want to, so now no container is running. And then we are able to play to run POTman play cube and choose this POT YAML. And if we do this, and we can see that POTman creates a POT and POTman creates also three new containers. And this is more or less everything we did in the previous demo steps. Funny enough, this W get does no fail. This is because this engine X is not up and running during the execution of this W get because they are all executed in parallel. This is something which has to be considered when creating POT manifests as well. So it's pretty good. You can also, if you develop a Kubernetes application, then you theoretically could edit this manifest and then try it out in POTman, which is pretty nice without having the need for Kubernetes at all. So then let's come, I'm your pretty, we just have five minutes left, right? Okay, we are almost done. I think we have a lot of more demos. I hadn't the chance to display all of them. So we have a security related demo, networking regarding the mounting container storage to the local path regarding images, regarding system de-handling. So there's a huge feature set of POTman, which is not probably not, I'm not able to show you all of them, but you can have a look at them on GitHub under my name and then first and 20, or the slides are available at the same domain, but slides.com first and 20. And I think we can now have a short discussion if you want or answering questions. Any questions so far? There. Do you need a microphone? I can hear you, I just want to hear you. I saw there was a port for Mac OS, I was wondering how it's implemented on Mac OS, does it use the Docker desktop VM? It's more about the remote client. So POTman has this walling API where you have a remote, where you can use a remote client to connect to a POTman instance. And that is all about right now. Okay, cool. Other questions? Oh, okay. Obviously, other kind of the room. Who was it? Can you talk a little bit more about networking and how to forward ports outside of the POTs? Oh, the port forwarding works. I would, I'm not, how does it work from a technical perspective? So networking itself works via CNI, so you can specify different configurations. We are the usual CNI plugins. For example, you can specify networks and routes, for example. And rootless networking works via a slope from NetNS, which is a users-based networking implementation based on TAP interface, which gets mounted into the container. So this is a huge topic, but the port forwarding works, and from my point of view, we are SoCAD, which works the same way in Kubernetes, but... Okay, that's great, thank you. Okay, I think we are... Can we run POTman with a rootless user and what's out the limitation? Sorry, I didn't... Can we run POTman with a rootless user? Yeah. And what's out the limitation? What the implementation is? The limitation. The limitation. For example, AppArmor doesn't work rootless, so some features don't work rootless, but generally, I would say, because POTman runs in a username space, then I don't see any limitation. And networking doesn't work via CNI, for example. It could be a limitation, but generally it works pretty well. The file system works via Fuse overlay FS, which is pretty feature-complete from my perspective. But if you find anything, you have to report it, yeah? Okay, thank you. Okay, so you said that POTman is daemon-less and it uses container-mon to monitor running containers. If I let a container run in the background, how will it know that the container died so it can restart something of the sort? How does container-mon work in that situation? Yeah, that's totally the job of Konmon to keep track of that. POTman just interacts with Konmon. But does it send like a callback or...? Sorry? Does it send like a callback to POTman so it knows that it needs to restart the container? Yes, kind of. But you don't have POTman running, right? So, for example, if you want cryo, then you have a direct connection between cryo and the Konmon processes these days, just for tracking purposes. But for POTman, there's nothing running than Konmon when a container's running. So it's just a CLI, basically? Yeah, yeah, yeah. And laying out a state on this. Thank you. Is there any support for Windows? Oh, that's a good question. Maybe for the remote client, we could build it for Windows, yeah? But not right now, I don't think so. Sorry. Any other question? Okay, that looks like it. Thank you. Thank you.