Hello! This is Doug Tidwell, 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 quay.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=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 that 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 in to the good stuff.
We'll take a Dockerfile and use podman to build an image with it.
This copies the source of the Colossal Cave Adventure game
into the container image, installs 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 with podman built the image.
I can run ./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 quay.io. First I'll use podman to log into my account.
Now I can push my image from localhost
into the quay.io repository.
When I push the image to quay.io, I have to specify the quay.io repo
and my username as part of the remote image name.
Now I'll go to the quay.io website,
log in to my account, and there's the image I just created.
By the way, depending on the base operating system for your image,
quay.io may run a scan for security vulnerabilities.
I built the image tagged insecure
with a modified Dockerfile that didn't install any kernel updates.
That image has some vulnerabilities, and quay.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 quay.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 daemon 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 daemon approach also stifles innovation in the container community.
If you want to change the way containers work, you need to change the docker daemon
and push those changes upstream. Without a daemon,
the container infrastructure is more modular and it's easier to make changes.
Podman's daemon-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 quay.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.