 and get started. All right, so yeah, my name is Lisa Rangibar. I am a software engineer here at Red Hat. And today I'm gonna be talking about installing nothing and containerizing your demo workflow. I work here at Red Hat in the Edge Filler and a team. And prior to joining Red Hat, I worked in the IoT Edge Group in another company as well. And I've been working with containers for about three years. So I hope that today we'll be able to impart some of the knowledge and let's get started. All right, so let's get started with what is a container? So just from like a very high level point of view, this is a beginner talk. So I made it as beginner as possible. A container is a package that will contain all the dependencies and libraries and things that your application needs to run. It is a lot more lightweight than a VM. Usually when containers are described, we use an image like I have here on the left to show that we're not actually installing a whole another OS and we're allowing those resources to be used for your application instead of the guest OS. The one thing that is kind of important to know when you run your application inside of container is it will have its own file system, network and memory space. And so that means it's completely containerized and it doesn't know about anything going on in the host OS or in other containers. So that's actually part of the beauty. Because everything is packaged this way, you can take your container and then run it on someone else's machine exactly the same way. And so basically it's magic. If I build up my application in container, I can give it to my co-worker and they can run it on the machine exactly like I am. So let's just talk a little bit about how that magic works. The open container initiative is what defines all of this. There is an image spec and a runtime spec. So that basically comes down to building and then running your containers. This, because this is like an open initiative, this is why so many of our container tools are kind of interchangeable. So that's really good to know and check out the open container initiative after this talk if you've not seen it before. Another thing about building, so after you've built your containers and you've been writing them, you may wanna put them somewhere. So a container registry is gonna be an external source. It's essentially like a library. There's a lot of public container registries Docker IOs one, Clay IOs another. And basically these are places where you can take pre-built containers and use them either in your containers or just use them as they are. You'll be able to find most of the Red Hat containers on Clay IOs. The one thing about using containers and public registries is you should make sure that you're using a trusted source. So basically what this means on Docker Hub, they're trying to solve this by marking trusted images with either official or verified publisher. And this helps you understand where the container is coming from. Anyone can publish anything on these public registries. All right, so we're gonna go ahead and build our first container. The first thing we're gonna do is install Podman. I've actually already done this. And then we're gonna need to write a simple application. I've already done that as well. And then we're gonna write some container files and Docker files. So Docker file, it kind of has this problem that Xerox has where it's like just the common industry term but container file and Docker file are interchangeable. And I've linked this back here. And so then after we do all that we're gonna build our container. I'm gonna just move this to the screen a little bit. So let's go ahead and take a look at my very simple application that I made for this talk. It's basically a Python application where we're just gonna be saying hello world back to the screen in the command line form. And so yeah, it's very simple. And then this is our first Docker file for this application, which is pretty simple as well. So let's talk a little bit about this Docker file because it only has two commands but the first one is a little important. So when you say from, you are creating your container from a base image, which means you're taking someone's container that they already previously built and you're starting from there. It's a good starting point essentially. And with picking your base image there's two major ways you can do it. The first way is what I've done today which is pick a programming language based image. I picked Python because my name is written in Python. Many of our languages have these images already up in the registries that I mentioned. The other way you can go is using the OS based image. And while this won't be a complete OS it will have some of the things you expect in there like DNF, YAM, app get, et cetera. And that's a good route if your container is gonna be a little bit more bloated and have things in there like for running dev stuff like Git or any other like testing tools you might have. Today we're just gonna be running Python though. So we're gonna be using Python as our base image. All right. So let's go ahead and kind of start the demo. I'm gonna bring my terminal up. So if the text is too small, let me know. And yeah, basically. But otherwise I've tried to make things big so that people can see. So I'm here in my folder with all my files and you can see all my Docker files are here. So we're gonna build our first container with Podman here. I do have all the commands I had already kind of prewritten. So I'll just be pasting them in. All right. So as we go, you can see that I'm now building the timer. The first step is to just pull it in from Python and then it's gonna copy dot dot. So what that means is that it's gonna copy all the files from my local system into the container. And you'll be able to see that when we start to run it interactively, which is our next step here. Okay. So let's talk about this command I'm running. So I have Podman run. And then I'm saying open an interactive container with a pseudo TTY. And then when I'm done, I want Podman to automatically remove my container. So it's not running in the background. And then hello CLI is the container I built, as you can see in my previous command here. I didn't explain this command the first time around. Don't worry, I will be running it more than once. So explain it on the second time. But then I'm just gonna run bash to open a bash shell in my container. All right. Now I'm inside my container. If I do an LS, I have all of my files because we did the copy dot dot. And now I actually have Python too. So if I want to run my application, all I need to do is Python. And then this is hello CLI. Hi. You can see it says hello world. It also has, it's just a simple command line argument for name. So you can do that. That's a very simple application here. All right. So we've gone ahead and we're running it interactively. So this is useful when you're developing an application, right? So I'm here in Python. I have all the things I need for my app. If I needed to make changes here, I could, if I needed to do pip install here, I could, if I do pip install here, I will want to copy that into my Docker file because when I exit the container, it will not be saved. Okay. So we'll go ahead and exit. All right. So we may want to do a little bit more than run my container interactively. So in my second Docker file, I'm going to add something called an entry point. And so let me go back here to the Docker file and kind of show you. So also I'm doing a little something a little fun. I'm adding some ASCII art in here. So if I wanted to add a library or whatever in my container, I would need to run the pip install for that. Eventually you might make a requirements text in Python because that's generally, if you have a lot of requirements, we'll do that. And then I'm going to copy everything like I did before because I'll need it in my container. And we're going to run Python and the second version of the script, which has ASCII art. So adding an entry point means that when I run the container, it will be runnable on the command line as if it was kind of compiled. So let me go ahead and demo that after we fill that and you'll be able to see the difference. Okay. So we're going to go ahead and do a little fun. All right. So I didn't explain this command the first time. So let's explain it again. So a little bit this time. Pogman build is just going to build my container, the tag. And so the first part of the tag is your image name. And the second part is the tag. And the tag is kind of more like the version of your container. I'm just calling the CLI. And then the file is the backup file. And this dot over here is actually just signifying the build path. So the build path is the folder and so that's why it's a dot. All right. Okay. So we built it again. We made a copy dot dot and now I have an entry point. Okay. All right. So this time when we run parallel CLI, it's a little bit different. Because we're not going to interactively work with the container, we're just going to try to run it as if it was a command line that was compiled. So remember the argument I give it was dash dash name. And so this is the argument of my application. So again, I'm going to run my container in an interactive way. And I want it to be removed as soon as I'm done. And then this is the name of the container. And that's the argument I'm passing into my script. And it just says hello, Lisa. So it's similar to just running this as if it was compiled. And if I were to do the help text, I could do that as well. They would call me hello from Python. All right. So the third version of the script has to ask me. All right. Let me just go ahead and look at this. All right. So yeah. Yeah. So second version, we just add the entry point so we can run it directly from the command line. And now we're going to add the ASCII art because I wanted to do something a little fun with this. All right. Go ahead and rebuild it. And this is just to simulate the changes you might make during your development, essentially. So, you know, you write some code and then you decide to, you know, test it out locally. And then maybe you need, you know, a new library and you do install that. And that's what this is trying to simulate even though it's pretty much the simplest application that I could come up with. All right. So now I have gone ahead and we've got a container that has installed the ASCII art library for Python. And we're going to run this one just like we ran the other. And so now we've got ASCII art instead of just, you know, straight up text. So with the command line, I can kind of show parts of what a container has. All right. So I can show that when we were interactively in there it has its own file system. And you can actually mount more files in there. You don't have to copy them in there. But what I also wanted to show was that your container actually has a network too. So I created another file, another version of this application, basically, that is also very, very simple, the web version, right? And so essentially we're just going to say hello world when we go to the webpage. And that's it. And this is using a library called Flask. It's a very simple web library in Python. All right. So this time we're going to build, you know, hello web instead of CLI. Hello web. And we've got to file for it with hello web. Just like before, it's going to install my library Flask in the container. So that when I run this container because my code does require this library, it will be there for it. And this one takes a little bit longer. So yeah. And we also have an entry point too. So I'm not going to be interactively working with this container like I did the first one just for the sake of time. But essentially when I run this container because it's a web application and it has its own network, we'll need to map that network from the container to my local host network so that I'll be able to read, we'll be able to interact with it. If we don't add this argument here, dash P, which maps for 5,000 to 5,000, this is the default port Flask. Even my container will run in its own private network and we won't be able to interact with it. So now I have a mini web server running in the background. So let's go there. So hello world. And this is just, as you can see, when I hit this, this is the web server responding inside the container. And if I wanted to say hello, Lisa, I could say hello, Lisa, this time before. Okay, so in general, this is kind of simulating what you would do with your containers as you're building them. All right, now I just did a bunch of stuff with containers and what that probably did and I rebuilt the same container as a bunch. And so we'll go ahead and take a look at Podman images here and then I'm going to list them. And so I don't have anything running and the image would be the stuff I built. Yeah, so I kind of wanted to show this a little bit here. As you can see, I have my localhost repository here, local hello web, which is the one we just ran and see how they, which we built a couple of things. And then we have a bunch of that say none. And so what that has happened is because every time I rebuilt this container, the previous version just kind of like becomes dangling. So if I want to remove the dangling images, I would do Podman image crew and they would ask me, do you want to remove them? Then yes, because we don't have any use for those old versions of that image. If I do image list again, they are gone. All right, so that's just a little, you know, intro is that. So let's say I've been using Podman this whole time. Let's say I don't want to rebuild my container every time I make a change in the doc file. And I want to have something a little bit more interactive on the command line. So there is another tool called buildup. This will allow us to do that. It has a lot more features than what I'm going to show today. But essentially I just want to show a different way of building essentially the same container. This one is a little more interactive directly on your command line. So if you're not quite sure where your container should look like, this might be helpful to be more interactive. So we're going to rebuild this same container. But this time we're going to do it completely in the command line. So the first command we're going to run is this one from buildup. So what I'm doing here is I'm setting a variable on my command line saying new container. And I'm running the command buildup from Python 3. This is the same image I was using before. And then I just want to echo the value that comes back. Without the echo, it doesn't actually respond. So it's kind of funny otherwise. All right, so now buildup has created this Python working container. So if I do buildup with container plus containers. So some of these commands are plural and some of them aren't. So I always create which ones are which. And you can see now we have a build a container that is called Python working container. And the next thing we did in our container was to do the copy, dot, dot. So that's what we're going to do now here. And all right, so now we've done the copy, dot, dot in the container. And the third thing we did was set an entry point. So we'll go ahead and do that. This command is a little more into it than the copy. So basically we're saying buildup config, this is a command from there. And believe this is a dash, dash, one. And the argument's supposed to be, maybe not. This is how you know it's like, see what we've got here. I do think that we'll go ahead and buildup today. I'll click here and then for entry point, just to make sure this is the demo. Okay, yeah, so it does have a dash, dash. I was correct, I'm thinking that. I'm quite sure why it's not exiting the command. All right, so when we're done using buildup, essentially the last command you've done to finish off your container is going to be build a commit and that would finalize the container like we were with Podman. So I'm going to go ahead and do that. And then we'll take a look at what we did. It seems like my commands are slightly off. But here's a demo. Apparently I attempted the demo, but I was a little too much. And so when you do build a commit, it's going to finalize the container so that you can run it in Podman. And that's essentially what's happening here. And I'm using the dash rrm because the, what would happen is it would remain, it would leave that working container there without it and then have to manually go delete it. So now let's go ahead and do the Podman run of my container again and see what we have. We'll just try to run it interactively like I was trying, not interactively, but see what happens. I'm going to find it in the path. Okay, so let's go ahead and debug it a little bit by going in there and all that's, so yeah, so it looks like when I built this the entry point command wasn't properly set up. So yeah, it just doesn't have an entry point. If I do Python, hello, I'm here. And then back to us name research before the same. All right, so campaign that doesn't go as a little too much it seems, but we'll move on because we need to. Managing your containers. So now that I've built my container several times, if I wanted to push it to a like external repository, I would need to build it with that repository in. If I do a Podman images here, I've got the local over here in my terminal. You will see a new twist. You will see that I have local hosts. So local host is my current repository of this container because it's on my local machine. But if I want to push it to an external repository like play, I would need to put that in there. And so play IO is the repository and L render bar is my user. So because I don't have permissions to just push anything to play, I have to push it to my account essentially. And we would have to then rebuild the container with Podman to do that. And then once you do that, you'll be able to push it to play. And so I'll go ahead and do that again. I'll do it with the doc file so that we have a good version of this container. All right. When you do Podman push, this will push it up to the external repository. In this case, it's play IO. So if you don't define a repository, you kind of default to local host. If you're using Docker instead of Podman, it will default to Docker IO as the external repository. Just so you know that. So there is a little bit of differences between the tools you're using. And, but I can easily do this, right? I can easily push my containers this way using Podman. But if I want to interact with my external image, let's say I just want to copy from one tag to the next and not have to rebuild it to that, I can use a program called Scoopio. And so Scoopio is just a small tool that allows you to interact with the external repositories without pulling them down. Let's go back. And so let me go ahead and demo that a little bit. So this first command, we already have an image called Scoopio like hello.cli. And I'm going to copy it to hello latest. And so the latest tag is a special name in Container World. It is the default name if you pull an image from an external repository and you do not specify a tag or version, you will get latest. So without this in my repository, people would have to specify the dot, the, you know, colon CLI, but now that I've copied one image to the other, now that they don't, they'll be able to pull that image without it. And if I want to inspect that image, you know, that remote image locally, I can use for the other inspect to do that. And this is useful when you want to take a look at some of the images out on Docker Hub or in Quay. My image is quite small and there isn't a ton of things in it. So, you know, it's, you only have two tags, CLI and the latest. And it's fairly simple. If I were to inspect like, let's say the Python image I was using, we would be scrolling for a while here in my terminal because there's a lot of tags and a lot of stuff going on in that image. All right. The last thing, and I know we're running close on time here, is Fedora Toolbox, the container playground. I'm actually not sure if I'm going to have full time to do this one. So we'll just start, so we'll just start going. For Fedora Toolbox, the container, hold on, it just basically creates this like localized container for you that you can kind of do whatever you want with. And what's kind of interesting about it and fun is you create your toolbox by doing same toolbox create and then you enter by entering it, right? So, let me see. I was playing around with this a little bit before. Ah, yeah. So, no, I'm full. So, this is what I was planning on doing. So, we'll just start it. So, Ansible. And this is going to take a little while, but I'm going to talk while it's taking them. Okay, so essentially, I don't have Ansible installed on my local machine and I didn't have it installed in this toolbox container either. After we install it here, I'll be able to use Ansible inside this container. But when I exit the container, I will not be able to use Ansible from my command line. So, really what I was just trying to show with Toolbox is you can install things and try them out without actually installing them on your local machine. And that's actually pretty neat. And the other thing about Toolbox is it's running in a container with Pogmat. So, this is going to take too long, so I'm going to stop it. But we're just opening the terminal to show you guys. Let's just do that. In the new window. And I did have Q&A, but I guess we're not going to get there. No, we got there. Okay, so now if I do Pogmat, then this is the very last thing. Oh yeah, I'm in. So, we don't have Pogmat installed in our Toolbox, apparently. So, we'll go do Pogmat. And then, list outside. And then, didn't too many things, it seems like. All right, we're out of time. We're three minutes over, so I'm going to leave it here. But yeah, that was me trying to explain all four different tools in 30 minutes. Hope I did the best I could. And I hope that you're really interested in containers as I was when I first started working with them. Because essentially, you can do a lot with them and it makes your development life a lot easier. I'm going to stop sharing now. Thank you so much, Lisa. This has been a really awesome presentation. If anyone would like to follow up with Lisa, there is a breakout room in the chat. I really wish that I could join. This is something that I think would be an awesome workshop topic. But yeah, thank you so much.