Red Hat has now gone a step further and reportedly removed official support for the Docker package for Red Hat Enterprise Linux v8.0. It has been said that keeping up with feature and security updates for the Community Edition of Docker was a driver in the decision to go it alone. Indeed, Red Hat has created even a podman-docker RPM package that links Docker to Podman for people who are comfortable using Docker commands (access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index). Maintaining autonomy and avoiding reliance on a third party were also apparently factors; Red Hat customers made it clear that their preference was for the container runtime to be either integral to the operating system or integral with OpenShift.
Another valuable Podman feature is its ability to run daemonless. Consider that for a moment. Rather than running an application all year round on critical systems (which in itself represents a superuser-run attack vector), it is possible to use the container runtime only when it is needed. It is a clever and welcome addition to Podman's offering. For backward compatibility, the venerable Podman happily runs container images compliant with the Open Container Initiative (OCI; see www.opencontainers.org), and it is compatible with Docker images, too.
And, with Red Hat Enterprise Linux v8.0 there has been a clearer focus on helping users move away from Docker in Kubernetes to use CRI-O (cri-o.io), which is now one of the preferred container runtimes in Kubernetes thanks to its lightweight and more secure nature. An interesting Red Hat blog entry can be found at developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml.
It is safe to say that Podman handles the running of containers differently than Docker. Instead of using containerd (the popular runtime) and containerd-shim (the runtime used for daemonless containers that acts a type of parent that shepherds a container's child processes), it uses a conmon process for every running container. According to Red Hat (as described at developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods/), conmon is a small program written in the C language that monitors the parent process of each container. If the container stops or fails, then it dutifully passes on the exit code. Additionally, conmon is responsible for allowing the tty to be attached to a container, and conmon also provides the daemonless functionality that Podman achieves. It manages this by continuing to run, even when Podman has stopped, which cleverly keeps a detached container alive in the background. There is more information on how that works here: developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods.
Setting Up Podman
We are going to use the Ubuntu 20.04 Long Term Support (LTS) release to run Podman as rootless. This is because according to the docs (github.com/containers/podman/blob/master/docs/tutorials/rootless_tutorial.md), if you read this important note about the fuse-overlayfs package, you need at least version 0.7.6: “This especially needs to be checked on Ubuntu distributions as fuse-overlayfs is not generally installed by default and the 0.7.6 version is not available natively on Ubuntu releases prior to 20.04.”
To install Podman, notably this time as the root user, we will first add a source to the apt package manager this way as one long command which should go on one line:
$ echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu _20.04/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
If you're not using Ubuntu 20.04, then alter the 20.04 string in the previous command. If you want to try other Linux distributions, then you can use this page: podman.io/getting-started/installation.
Next, we need to add the repository's key to our keyring as a trusted source (changing 20.04 if required again) which is one line command:
$ curl -L
https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_18.04/Release.key | sudo apt-key add -
A successful response is OK.
Now, refresh your packages and upgrade any that require upgrading:
$ sudo apt-get update; sudo apt-get upgrade -y
We should now be able to install Podman as follows:
$ apt-get -y install podman
Note the output from that command, shown here, so you can get an idea of the underlying components used:
Recommended packages: crun slirp4netns varlink The following NEW packages will be installed catatonit conmon containernetworking-plugins containers-common containers-golang containers-image crun libyajl2 podman podman-plugins runc slirp4netns uidmap varlink
Check that Podman has installed correctly:
$ podman -v podman version 2.0.4
We need to check our UID and GID mapping settings files to run rootless containers next. Run these commands and delete any entries (only on a development system!) to check that they are empty:
$ cat /etc/subuid $ cat /etc/subgid
This is the point where you might want to create a specific user for running rootless containers. Simply use the adduser command with a username of your choice, such as poduser, and follow the prompts:
$ sudo adduser poduser
We will stick with user chris, however, for continuity.
Now we want to populate the subuid and subgid files in the /etc directory. Use this command to set the ranges of UIDs and GIDS that you want to use, changing the name of the user at the end to suit your requirements:
$ sudo usermod --add-subuids 200000-201000 --add-subgids 200000-201000 chris
Without any more tweaking or fiddling, we are ready to run Podman in rootless mode. It has been a particularly painless process so far.
First, however, remember that Podman is not running as a daemon. Take a look with this command (to be really sure, run this as the root user to see any hidden processes in the process table, and not only as the chris user):
$ ps -ef | grep podman
The only output you should see is the grep command that you've just run. But, if we run this Podman command, we should see a service ready and waiting:
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
It looks remarkably familiar, just as Docker Engine would output. Using the chris user we can start up a container using another familiar command for Apache:
$ podman run -it -p 8000:80 httpd:latest
We have not added the -d switch to that command, and Listing 2.4 shows the STDOUT logging (output straight to the terminal).
Listing 2.4: Podman Running Rootless with Little Effort
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.2.100. Set the 'ServerName' directive globally to suppress this message AH00558: httpd: Could not reliably
