 I started. Hi, this is Mihaj Kiveti. I'm a CTO and STSM for IBM working at the Cloud Solution Center and Rahat's Energy Office. I have here with me today Elif Sameddin. She's a Rahat certified architect in infrastructure working at Takeoff Labs. And we're going to talk about Podman and the container ecosystem available with Rahat Enterprise Linux. We're going to introduce and share some of the lessons we've learned in adopting this toolset. But also some of the cool tools we've discovered and ways of working in setting up CI-CD pipelines using Podman, build a Quays, Copioclare, and a couple of other interesting tools from Rahat. Just to give you an overview of the agenda, we're going to cover a couple of team-driven use cases, how an end-to-end container build looks like, and share some of the experiences we've had in adopting these tools. But also working with Podman to replace other container tools as part of a pipeline and sharing some of these resources and links that you can follow up in adopting similar tools. Just to give you an overview of the use case we're aiming for is how to set up Podman for an end-to-end container build and also how to replace tools like Docker Compose in getting started with container orchestration. So helping you on your journey towards OpenShift or Kubernetes platform by using the same kind of YAML descriptor to build and manage pairs of containers working together. A couple of words about ourselves. So I'm a CTO working for IBM. I'm a Rahat certified architect in infrastructure and I'm an SDSM as well. And I work a lot with Vines, but also I volunteer in working with universities and students and helping them get started with containers, container orchestration, Linux, or software development practices. To be honest, some of the cooler things that I've learned, I've learned just working with students or with young development teams who are just getting started with this container ecosystem. I actually have two groups of students working with me this year at Trinity in Dublin. And I've given them a challenge. I wanted them to build an application as a modern development team would and select whatever application they want to build. A team decided to build an application to perform various analytics on COVID statistics. Another team decided to build an application to support musicians or podcasters or vloggers in getting full audio, connecting it to Raspberry Pi and performing various things. What did these two teams have in common? Well, they've both selected Linux as their operating system and they both decided to containerize their CICD pipeline, which was interesting, right? It doesn't matter what kind of application you're building, at some point you're gonna end up using either Linux or containers in your CICD pipeline. There seems to be a trend in modern development. And given that they were building this application and working together as a team, I requested that they start to migrate what tools they were using, refactor and adopt Podman and move towards OpenShift. I've provided them with some credits. I've provided them with access to the developer sandbox for OpenShift. And they've also started to adopt and to migrate towards that platform. And they discovered a couple of very interesting things that is very easy to migrate to this new set of tools, but also beneficial. So I'm gonna combine the experience that I've had working with clients, adopting the tools myself, but also working with students for volunteering in the community. And here with me, I also have Elif Samedin. She's a Rahat certified architect in infrastructure level too. I think she's recently got her, you know, Podman based exam list, this one she took. And I'm gonna let her, you know, hopefully she's gonna give us a few words about herself as well. So Elif, floor is yours. Thank you for the introduction, Minkai. Well, there is very little for me to say now. Other than that, thank you for having us. I'm happy to have this presentation with you. Thank you, Diane, for having us as well. And what I would add besides everything is that I'm really passionate and I hope to be a promoter for adopting Podman and friends. That's awesome. So let's look at the scenario that we're going to work on together. So I'm gonna take a step back and play a less technical role in the presentation today. Elif is gonna do all the heavy lifting and hard work and hands-on components. I'm gonna talk to you about the end-to-end process of building containers, pushing them towards a registry and how this would look like from an ecosystem perspective. So first we have Podman. What's Podman? Well, I guess it's in the name, right? It starts with Pod and it's a container management tool designed to manage pods, containers and OCI compliant container images. And it's different from existing container technologies that first you can run it as a regular user without requiring root or without requiring a daemon. It actually uses the fork exec model. So if you've run a process with an end at the end and creates a fork a child process, you'll see that in actions. When you create a container with Podman, every container of that would be a child process and it uses namespaces and cgroups and SELinux to secure your container and isolate it. But the interesting part is that it also lets you create Kubernetes definition using Podman generate and Podman play and Elif will show us how those work in practice as well. Before you start wondering, hey, is this a new container technology? Well, we need to remember containers are Linux. It's the ecosystem and the tools that you use that leverage the namespaces and cgroups and other features of the Linux kernel that provide the isolation and provide the user experience and Podman like any other tool is a OCI compliant container implementation. So you can pretty much hot swap it for existing container technologies that you might have been using. With Podman come a couple of friends, right? One of them is Builder. It's designed to build container images from the CLI or from a Docker file. It's also designed to run rootless of course and it can be used to securely build containers in a lockdown environment. And it's a bit different than using a new simple Docker file to build a container. It's easier to script. So if you know how to write a shell script, you probably know how to use Builder. Scopio is another friend of Podman and Scopio is a very, very useful command. If you've ever been wondering, hey, I have this container, I build it on my machine, how do I log into another container registry and copy it here or inspect it or sign it or verify the image signature where Scopio is the key. It can copy images from, well, pretty much any container storage or tar file to any container storage or locally and it can do various things like inspect the image, verify the image, sign it, verify the signature. It's a very powerful and useful tool. Speaking of container registries, let's talk about some of the sources from where you're going to be able to get container images. Now, I'm guilty of this myself, right? I've created containers that I've decided to use for myself and I've published them onto a public container registry and then I've never updated them. I know they're insecure, I don't care, right? I've decided for a single use, I've used them a couple of times and when I checked my image, it has something like 30,000 downloads. I was like, well, that's not me. I hope whoever downloaded a container image isn't using it in production and here's where these container sources come into help. The RAD Software Correct Collections Library or RH-SEL is designed for developers that need the latest and greatest. They're using well, but you may not have the latest tool. You can use this to get it. The RAD Container Catalog is slightly different. It's full of certified, created and verified images with a QA process in place that are upgraded on a regular basis to avoid security vulnerabilities. So if you're looking to build your container images for production, that's one huge lesson learned, right? Just go with this. Make sure that you have a trusted and maintained container image as your source and QA is a private or a public container registry that you can use as well. Now, I know that in a lot of cases, you're thinking, okay, but what if I'm building my own images? Where do I start? And I would advise you to start with UBI, which is a OCI Compliance Secure Base Image. It's based on route. So you can get UBI in version seven or version eight. It's really distributable and it's a bit more than just a base image. It's basically, and I'm gonna show you here, you can get the universal base image. So you can just get a minimal or a innate image for those of you who may be using something like Ansible Molecule and you want to do some testing on your image and you wanna test things like starting a service. Well, that doesn't work in a regular container, but if your container is a UBI innate container as a system D, and you'll be able to start and stop more than one service on that image. I know best practices, you're supposed to put one microservice in a container. Well, that's not always the case. Maybe you're developing and you're building a test framework and rather than wait 10 minutes for a VM to spin up as part of your CI CD pipeline, you're testing an Ansible Playbook, you're gonna run it against your UBI innate container and you're gonna do it in seconds. Another example would be migrating or translating a legacy application which happens to have multiple services that need to start. Now, UBI and UBI minimal are just what it says, right? It's either a rel or a minimal image, which is your foundation on top of which you can get, you know, language runtimes. You can get your Ruby or Python, your PHP or Perl, whatever language runtime of choice that you want to get started from that step on. And again, all of these images are supported by Rel and OpenShift. So as you're building your foundation for your images, you know that you'll always have updates and you're gonna be able to start from a secure image from the get go. And this is one hard to learn lesson in practice, right? It's easy to start building with a simple image, but the moment that you start putting these images onto container platforms that you need to look at security, whether or not you're running processes as root and why should you be running as root? Don't mind the t-shirt, you really shouldn't. It's gonna be very hard for you to refactor once you've accumulated a lot of technical debt. So here is where you'll be able to see that the image is secure, what packages are inside it, how it was built, what the Docker file is and what's the health of your image. Another thing we found to be quite interesting when working with development teams is typically development and operations, even though, you know, everybody's saying they're doing DevOps tend to be different teams, right? And development teams might use something like Docker compose or might use some show scripts could quickly put together an environment that consists of more than one pod. You know, take the typical scenario WordPress and MySQL or MariaDB, two containers, one for your web application, one for your database, some kind of a YAML file to glue it together with Docker compose and you're good to go. But that's not really the way you're going to deploy and manage and build your application when it goes to production. You're probably gonna put it on OpenShift or some other Kubernetes platform. So why would you want to maintain two systems to make this work? Well, if you already have a Docker compose file, you can use podman compose. It depends on podman and Python and pyYAML. Get it, use it, it's compatible. And you can run an unmodified Docker compose file rootless. But if you don't want to maintain these two versions separate, then you can use the podman generate and podman play to generate and create Kubernetes definitions. So you're still creating that YAML with one or more containers, but now they will be useful for you, not just in development, but also moving forward as you deploy your application to production. So if you just want to use podman or scope or any of these other tools, chances are they're already available with your distribution. I'm gonna encourage you to check those out. And if you have any questions, shout out or available on Twitter or other media. With that being said, I'm gonna hand it over to Elif who's gonna give us a hands-on demo of some of these tools in action. Thank you, Mihai. I wonder what it would take for me to convince you to give up your root privileges, I mean the T-shirt. Okay, I'm gonna start sharing my screen now. So as Mihai was saying before, podman enables us to manage container images, containers and even pods. What I'm going to do next is to give you some examples of demonstrations or better said stating why podman provides us with a more secure approach to run containers. Another aspect I want you to keep in mind is how are the processes inside the container actually running? What is interesting or what podman has brought is it made possible for us to run rootless containers. But what are actually these? And we'll explore this in the next two examples. So I have a Fedora workstation. This is a Fedora 33. And I'm running everything under my regular user, Elif having the UID and GID 1000. What I'm going to do, and also I have podman installed. This is version 301. Let's start the container and I'm gonna take Mihai's advice and start even with an UBI 8 container. For that podman run, I'm gonna start this in the touch mode. Just give it a random name. For example, podman 01. Let's choose an UBI 8 and I want this to keep running. That's good. So my container is up. Let's check that. Keep in mind that I have started this container under my user. The question is, how is the process inside the container actually running? In order to find this out, I'm gonna connect to the container. Okay, and as you can already see, I'm already connected as root. Another, the processes are running as root. What would be interesting to explore next would be how does the host actually see the container? What kind of process does this see? Because podman creates containers as its direct sub-processes and for that, let's just prove it. It's much easier. Okay, so I started the container as my user. Within the container, I'm root and the host sees this process under my username, which is Aleph. Is this secure enough? What do you say, Mihai? Almost. I will say I'm root. I think we can do better than that. Oh, yes, of course. Of course, of course. So I'm gonna take root out completely next. Okay, let's start another container. And this time, I'm gonna start from the same command. Just give it another name and start the container with the user sync. Okay, my container is up. Let's confirm it. This is podman02. Let me quickly connect to it. And this time, well, Mihai, I'm sorry to disappoint you, but this time within the container we'll have the user sync UAD5. Well, what does it look like? Just maybe one interesting comment here. One other lesson that we've learned is as teams move and start to adopt open shift or start to adopt an unprivileged container platform in production, they always end up looking back at all of the images they've previously created and going, oh, we can't use any of these because we've built them in an insecure way or we've designed them to run only with root or to bind to a privileged port. So what Aleph is doing here is really awesome. You're gonna learn these lessons and you're going to learn how to properly build images in a secure way from the start. So you don't end up accumulating all of this technical depth. Thank you, Mihai. Okay, I'm gonna disconnect now and what I want to prove next and I want all of you to keep the following in mind. I have started two containers and I have started from an UBI based image, more exactly, UBI 8. First time, in both cases, what is common to this is that I have ran Podman as an unprivileged user, meaning my own personal user. In the first case, the processes within the first container, and that would be the first case, were running as root and the host sees this process running under my username. In the second case, the process within the container was under sync user and the host sees this as a completely different UID. So the second case demonstrates that we are able to run containers as regular users and the container runs in rootless mode, so non-root within the container. So Mihai no longer is happy. I have taken out his root privileges now, but that is not all. The second side would be the fact that Podman allows us to work with, guess what, pods, actually. And this would be an alternative to Docker compose. In order to do that, let's create a pod. Currently, I have none. So we're starting from a clean slate. What I'm going to do next is the following. I'm gonna start the pod. I'm gonna expose port 80 and I'm gonna start two containers within this pod, a database container and the WordPress container and then we have our WordPress container. Furthermore, we're gonna use this to generate a template to be used further with either with a Kubernetes cluster or with the Opshift cluster. So let's give it a start. I'm gonna choose a pretty dummy name. My pod. Map port, I'm going to map port 8080 of the host to port 80 of the pod. What is interesting that doing sport mapping at this point, I will no longer be needing to do this for the containers. Let's ensure our pod is up and it is indeed. I have only the previous two containers up because I did not stop them. Oh, and it is actually three containers. This is the post container which automatically is started and created within the pod. And next, let's try a MariaDB container. Okay. The name of the container is very basically MariaDB. The flag minus minus pod allows us to specify that I want this container to run within the pod I have previously created. I have passed the regular arguments necessary for this container to start and specified the necessary image. So the container should be now running and it is indeed. And the next one would be the WordPress one. Okay. Same. My container starts within this pod. What is interesting and I would like to point out is the fact that I have specified the WordPress DB host to be local host. In this manner, the WordPress container will be able to connect to the database one. And this should be up now. And indeed it is. So what would be the first block post, Mihai? I guess the first block post is wait, I don't have to type a lot of YAML to connect to containers together. Well, I'm gonna pass this WordPress to you to give you this joy. And well, I'm not able to write so much YAML without having typos. I'm one of the persons who does typos almost every time. And this is why I am in love with the feature of generating templates using Podman. And for that, and I hope you'll find this useful as well, I'm gonna generate that Podman GenerateCube is one of my favorite commands using Podman. Let's say WordPress, for example. And voila, this is my template generated with Podman. So how do you want this, Mihai? It would be helpful for Git. I made it to GitHub. You'll be able to find that. I will, this is my present to you for this end of the demo. Hey, that's excellent. Let's leave the folks here on the call with the link where they can find the presentation if they wanna get started or they wanna continue this. So that's it, demo done, Alef.