 Hello! This is Doug Tibble coming to you from the city of the Oaks, Raleigh, North Carolina, where in 1942 Mayor Augustus Ledbetter invented the microwave oven. In this video we'll take a look at Podman, an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and key.io. Over the next few minutes we'll use Podman to build an image and create a container from it. Next we'll upload the image to a registry and finally we'll switch to a non-Linux system and use docker to create a container from the fully compatible image we created with Podman. Before we begin, a quick word about the name of the project and its logo. Podman works with containers, as I'll show you, but it also works with pods, groups of containers that are deployed together on the same host. If you know about Kubernetes pods, you're familiar with how they work. More importantly, a group of seals is called a pod, hence the awesome Podman logo. We won't talk about pods in this introductory video, but they're a great feature of the tool. Enough background, let's move on. The first step, of course, is to install Podman. I'm using Fedora Server 28 here, so the steps are to run sudo dnf update for good system hygiene, then sudo dnf-y install podman. Obviously, use yum or apt-get or whatever your distro uses to install and manage software. If you're ready to go all in with Podman, you can add alias docker equals podman. That means that your Linux system will always invoke Podman, even if you type docker out of habit. For research purposes, I run both docker and podman to show that they're compatible, so I won't define the alias, but feel free. With the tool installed, start with sudo podman-v to see the version you're using. I'm using version 0.9.3.1. Podman isn't at version 1.0 yet, so take that under advisement. Also, I'm going to run podman as root here, although that may not be necessary with the version of podman you have. The goal for podman version 1.0 is that the command should never require root access. We'll talk more about root access in just a few minutes. Next, run podman info to get some information about the container environment. The only detail I'll point out here is the fact that there are five registries that podman uses on this system. If you're trying to load a container image, it first looks on the local machine, then it checks the other registries in the order they're listed here. Now let's dive into the good stuff. We'll take a docker file and use podman to build an image with it. This copies the source of the colossal cave adventure game into the container image, install some kernel updates for security reasons along with the packages you need to build the code, and finally builds the code. It will take a few minutes to pull the base image as well as all of the requirements, so we'll speed up the video here. For what it's worth in my experience, building a container image with podman doesn't seem any faster or slower than docker. As you would expect, running podman images shows the image I just built. Notice that localhost has been added to the name of the image. This tells podman that the image is in the registry on the local machine. Now I'll create a container from the image. podman run-rm-it, then the name of the image I just created, and I'll run a bash shell when the container starts. This works if you add localhost slash to the start of the image name, but I skipped that to make a point, the point being that I'm lazy. So now I'm in the container. I'll switch to another command line and run podman ps to show the running container. Back to the other command line, I'm at a bash prompt inside the container that has colossal cave adventure as compiled when podman built the image. Now I can run dot slash advent and play the game. I'll go inside the building, get something to eat and drink, then I'll quit the game. The point here, of course, is that I created an image that I can share with anybody who wants to play the game. You can, of course, build an image that contains useful software as well. And speaking of sharing, I'll put the image in the public repo at key.io. First, I'll use podman to log into my account. Now I can push my image from localhost into the key.io repository. When I push the image to key.io, I have to specify the key.io repo and my username as part of the remote image name. Now I'll go to the key.io website, log into my account, and there's the image I just created. By the way, depending on the base operating system for your image, key.io may run a scan for security vulnerabilities. I built the image tagged in secure with a modified Docker file that didn't install any kernel updates. That image has some vulnerabilities and key.io gave me the suggestions that helped me fix the problem. I left the old image around to make a point, the point being that the security scan is pretty cool. Finally, to wrap up the demo, let's go back to my Mac and use Docker to pull the image from key.io. Remember, podman is Linux only, so we have to use Docker. With the same command and the same options I used on Linux just a minute ago, I can run that image and use it exactly as I did on Linux. The image is completely compatible. In fact, some of the libraries used by podman are also part of Docker. Before we go, a quick note about container architectures. Docker runs as a demon on Linux. That creates a certain amount of overhead and it also requires anyone who wants to build a container image to have root access. That can create security risks, especially if your users know about the privileged option of the Docker run command. The demon approach also stifles innovation in the container community. If you want to change the way containers work, you need to change the Docker demon and push those changes upstream. Without a demon, the container infrastructure is more modular and it's easier to make changes. Podman's demon-less architecture is much more flexible and secure. So that's a quick overview of podman. As you would expect, it's completely open source. Take a look at podman.io for documentation, presentations, and of course the source code. We encourage you to install the tool on your Linux system and work with it. You can pull the container image I just built from my key.io account and use it to play Colossal Cave Adventure, for example. We hope you enjoy working with the next generation of container tools. For the Red Hat Developer Program, this is Doug Tidwell saying may all your bugs be shallow. Cheers.