 Hello. Yeah, so exactly that. So that's the topic about the talk. So first of all, you know, my introduction. So my name is Ricardo Carrillo Cruz, although, you know, everybody calls me Ricky. I'm a principal software engineer at Red Hat. I've been there for almost seven years now. I'm a member of the productization team at Ansible. We are responsible for building and delivering the Ansible products and we're also, you know, responsible for the installers and operators and other stuff. Previously to that, I was very involved into the OpenStack project as a whole with another company. Then I joined Red Hat with Ansible and then I've traveled around a bit. So I've been at OpenShift Engineering, CD office, and I'm back to the modelship at Ansible because I'm really happy, you know, to be back with my folks. So first, a little bit of introduction because I'm not sure, you know, I don't like to presume things. I don't know if you've ever heard of Podman, if not. So what is Podman? It's a container engine to build, run, and manage containerist apps. So, you know, you can pull images from Docker Hub, Quay. You can build your applications. You have maybe a web app with your source code and you want to create an image and push it. And you can create containers, run them, stop them, you know, that kind of thing. It's obviously open source. We're Red Hat. We're an open source conference that what we do follows open standards like OCI for container images and run time. So it will support things like run C, C run, you know, whatever, you know, it's standardized. You know, it's just like Docker but different. So how is it different? It was designed to support rootless containers from the ground up. One of the things that the Podman folks did is that they didn't want to have like Docker that runs as a demon and, you know, as root. So the cool thing about Podman is that you can run a container as non-root. And basically, if there was some sort of a privilege escalation and you could somehow, you know, get out of the container, you would still be running as the non-root user at the host. It's demon less or like Docker, which has a client server architecture, which, you know, you connect from a client to the server. And the server, you know, spins up the container. And then, you know, it wires up the connection between them for the standard, then I started that out. It doesn't have any kind of demon. It's just a fork and exec. So Podman spins up, spawns the container runtime, the container runtime that spawns the container, that's it. So Podman, you know, you know, goes away. Docker still, like compatible, you know, tries to, it aims to have the same flex as Docker, you know, for the most part, you know, you can even, you know, do like an alias for Docker and Podman would just work. Cool things that it has. So despite being demon less, you're going to still have like Podman as a demon. If you want to access it, you know, remotely, maybe because you want to have, you know, a machine, a host machine with Podman running and you don't want to run Podman from your laptop, you can still do that. That's managed by SystemD. It's not Podman being a demon. It's SystemD doing that. Integration with SystemD. That's another thing that the Podman folks wanted to put into the project. Maybe you have some, you know, legacy application, which you have multiple services, and you want to have like SystemD managing all of that. And my understanding is that there was some issue with Docker and they didn't want to allow that. And, you know, Podman allows you to do that. You can have a Podman container, which, you know, can leave, you know, SystemD managing the services for you. This is actually another cool one that you can actually label your containers with a special label. And if you run a Podman auto update command, Podman will go to either an internal or remote registry, check whether there's a new image for your container. And if there is, then it will pull it and rerun it so it updates the container. You can also have like a SystemD unit managing that if you want to have more automatic kind of things. It supports pods for containers. This is like, you know, just in case you're not familiar in Kubernetes, you have like the single unit for execution. It's a pod. It's not that container itself. So when you want to have containers that share the life cycle and you want them to share like the same storage and networking, you put them into a pod. So that's actually what gives I think Podman the name. It's Podmanager because it allows you to create pods. So you can create a pod and then you put containers in them so you can share networking or storage to have some communication between them. A generation of Podman pods from Kubernetes manifest, you can actually get something like a deployment manifest from Kubernetes and run a command and then you create containers out of it and the other way around. You can generate Kubernetes manifest from Podman objects, which is actually pretty cool. Now another quick introduction for Ansible, as well as an IT automation tool. It's a tool that allows you to automate things for your infrastructure, whether it's deploying servers, configuring your servers, deploying applications, that kind of thing. It's open source with Red Hat. That's what we do. Very easy to learn and use. This is actually one of the cool things about Ansible is that it's the learning curve. It's very low. It's very easy to get going and automate things with it. Agents less. Some other similar tools, you have to install agents in your servers to actually run automation. With Ansible, it's not like that. You have something, you run Ansible from a bastion or control machine, as we call it, and you run automation against your target host. So you don't have to install anything. Providing you can attach to it or use whatever connection plugin to connect to the device, you can just do it. High list Ansible with plugins. Everything with Ansible, it's a plugin base from the connections. You have devices that do not use this as a telephone or Windows machine, so you have a connection plugin for WinRAM, for example. Or maybe you have your host machine in Inventory, which is a static file, but you want to somehow pull your VMs from AWS so you have plugins for Inventory. So pretty much everything in Ansible is plugin-based. You can mix and match and you can extend it. Use case for Ansible Config Management, install packages, set firewalls, create users, groups, that kind of thing. Infrastructure provisioning, you can create VMs, containers, clusters, AWS, GCP, Azure, DigitalOcean, OpenStack, VMware. You name it. We have a lot of modules for that kind of thing. Application deployment, if you need to deploy your bare metal servers applications or containerized applications, or even you can even create VMs with your applications, then push them into your cloud and then you create instances from it. Orchestration, that's my favorite one, because Ansible is so simple and it has such a wide integration with different services, it can actually act as the glue to basically automate all the things. Yeah, AriCloud, all the clouds that are set, networking, you can automate your networking devices, your firewalls, we're also getting into the edge right now. So with Ansible, you put your content modules and playbooks and roles and all that into collections, which contain a particular domain of automation. So you will have a collection for AWS or for VMware, that kind of thing. And you can pull that from Ansible Galaxy, which is a repository in the internet for basically browsing and look for your content to automate your stuff. So this is the collection that there is for Putman, that's been largely developed by another fellow redheader, Sagish Naiman, he's done a phenomenal job creating this very feature rich collection for ultimate Putman containers, because it's not part of the Ansible core, it's available from Ansible Galaxy, so you have to install it with Ansible Galaxy CLI. It's a resource based kind of collection. So we'll have the sources for managing Putman containers, which you can stop, start containers, you can even generate system D units for those containers that you want to run. Modules for building, pooling images, login to registries, whether you know they're internal, public ones, create networks in Putman. You also have like a module for integration with Kubernetes, also for managing pods and volumes. And you know the use cases, you can build and publish container images, push them into Docker or Quay, whatever. You can deploy your container as applications managed by system D, you can actually, okay, so you run a Putman container, but also have a system D generated, so you can start and stop it with system D, which is a really nice feature, because you can do pretty much anything with Ansible, that's another good use case, you can create an instance, then configure the instance with a role that will deploy container as application on it, then you create an AMI from it, and then you have like a blueprint, an AMI which contains your container as app, and you can create instances of it. Yeah, so you can manage your volumes and networks for doing backup and restore for your container as applications, because you can actually not only create volumes, you can also in fear and get information about your current Putman objects. You have info modules for all of that. And if you have like Putman containers running, you can also generate system D units for it with it. And also, you know, following that feature for Putman, it can also help you to migrate workloads from Kubernetes to Putman, and the other way around. I'm not sure, so these are going to be a hard one, because, yeah, I don't have my, so yeah, so this is one word. So I won't be able to do the demo, because I don't have in front of me the terminal. So I'm sorry. But if you go to the last slide, it will contain the link and some, yeah, again, I can even click here. Yikes. Yeah, so if you go to this link, you will find some playbooks and scripts that will have a very basic role that builds an image by using a role for based on an NGINX image. It will create a volume, push some HTML files on it, and then it will create the image with the AWS modules, and then tear it down. So basically, it will depict how you can have a very basic role for creating your container as application and reuse it for creating a cloud image, which you can use for launch your instances with it. And we're out of time.