Podman - The Powerful Container Multi-Tool
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Grunert, Sascha
Podman is the container management tool of your choice when it comes to boosting day-to-day development tasks around containers. The journey of Podman started as a drop-in replacement for docker, but nowadays it’s even more than just that. For example, Podman is capable of managing pods, running containers without being root and supports fine granular configuration possibilities. In this presentation, we will deep dive into the exciting world of Podman. We discover how Podman fits into the containers ecosystem, learn about the architecture behind the project and utilize practical examples for daily development tasks. For example, we will learn how rootless containers work technically, how to safely share resources within multiple containers and which benefits a daemon-less container management tool like Podman provides. All these exciting features will be explained by utilizing live demos which leaves room for an open discussion at the end of the talk.
 All right, go ahead. Hey, 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. Hi. You can find me under that name on GitHub, Kibay's, 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 discussions with you. So what is Portman? Yeah, Portman is a container management tool. So now we could ask, also, 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 for 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 open-sousa distributions. And we also have packages for Mac OS, REL, Ubuntu, Resbian. And it's already built in OpenSousa Cubic and for Fedora Core as well. During the installation of Portman, we see that there are a lot of dependencies. So there are not only build-time 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 RunC down here gives us an indicator that Portman is more or less based on different other tools 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 RunC or it can also use Cutter containers. I think there is 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 Fasten20, 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 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 expected in Docker. So we just run Portman run. We 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, do a sentiment to the background. And if you do that with that container, which just sleeps forever, then we get a unique container it back, which can be used to re-identify our container. We also have a name for sure. If you now run Portman PS, then we can see that the container is up and running in 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 PID 1 is our sleep command and the PS command has PID 9 in that case. So there is 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'm the owner of the container. So this works as well. And if we now kill our process with signal sick kill, just the sleep process on the local host, then this succeeds as well. And we can see that the container is not running anymore. It has exited on signal 137. Some seconds ago, this means that Konmon ensures that the signal gets delivered. It does not ensure that the signal gets delivered, but it 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 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, POTman wouldn't be POTman if it would not support POTs as well. So let's create a POT. We call it MyPOT. And it's the same like running a container. We just get a unique identifier 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 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 Engine X server we currently started, then we will see that we can create a new container, which just the W get on local host. 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 myPOT. And if we look into that file, then we can see that this is 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 run POTman play cube and choose this POT yaml. And if we do this, then 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. 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. You're pretty, we just have five minutes left, right? OK. We are almost done. I think we have a lot of more demos. I had the chance to display all of them. So we have a security related demo, networking regarding the mountain, mounting container storage to the local path regarding images, regarding system de-handling. So there is a huge feature set of POTman, which is not probably not, where 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 Fasten20, or the slides are available at the same domain, but slides.com, Fasten20. 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, but I just want to hear you. I saw there was a port for macOS. I was wondering how it's implemented on macOS. Does it use the Docker desktop VM? It's more about the remote client. So POTman has this VARLINK API where you can use a remote client to connect to a POTman instance. And that is all about right now. OK, cool. Other questions? OK, obviously, other kind of the room. What 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 not. How does it work from a technical perspective? So networking itself works via CNI. So you can specify different configurations. We are just going to do a little bit of a demo. So we have different configurations. We are the usual CNI plug-ins. For example, you can specify networks and roots, for example. And rootless networking works via a slope for netNS, which is a user-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 so-cut, which works the same way in Kubernetes. But OK, that's great. Thank you. OK, I think we are done. Can we run a podman with a rootless user? And what's the other limitation? Sorry. Can we run a podman with a rootless user? And what's the other limitation? What the implementation is? The limitation. The limitation. For example, app armor doesn't work rootless. So some features don't work rootless. But generally, I would say, because POTman runs in the username space, then I don't see any limitation. 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, which is pretty feature-complete from my perspective. But if you find anything, you have to report it. OK, thank you. OK. So you said that podman is daemonless, and it uses a container mod 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 or something of the sort. How does container run work in that situation? That's the totally the job of KONmon to keep track of that. POTman just interacts with KONmon. But does it send like a callback? Sorry? Does it send like a callback to podman so it knows that it needs restart the container? Yes, kind of. But you don't have podman running, right? For example, if you run cryo, then you have a direct connection between cryo and the KONmon processes these days just for tracking purposes. But for podman, there's nothing running than KONmon when the container runs. So it's just a CLI basically. 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. But not right now, I don't think so. Sorry. Any other question? Okay, that looks like it. Thank you. Thank you.
 All right, go ahead.  Hey, 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.  Hi.  You can find me under that name on GitHub, Kibay's, 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 discussions with you.  So what is Portman?  Yeah, Portman is a container management tool.  So now we could ask, also, 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 for 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 open-sousa  distributions.  And we also have packages for Mac OS, REL, Ubuntu,  Resbian.  And it's already built in OpenSousa Cubic and for Fedora  Core as well.  During the installation of Portman, we see that there are  a lot of dependencies.  So there are not only build-time 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 RunC  down here gives us an indicator that Portman is more or  less based on different other tools 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 RunC or it can also use Cutter containers.  I think there is 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  Fasten20, 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 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  expected in Docker.  So we just run Portman run.  We 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,  do a sentiment to the background.  And if you do that with that container, which just  sleeps forever, then we get a unique container it back,  which can be used to re-identify our container.  We also have a name for sure.  If you now run Portman PS, then we can see that the  container is up and running in 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 PID 1 is our sleep  command and the PS command has PID 9 in that case.  So there is 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'm  the owner of the container.  So this works as well.  And if we now kill our process with signal sick kill, just  the sleep process on the local host, then this succeeds  as well.  And we can see that the container is not running anymore.  It has exited on signal 137.  Some seconds ago, this means that Konmon ensures that the  signal gets delivered.  It does not ensure that the signal gets delivered, but it  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 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, POTman wouldn't be POTman if  it would not support POTs as well.  So let's create a POT.  We call it MyPOT.  And it's the same like running a container.  We just get a unique identifier 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  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 Engine X server we  currently started, then we will see that we  can create a new container, which just the W get on local  host.  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 myPOT.  And if we look into that file, then we can see that this is  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 run POTman play cube and choose  this POT yaml.  And if we do this, then 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.  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.  You're pretty, we just have five minutes left, right?  OK.  We are almost done.  I think we have a lot of more demos.  I had the chance to display all of them.  So we have a security related demo, networking regarding  the mountain, mounting container storage to the local  path regarding images, regarding system de-handling.  So there is a huge feature set of POTman, which is not  probably not, where 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 Fasten20, or the slides are available at the same  domain, but slides.com, Fasten20.  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, but I just want to hear you.  I saw there was a port for macOS.  I was wondering how it's implemented on macOS.  Does it use the Docker desktop VM?  It's more about the remote client.  So POTman has this VARLINK API where you can use a remote  client to connect to a POTman instance.  And that is all about right now.  OK, cool.  Other questions?  OK, obviously, other kind of the room.  What 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 not.  How does it work from a technical perspective?  So networking itself works via CNI.  So you can specify different configurations.  We are just going to do a little bit of a demo.  So we have different configurations.  We are the usual CNI plug-ins.  For example, you can specify networks and roots, for example.  And rootless networking works via a slope for netNS, which is a  user-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 so-cut, which works the same  way in Kubernetes.  But OK, that's great.  Thank you.  OK, I think we are done.  Can we run a podman with a rootless user?  And what's the other limitation?  Sorry.  Can we run a podman with a rootless user?  And what's the other limitation?  What the implementation is?  The limitation.  The limitation.  For example, app armor doesn't work rootless.  So some features don't work rootless.  But generally, I would say, because POTman runs in the  username space, then I don't see any limitation.  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, which is pretty  feature-complete from my perspective.  But if you find anything, you have to report it.  OK, thank you.  OK.  So you said that podman is daemonless, and it uses  a container mod 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 or something of the sort.  How does container run work in that situation?  That's the totally the job of KONmon to keep track of that.  POTman just interacts with KONmon.  But does it send like a callback?  Sorry?  Does it send like a callback to podman so it knows that  it needs restart the container?  Yes, kind of.  But you don't have podman running, right?  For example, if you run cryo, then you have a direct  connection between cryo and the KONmon processes these days  just for tracking purposes.  But for podman, there's nothing running than KONmon when  the container runs.  So it's just a CLI basically.  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.  But not right now, I don't think so.  Sorry.  Any other question?  Okay, that looks like it.  Thank you.  Thank you.
containers_podman_0_155.png containers_podman_156_1175.png containers_podman_1176_3335.png containers_podman_3336_4223.png containers_podman_4224_5351.png containers_podman_5352_5507.png containers_podman_5508_5567.png containers_podman_5568_5975.png containers_podman_5976_9503.png containers_podman_9504_10775.png containers_podman_10776_12155.png containers_podman_12156_14951.png containers_podman_14952_15647.png containers_podman_15648_16031.png containers_podman_16032_16127.png containers_podman_16128_16511.png containers_podman_16512_16991.png containers_podman_16992_18695.png containers_podman_18696_25847.png containers_podman_25848_25962.png