 All right. Hello, everyone. My name is Irvisha Munani and I'm a senior software engineer on the open to continue engines team Hi My name is Ashley. I'm on the same team and I work on pod man and build up and our talk is going to be about What's new in pod man and catch you guys up to speed on? the things that are happening here So for people who are new to pod man, let's just start off with what is pod man? So from our Website, you can see that pod man is a demoness open source Linux native tool designed to make it easy to find run build share and deploy Applications using OCI containers and container images So it's kind of like a mouthful But simply put if we go to the next slide, we can see that alias docker equals pod man so So now you're thinking like okay pod man can do all these things, but now we see that alias docker equals pod man Why would I use pod man over docker and then so let's just go over some of the like the key features and Why somebody would use pod man over docker? So as you can see Podman can do everything that docker to do so docker fine runs build shares deploys and manages containers Doctor has a CLI has a rest API and a remote option. We do as well So everything that you they can do we can do but we think we do it better so So the things that make pod man special Are that it is demonless and rootless so what does this mean? Rootless you can run pod man as non-root This means that you don't have to give somebody access to root on your computer In order for them to use pod man This increases the amount of security that you can use using pod man And if you don't want to give somebody you know root access to your computer or if something Happens and a process breaks out. They will never have root access on your computer Even if something bad happens pod man is also demonless it uses the 40 second model So there's no single point of failure, and it's a lot more lightweight You don't have a demon sitting there hogging up like CPU cycles It's just simply fork exact. No constant monitoring of what's going on on your system Podman also has an extremely active open source community as of now or January 14th So last week ish we had 363 individual contributors and in our RC that's coming We're releasing for us soon, but in our RCs that we did in the past few weeks We had around a thousand one hundred thirty six commits around four months of work We have 12k stars and one point two k forks, and you can see in just one week from January 14th to January 21st. We had 43 pro requests and 44 commits from 22 authors So there's always something going on on our github, and if you want to take a look or pop it and say hi I feel free to do so some more stats on our On our community This is just kind of As of a few months ago, these were kind of the numbers compared to some other projects in the container space Moby being Docker container D and then cryo is another project that we have that That deals with containers. You can see we have almost double if not triple the Activity that Docker has and if you want to you know keep updated on what's going on in the podman world We have an evil list that averages around 500 members around one message a day seven days a week So fairly active a lot of discussion going on but not enough to be very spamming to your inbox So feel free to join if you would like And as Tom said in the chat This is just podman only so we have other projects that kind of work with podman like hand-in-hand So underlying tools like build a storage image in common also receive a lot of work So we just we have a very very active community. So Yeah All right. Thanks for that introduction Ashley So as promised, we are going to go over some of the new features that have been added in podman over the last year or so The team and community has been really hard at work enhancing podman and while we have added a lot of new things I'm just going to go over some of the major ones So the first time I would like to talk about is generate and play cube So a pretty common use case is for people to use podman to kind of test test or like their workloads And then use Kubernetes to deploy them So to make the migration easier for this we created the generate cube and play cube command Which is essentially what generate cube does is that you fasten the port or the container You want to create a Kubernetes demo for and it generates that for you automatically You can just pick that cube yamble and plug into your Kubernetes cluster and then deploy your workloads there Play cube does the exact opposite of that where you bring your Kubernetes yamble from your Kubernetes cluster and with Podman play cube We will create the containers and African volumes and stuff that are like defined in the cube yamble So making it easy to go from podman to Kubernetes and vice versa We wanted this to be a viable replacement for Docker compose So we have continuously been enhancing these two commands So one of the big things we added recently was the build flag So we kind of got a lot of requests from the community that They would like podman play cube to build the container image first before deploying the work the containers defined in the The yamble file So we added the build flag which basically looks for a directory with the same name as the image name That is defined in your cube yamble And when there's a container file or Docker file under that play cube will first go there I built the container file and then use that image to trade your container workloads Since Kubernetes doesn't support this if you want to you know use the same Kubernetes yamble in your Kubernetes cluster You will first have to push the image that was built locally to a registry So that Kubernetes can then go up there and pull it down to you know deploy your containers The second one is we added the down flag so basically a cube yamble can be pretty long You can have a lot of containers that you're creating volumes, etc And then cleanup can be pretty tedious if you want to when you're done testing or you want to clean it up Right, so instead of having users go and manually cleaning up everything, you know on their own We added this down flag which when you set that and pass the yamble file that you created with play cube It will go through all the things that was set up stop them remove them and so that you can have a clean environment after that One more feature we added was in it containers. So this is a Kubernetes concept where an internet container is a container that runs to initialize your environment and exits before your main containers start So poor man took that concept and added it and here's also at worth the play cube and generate cube as well And poor man. We have two different times. We have one shot Which means that the internet container will run exit and it will be removed And then we have always the internet can always which means the internet container will run exit But it will stay in the it will stay in exit that state in your history over there So that when you generate when you do a for example bottom and generate cube It will know it will it will detect that there was an internet container and add that configuration to your yamble file as well We also added some health checks equivalent to like the Kubernetes liveness probe and readiness probe All right, so as promised we have some demos. Let me just switch to my terminal really quickly All right, so here we have I'm going to go over a play cube with built So here I have a simple cube yamble file. This is the command And if you see my image name here is called my ubi-8 because I want to build my own image This is what my container file under the my ubi-8 There actually looks like fairly simple just three steps And then when I run fordman safety with the build flag you can see here that the image was built and then committed And then my container and ford was created from that after So if we do look at fordman images the first line here we can see that my ubi-8 was built And then let's take a look at the containers that are up and running There are two containers running here one is the false container which runs when you have a pod up And then the second one is the my ubi-8 container which I had defined in my cube yamble file So now I'm done with this I want to you know get rid of it I just want to so I'll just run the fordman play cube with the down flag and pass in the yamble file again I'm not very creative with names I just called the play cube of yamble And when I run that you can see it said that the pods were stopped and removed And when we looked at the fordman ps we have no containers up and running So that was just a quick demo on using a play cube with both and down Alright so the next thing I want to talk about is our integration with systemd So fordman embraces the power of systemd so systemd as fed one in containers are supported by default Similar to how we have fordman generate cube we have fordman generate systemd So that's the command you can use to create systemd unit files from your pods and containers So this is very useful if you want to create a if you want to have a service that creates a container Unlike boot time for example so instead of you having to write it yourself We automatically have the command that generates those We also support socket activated containers so for services that have very low traffic There really is no need to constantly listen on a socket So when a packet actually arrives at the socket a trigger is fired And fordman is activated to create the containers and processes as needed And the socket is then passed down through the container processes Similarly we have SD notify support We pass down the notify socket to containers so that processes in the containers can use the functionality of SD notify with systemd To notify when it's up and ready and the dependent processes can then you know continue as great as We also have fordman auto update and auto update rollback This is mainly a use case for like edge or like IoT devices So let's say you have thousands and thousands of devices out in the field right and you want to send you want to trigger an update for it So instead of sending like a trigger command what we have is you kind of have a timer that works with systemd basically it fires once a day And fordman is then told to like go check the registry if there's an updated container image if there is pull that down We create the container, we create the service and then so that you have the updated image running But if in that process something fails like the containers and some of some other issues happening Rollback will detect that something has gone wrong so it will rollback to the previous container image that was working To ensure that there's not really any disruption And then when this happens you can whoever is administrating those devices can go in and see what happened And then make a fix to the image, push another image up and then since this happens frequently like once a day kind of a thing The next time the trigger happens, fordman will go up to the registry, see that there's another update, pull that down and then do the process again And then we also have fordman restart service So since fordman is demon less there was really no good way of like, you know, restarting containers on reboot Which is a feature the doctor had with the restart always flag So we have a service that runs on a machine reboot basically goes checks the fordman database to see which containers have the restart always flag set Then it will go and then fordman will restart those containers basically on reboot And we have a quick demo on this as well So here I'm going to run a quick container to show that the system is running inside it So this is just showing that we have the system be running inside the container Let me stop that I need to get out of that Right. So this is just a quick look at the generate system to help menu. We have a few flights and so that you can set So now I'm going to create a container running top And from that continue, I'm going to use a general system deep amount to create a service file And this is what the service file looks like You can see the exact start exact stop has start stop service stop stop service, etc So once I have a service so I can kind of, you know, if I need this I can run it on boot run it anytime I want with system PTR without having to, you know, department run, etc So I reloaded my demon and then for the fears I have no containers running right now. So when I start this service You'll see that we have a container up and running running that's top demand. And then when I stop the service It will stop the service will stop the container and remove the container and as you can see here I have nothing running anymore. And this is just so that you can also access the logs of that service. Sorry, it was edited. So podman also has a recipe API and that kind of goes hand in hand with pub and pie and Docker pie. So podman implements a rest API and it kind of has two sides to it. They have a compact layer or end a live pod layer. So the compact layer is like exactly one to one matches Docker's rest API and the podman the live pod layer is kind of podman specific so extra features that Docker may not have in our in a rest API. So this is our recipe is really useful because you can also be integrated with system D. So you can have socket activated containers that are and you could send the requests using a rest API. So this also goes hand in hand with podman pie and Docker pie. So podman pie is a Python SDK or Python package and they're bindings to podman rest API. So if you're, you know, a system and who doesn't want to be sitting there writing like podman commands all day. You can actually script all your, your whole podman workflow using podman pie and it just uses a rest API and it's just very elegant if you're a Python person. So that's one of the like scripting features that we have currently. All right. And the next thing I'll talk about is the compose support. So this came by popular demand support to make podman work with Docker compose so podman v3 and later works with Docker compose initially it was only working with and with full mode, but recently added support for root as mode as well kind of driving in our focus on security. It's very simple you just need to start the podman socket and connect it to the Docker compose CLI. So there's not much to say here I'll just quickly show the demo for that. So here I'm starting my podman socket. Let's take a look at the podman version. I'm using 4.0 right now. To just to show that I'm not, I'm not actually using Docker and I'm using podman. You can see that my Docker service is currently inactive. And when we look at the podman service we can see that that's up and running. So I'm going to run a quick container here using the Docker CLI but I'm passing in the podman socket as shown over here. And we can see here that the container equals for men means that this container was created with podman. All right. So this is a simple compose file just building a simple image and then running complete command on that. Similar just pass in the podman socket as shown here and then do docker compose off. And here we can see that the image was built committed and then the container and network was created from that so my application is up and running. And we can see that with podman ps. And similarly when you're done with the compose and you want to bring it down just run docker compose down by pointing it to the podman socket and it will go through the service and like stop the container stop the network and remove all of that. Which should happen anytime now. Yep. And then when we look at the podman ps we can see that none of our containers are running anymore. So that was for compose. One more big feature we have is running podman inside the container. So if you're kind of desk from us last year that Dan and I gave a short talk on this. I'm not going to delve much deeply into this since you already gave a talk on it. But basically podman runs inside a podman container and podman also runs in Kubernetes container. We were two blogs that highlights the different use cases of this so running in root full and ruthless mode and privilege on privilege mode, as well as running image builds within the container. So if you're interested in this one check it out the links are here. We have also uploaded our slides to a sketch so you can also download from there and access all the links that are on our slides. So one of the biggest new features that we have or that have we have been working very hard on is podman on non Linux OSes. If you remember from the beginning, we said that podman is a Linux native container management tool. So it's very difficult to get things working on, you know, a Mac or a Windows machine. But if you can go to the next slide, we made it pretty easy to be able to run stuff on Mac. Currently the workflow is kind of just brew install podman. If you worked on a Mac before you know that brews the default package manager or the de facto package manager for for Max. So you would install podman, you do a podman machine in it, a podman machine start and a podman run Alpine. So basically two extra steps you just say podman machine in it, and then podman machine start. And then you can use podman however you would on a Linux machine. Next slide. So I have a little demo. So this is just a recording of my demo. Let's see if it'll play. Oh, no. Okay, so you can see I'm first installing podman. And it's just going to download it from homebrew. And I'm just going to create a new machine, so podman machine in it. And that downloads the machine of VM image, the default VM image that we have and you can see we're using Fedora for us extracting the compressed file. And then so now we have a machine. Now we're going to start a machine. Just wait for it to come up. And then now it started. Now we can use podman like we would on Linux. So like you can forget about all the machine stuff. You can use however you want. So let's do a podman images. I wrote a little web app using Flask. If you're done web development, you know that all it does is return, you know, a home page that says hello. I have a container file, which basically installs all the Flask requirements and then copies everything into the container. And runs Python, the Flask application. So, and literally the same user experience as you would on Linux, you would just do a podman build with this container file. Tag it as Flask app, because it's a Flask app, I guess. And you can see it's pulling everything down. It feels like it's in Linux. You would never know it's in a machine. Takes a bit for it to build. And then we can see that now we have an image with our web app on it. So let's take that image and we're going to run it. And if you know by default Flask hosts on 5,000, but Mac has something weird with 5,000 where it has a default like thing with listening on 5,000. So I'm going to bind it to 8,000. And if I just go to web browser and go to local host 8,000, you can see hello DevCon CC. So the only two extra commands that you would need to type if you were on a Mac is, you know, put a machine in it and then put a machine start. And everything else, it just feels the same. And we tried very, very hard to make it be like that. Oh, I'm just trying to figure out how to make the default screen again. Okay, there you go. Okay. Next slide. Yeah, there you go. So this works on Intel and one. So it doesn't matter which one you have if you have a new Mac for you if you have an old Mac still for you. Root listen root for you still don't need to root for delicious to run it on a Mac. We're working on volume and networking support networking support is mostly their volumes. It's, it's in progress and we're getting quite close to it. And we're also working on a GUI to manage machines. So the GUI written in Swift, you know, Mac native so run stats lightweight you don't have to deal with what is it electron or all like the heavyweight JavaScript like rendering engines it's going to be in it's in Swift. And if we get to the next slide. Here are some screenshots of our work in progress with the GUI, you can see you can like create new VMs on it. And then if you've worked on a Mac before you know there's like a little system bar. So you can just manage your machines from the system bar. If you've ever used Docker on a Mac. It feels kind of like that where you just like press the button and it brings the machine up. Yeah. So, I've talked a lot about machine. So, how does it actually work so you, if you're not familiar with how containerization works on non links OS is, you might be like, Oh, why, why, why do we have a machine. What is this machine about. So as we said that. Podman is Linux native and so are all containers. So when you run containers on non links OS is you have to have a Linux distribution running it. So this means that everything will be running in a VM. And in this case we choose fedora chorus as our OS to run inside of VM. This is not a pork of poppin. Again, containers are Linux like fundamentally like if you have a container, it will be running on Linux. So any other container engine that runs on a Mac is also running on a virtual machine. But we're quite transparent about like, you know, putting machine up like built, we're bringing up a Linux virtual machine to run podman in. So the technology behind this is we're using qnu plus hvf acceleration to run our virtualized native distribution. And so that's kind of like our infrastructure and then inside qnu we're running for door chorus. So that's our Linux distribution. In order to bring up for door chorus we use ignition. It's just kind of this file that kind of sets up everything in for door chorus for us to use podman in. Gvice or tapsock, tapvsock is a proxy application. So in my demo you can see that I bound port 5000 to inside the container to port 8000 on my Mac. On a Linux machine this is just one to one right you're binding 5000 to 8000. But on a Mac it's a little more complicated because you have to take the container point port and then bind it to the host VM port or the VM port and then you have to bind it to like your host port. So gvice or taps vsock is just this application that handles all this like kind of mapping from inside the container to the VM to your host machine. And then SSH is how we connect to the Linux VM so fairly secure. And yeah so the default virtualized distribution is for door chorus. We allow people to use their own distribution if they would like but it there's a lot of setup that needs to be done manually if you do choose to do so. So you're not locked in but for door cross it's easy if like you don't want to think about everything you just want everything to work. Which is you know our goal is just to make everything easy and feel like native on Linux. So we're also that that's kind of the Mac side where we're using Humeo. We're also doing some work on pomeon on Windows. If you've worked on Windows before you know there's this feature called WSL or Windows subsystem for Linux. Basically you can run Linux inside your Windows box and this is supported by Microsoft like ships with Windows and stuff like that. Beforehand we would recommend you that like you would just run pomeon on WSL and pretend it's just on that. But we're looking to implement the same kind of field that pomeon on Mac has on pomeon on Windows. Except for we're not going to be using QMU as the VM we're just going to be using WSL. So the idea behind this is that you have the pomeon client connecting to pomeon running in WSL. Instead of on the Mac you have a pomeon client connecting to pomeon running on QMU. And a lot of work is being done on this place on WSL. So if you just decide to run pomeon on WSL like you don't have to worry about all of this. This is for people who want to be who want to use pomeon from the Windows side and connected to WSL back end. If you just want to take around with it in WSL it should work perfectly. So lots of exciting news and we're kind of breaching out to welcome the people who don't primarily develop on Linux to come and try Podman and see how great it is. So some upcoming work on Podman. We've also been working really hard on build kit support. So if you have used Docker before Docker has kind of this extended build feature called build kit which allows there's just more features that you can put in your build. And one of the big things we've worked on this year is build kit support. So adding stuff like SSH secret mounts or SSH secret mounts cache temp of us. These are all like on the category of run mounts. So if you've heard me talk before I talk a lot about Podman secrets because I worked a lot on Podman secrets. It's kind of the build side to Podman secrets where if you want data inside your build but don't want to in your image. Or if you want data inside only one stage of your build and don't want to expose it to other stages of your build you would use these kind of build kit features. So we've implemented a lot of these and we want to continue taking more build kit features and putting them into Podman and build. Yeah. And another thing that's happened pretty soon in Podman's future is we're having a major version bump from 3.x to 4.x. There's been a lot of new features, a lot of bug fixes, a lot of changes and 4.0. If you take a look at our without a cutting release candidate and if you do a take a look at the notes for a release candidate too. For example, you'll see it's pages and pages long. There's a lot of stuff that's gone. And one of the biggest thing that we did was created a new networking stack for Podman called NetEvark. So this is to help you know close the gap in the networking, the gap we had in our networking and to be able to add more features. Like one of the big ones is IPv6 support. So that's something to look forward to. All right. So here are some resources. These are the links to our GitHub repos. One of the, I guess one thing that might interest you is the demos repo that has a lot of scripts for all the demos that we've done in the past, including the demos for this talk. We also have our website, podman.io, builder.io, cryo.io. And the team and community are Hangout and IRC and Libra.chat under the Pound Podman channel. So if you want to just come say hi or have any issues or want to talk about Podman, feel free to drop by in there. We also have our Twitter handles for Podman and Builda. We used to kind of send out announcements related to the tools and like when we're having our community meetings. So we have one community meeting every two months, which is kind of demos on what's new in Podman from the team and the community. And then we have a community combat meeting, which is a meeting for technical discussions for the team and the community that happens once every month. So we send out reminders to our Twitter channels as well as our mailing lists. And all those meetings are recorded and uploaded to our YouTube channel. So if you couldn't make one of them, you can always go back and listen on what's happening. And as always, we are looking for contributors. Please download Podman here on Podman if you have any issues, open issues. If you have a fix for it, even better, open a PR to fix it. We're always looking for new faces and new ideas and how to make Podman better for everyone. That's what's work off. Thank you. Questions. I think we have two questions in the Q&A. The first one is what about Podman and Minikube? The Minikube link refers to maturity, which might mean that what Minikube wants to do with it is a some Podman's radar. And as I mentioned earlier, I'll mention again, we have uploaded our slides on SCED. And we have a lot of links, so if you go grab the slides from there again, access all of them. Where can we read more about NetEvark? Our NetEvark repo is on containers and slash NetEvark, so get hub.com slash containers slash NetEvark. I don't know, I think Brent is grabbing a link if you want to read more about it. But it's our new network stack, it's our inner rest. It's, you know, lots of work still being done, but it's brand spanking new and I think it does a lot better than what we currently have. Do you know the answer to the Minikube question? Where is that? It's in the Q&A tab. It's in the Q&A tab? I actually do not have an answer to that, but we can get back to you on that. Yeah, feel free to send an email on the email list or hop into IRC and ask this question that we perhaps do not know the answer to at the current moment. And then another question is, a lot of server apps have a Dock and Compose solution and it's not that simple to migrate that to system B services. Is it recommended to use Dock and Compose and then generate a system D unit from that? So we do have Dock and Compose support with Podman. If you want to use Podman, as I showed, you can use the Podman socket to point to it and still have that running. In terms of generating the system D, I don't have a strong answer on that. You can try it and see if that works. I've never tried it, so I am not exactly sure, but if anyone from our team who's watching and has an answer, please put it in the chat. And I think earlier we said that we're gearing up for Podman 4.0 release soon. We have a bunch of RCs out right now and if you're interested in using it and testing our shiny new network stack called Net-a-Vark with it, please feel free to take a look at it and give us feedback on what's happening with 4.0. We would love to have as many users try to use it before we actually release it to the wild. Oh, and Brent put in a link to a blog for Compose Kubernetes Podman. That might have some more insight to that question. There's one more question. I think it's for you, Ashley. Will you be working on the GUI for Windows as well as Mac? That's a good question. We'll see. It depends on if I can convince myself to use a Windows machine. But I've done work on Macs and I've done work on Linux, but I've literally never programmed a single line on a Windows machine. So if I can wrap my head around that, I will be. I personally will be working on it. But we are also like in theory, we are going to be working on a Windows GUI, whether it be from the community or me, we'll see what happens. But that's the roadmap. Our roadmap is everything that happens on a Windows machine should feel the same as a Mac machine. So the idea is we want everything to feel like Linux. And if it's not Linux, we want the not Linux things to feel like each other as well. So everything should be equally balanced in terms of what features we have. So whether you're on Windows, Linux or Mac, you should not be left out. You should not be deprived of a Pogman experience. So yes, we should be working on a Windows GUI. Another question. Any progress on Integrated Quadlet Pogman for Generating System D units to start containers on the boot? It is on the roadmap. It will be there in the future. I don't think any work has started on it, but it is in the plan. And then is Pogman fully supported on Vrel Auto Update and for containers in production? Dan, how about you answer the question you asked? I think it is. I don't fully remember, but I think it is supported on Vrel right now. Please correct me if I'm wrong in the chat. Another question. The answer is yes. Another question is, any chance of RC pre-built binaries for Mac OS and Windows? So we typically don't build binaries for RCs, but it is also kind of difficult for Mac and Windows, mostly because you wouldn't just need a client binaries. You would need to match the version of Pogman that is inside your VM, so you would end up needing to build a custom VM image with the newest RC Pogman. We cut RCs more frequently. When we are gearing up, we don't spend a week or a lot of time in between RCs, so it is kind of hard to keep updating stuff in between RCs. We not only have to build a binary, we have to build two binaries and a VM image, and it is just a lot, but if you ask somebody nicely on our team, perhaps we can link you to something. Not typically, it is not something we typically do, but if you are really interested in it, just reach out to one of us. We basically cut RCs every week while we are gearing towards the release. So kind of a balancing act of doing five things at the same time, RC weeks or release weeks? I think questions have slowed down or stopped. If you have further questions, you can find us in IRC or our mailing list, so I think there is one more. Will there be a podman desktop and will we charge other companies? There will be a podman desktop and no, it will be completely free. The idea with the GUI, the screenshots I showed with the GUI is that it would manage your machine first, and then if we can get managing containers into it, we will see integration with container management with the GUI, and it will be free. We will package it as a DMG if you worked on a Mac. Everything works kind of as a DMG. Trying to get as native as possible with our Mac technology over here. Any other questions? Well, I don't see any questions here in the chat, but it was really a great presentation. Thanks to our speakers over here, Ashli, and thanks for the amazing audience for being here. Thank you all very much, and we are in IRC if you have further questions, so please reach out. Feel free to reach out.