Podman - The Powerful Container Multi-Tool
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/47268 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Data managementMultiplicationRun time (program lifecycle phase)AliasingFedora CoreCubic graphTrailAcoustic shadowInterface (computing)Computer networkDemonArchitectureDemo (music)Different (Kate Ryan album)Projective planePoint (geometry)Run time (program lifecycle phase)BitCubic graphTwitterMultiplication signPower (physics)Data managementDecision theoryIntegrated development environmentSound effectLevel (video gaming)Perspective (visual)Price indexDistribution (mathematics)
03:38
Computer configurationAsynchronous Transfer ModeDemo (music)Default (computer science)Function (mathematics)Data managementInformation securityData storage deviceComputer-generated imageryPhysical systemWindows RegistryComputer networkDemo (music)Cartesian coordinate systemSource code
03:59
InfinityComputer virusComputer-generated imageryPrincipal ideal domainRootTask (computing)DemonVirtual machineCASE <Informatik>Radio-frequency identificationProcess (computing)Uniqueness quantificationComputer animation
05:23
Overlay-NetzData storage deviceLocal ringPrincipal ideal domainInfinityError messageNetwork socketGroup actionHash functionRootInformationData storage deviceLevel (video gaming)Source code
05:50
Overlay-NetzData storage deviceLocal ringElectronic mailing listPrincipal ideal domainRun time (program lifecycle phase)Error messageNetwork socketRootGroup actionInfinityData managementElectronic mailing listSource codeComputer animation
06:09
Computer-generated imageryData storage deviceOverlay-NetzLocal ringFiber bundleStructural loadInfinityProcess (computing)2 (number)
06:42
RootStructural loadComputer-generated imageryInfinityOverlay-NetzLocal ringData storage deviceProcess (computing)Radio-frequency identificationComputer animation
07:11
Physical systemHuman migrationStructural loadRootInfinityPrincipal ideal domainRadio-frequency identificationNamespaceProcess (computing)Computer animation
07:36
Human migrationInfinityPhysical systemPrincipal ideal domainComputer-generated imageryRootStructural loadFerry CorstenBoolean algebraNamespaceRadio-frequency identification
07:59
Computer-generated imageryInfinityHuman migrationRootPrincipal ideal domainNamespaceInformationComputer fileRadio-frequency identificationLecture/Conference
08:15
Computer-generated imageryInfinityPrincipal ideal domainWeightInterprozesskommunikationRootClique-widthServer (computing)Web pageConfiguration spaceFunction (mathematics)Correlation and dependenceDemonTerm (mathematics)Electric generatorNamespaceSoftwareIdentifiabilityServer (computing)Set (mathematics)Computer fileComputer animationLecture/Conference
10:45
InfinityComputer-generated imageryTerm (mathematics)Local ringStatisticsContext awarenessInformation securityDemo (music)Computer animationLecture/Conference
11:17
Computer-generated imageryInfinityDemonDemo (music)Parallel port
12:08
Computer configurationAsynchronous Transfer ModeDemo (music)Default (computer science)Function (mathematics)Data managementInformation securityComputer networkData storage deviceComputer-generated imageryPhysical systemWindows RegistrySlide ruleData storage deviceLimit (category theory)ImplementationPoint (geometry)SoftwareBitMiniDiscTrailClient (computing)Set (mathematics)Connected spaceDirection (geometry)Process (computing)Mobile appFile systemSlide ruleComputer animationLecture/Conference
17:13
Point cloudFacebookOpen source
Transcript: English(auto-generated)
00:05
All right, go ahead. Hey. Welcome, everybody. Thank you for having me. It's a pleasure. I would like to talk about Potman, the powerful container multi-tool today. So I will speak around about 15 minutes and do some short demos. And then we will have some time to do some Q&A session afterwards,
00:22
around about five minutes. But before we start with the actual content, I would like to introduce myself. So I'm Sascha. Hi. You can find me under that name on GitHub, on GitHub, 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.
00:43
So feel free to reach me out any time. So I'm happy to get into discussions with you. So what is Potman? Yeah, Potman is a container management tool. So now we could ask ourselves, what is a container management tool? It's really hard to describe tools or the purpose of their tools these days, because container management
01:00
tools are so huge, and there are so many out there. But let's defer that question a bit. So initially, Potman 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.
01:21
So this means, in the end, that mostly every talk regarding to Potman starts with something like, yeah. Just put your alias, Docker equals Potman, 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. Potman behaves a little bit different
01:41
and also has architectural decisions made which are completely different from Docker. So if we want to get started with Potman, 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.
02:01
And we also have packages for Mac OS, RAL, Ubuntu, Raspbian. And it's already built in OpenSUSE Cubic and Fedora Core as well. During the installation of Potman, we see that there are a lot of dependencies. So there are not only build-time dependencies
02:22
or dependencies which depend on the runtime itself. We also have dependencies which are configuration-based. For example, CNI, and also CNI plugins, Conmon, and run C down here gives us an indicator that Potman is more or less based
02:40
on different autotools from a container runtime perspective on a level where autotools around gets used. So that brings us to the architectural effects. So Potman is a daemon-less container engine. It uses Conmon for container lifetime monitoring. So we will come back to that later.
03:01
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 Potman. 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
03:22
like Grunsee, or it can also use Kata 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 Fosten 20, which is a price. And what we can see, I can also,
03:41
this should be readable as well. I baked in multiple demos regarding Potman. So the only requirement to run this demo application is to have a Potman installation which supports rootless and root-based Potman executions or containers. So then, let's start with the first demo,
04:04
which is about the basics. So running a container in Potman is more or less a trivial task. So we can run a container in Potman like we already would expect it in Docker. So we just run Potman run, we create our Alpine container, and we do some echo hello world.
04:21
And this works, which is a price, 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 send them into the background. And if you do that with that container, which just sleeps forever, then we get a unique container ID back,
04:41
which can be used to re-identify our container. Oh, we also have a name for sure. And if we now run Potman 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,
05:01
then we can see that our process with pit one is our sleep command, and the ps command is past pit nine in that case. So there is no daemon running for Potman. So this means that konmon is the monitoring tool which has to be dispatched to actually ensure the lifetime of the container.
05:21
So if we now look at my local machine and prep for konmon, then we can see a lot of command line parameters, for sure. But we can also see that, for example, it uses, it uses runc as runtime, as lower level container runtime, and it uses, for example, the storage driver overlay,
05:42
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 runc to have a look into that container as well. So if we do a runc list and then look for our containers, then we see that we have our container up and running.
06:02
So the container manager is lepot in that case, and I am the owner of the container, yay. So this works as well. And if we now kill our process, the 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,
06:23
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, but it ensures that the status of the container gets written to just accordingly.
06:43
So let's come to our next demo, we are pretty good in time, regarding the isolation principles in 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
07:02
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
07:21
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 growing containers,
07:41
then both are up and running. And if we exit into the first container and list 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
08:02
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, yeah, for the networking namespace, they are different. So they have dedicated networking interfaces attached.
08:25
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,
08:41
and Potman wouldn't be Potman if it would not support POTS as well. So let's create a POT. We call it my POT, 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.
09:04
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 pause 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,
09:23
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 the container, and then we can also create another container inside that POT, so we are totally free
09:42
to do anything we want with that POT. And now, if we try to access that Nginx server we currently started, then we will see that we can create a new container, which is just the wget on localhost, and we can see that the Nginx is reachable.
10:01
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 kube manifests from our POTS. So we can do this by POTMAN generate kube, and then we specify our file myPOT.
10:22
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, we have our wget command here.
10:42
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,
11:02
so now no container is running. And then we are able to play, to run POTMAN play kube, 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
11:22
in the previous demo steps. And funny enough, this wget does no fail. This is because this nginx is not up and running during the execution of this wget, because they are all executed in parallel. This is something which has to be considered when creating POT manifests as well.
11:40
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, come, you're pretty, we just have five minutes left, right?
12:02
Okay, we are almost done. I think we have a lot of more demos. I hadn't a 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 systemd handling,
12:21
so there is 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 Fosten20, or the slides are available at the same domain, but slides.com, Fosten20,
12:40
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, it would, there's three more to hear you, sir. You, I saw there was support for MacQuest,
13:02
I was wondering how it's implemented in MacQuest, does it use the Docker desktop VM, or? It's more about the remote client, so POTMAN has this VAR-Link 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.
13:22
Other questions? Oh, okay. Obviously, other corner of the room. Who was it?
13:42
Can you talk a little bit more about networking, and how to forward ports outside of the pods? 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,
14:00
for example, you can specify networks and routes, for example, and rootless networking works, we are, we are slow for NetNS, which is a user-space networking implementation based on a 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,
14:23
but... Okay, that's great, thank you. Okay, I think we are done. Can we run POTMAN with a rootless user, and what are the limitations? Sorry, I didn't... Can we run POTMAN with a rootless user? Yeah. And what are the limitations?
14:41
What the implementation is? The limitation, limitation. The limitation, no, for example, app armor doesn't work rootless, so some features don't work rootless, but generally, I would say, because POTMAN runs in a user namespace, then I don't see any limitation, and networking doesn't work via CNI, for example,
15:00
it's more, could be a limitation, but generally, it works pretty well, the file system works via FuseOverlayFS, which is pretty feature-complete, from my perspective, but if you find anything, you're happy to report it, yeah. Okay, thank you. Okay, so you said that POTMAN is daemonless,
15:35
and it uses containermon to monitor running containers. If I let a container run in the background,
15:42
how will it know that the container died, so it can be restarted or something of the sort? How does containermon work in that situation? Yeah, that's the, totally the job of CONMON to keep track of that, yeah. POTMAN just interacts with CONMON. But does it send like a callback, or? Sorry?
16:00
Does it send like a callback to POTMAN, so it knows that it needs to restart the container? Yes, yes, kinda, kinda, but you don't have POTMAN running, right, so. Yeah. For example, if you run CRI-O, then you have a direct connection between CRI-O and the CONMON processes these days, just for tracking purposes. But for POTMAN, there's nothing running
16:22
than CONMON when a container is running. So it's just a CLI, basically? Yeah, yeah, yeah, and laying out a state on disk. Thank you. Is there any support for Windows?
16:41
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?
17:04
Okay, that looks like it. Thank you. Thank you.