Check Out Podman, Red Hat’s daemon-less Docker Alternative
Did you know that both Red Hat Enterprise Linux 8 and CentOS 8 have dropped official support for the Docker container runtime engine? Yes, it’s true. Because of this, you have two choices:
- Constantly jump through hoops of keeping the latest version of docker-ce installed.
- Opt for a replacement.
Although you can install the community edition of the Docker engine, there’s an issue with containerd.io that will keep you on your toes. That may be okay with you, but other admins would prefer using an officially supported tool, which won’t require the constant hassle that can accompany such an installation.
That’s where Podman (formerly kpod) comes in.
Podman is a new, open source, container engine that works seamlessly with containers as well as pods (groups of containers deployed together on the same host). Podman is a unique take on the container engine, as it doesn’t actually depend on a daemon, but instead launches containers and pods as child processes. Podman is the CLI tool for interacting with libpod, a library that allows other tools to manage pods and containers. Anyone that has used the Docker CLI will feel immediately at home with Podman, so migration to from Docker to Podman should be seamless.
I want to walk you through the process of installing and using Podman. I’ll be demonstrating on CentOS 8.
What You’ll Need
Other than having a working knowledge of the Docker CLI and containers in general, you’ll need to have:
- A running instance of CentOS 8.
- A user with sudo privileges.
A Word of Warning
Podman is under heavy development. One issue you must know about is that, at the moment, certain Podman commands must be run as root. One example is when using port bindings. Say you want to bind external port 80 to internal port 8080 (with -p 80:8080). In order to do that, the container deploy command must be run with sudo.
Because Podman doesn’t use a daemon, it’s hard to say if this should be a security risk or not. However, my guess is the developers will be adding the ability to use port bindings without sudo in coming releases.
And now, on to the installation.
Installing Podman
There are two routes to take for the installation of Podman. You can either install only Podman with the command:
sudo dnf install podman -y
Or you can install the entire container tools suite (of which Podman is included) with the command:
sudo dnf install @container-tools -y
And that’s all there is to the installation of podman.
Usage
Let’s dive right into using Podman. If you’ve used the Docker CLI, much of what Podman has to offer will be quite familiar.
For example, in order to pull the official NGINX image you’d issue the command:
podman pull nginx
First, Podman will check registry.redhat.io for the latest version of the NGINX image. It won’t find it there, so it will move on to docker.io (where it will locate the image in question). Once the image has been pulled, you can make sure it’s there by viewing all of your downloaded images with the command:
podman images
You should see the newly-pulled image listed with its tag, image ID, the day it was created, and size (Figure 1).
Figure 1: The NGINX image has successfully been pulled.
To delete an image, issue the command:
podman rmi ID
Where ID is the first four or five characters of the image ID.
Now let’s deploy a simple container. We’ll pull the official Debian image and then have it use it’s internal echo command to print out the message, “Hello, New Stack!” The deployment command for this would be:
podman run --rm debian /bin/echo “Hello, New Stack.”
The official Debian image will be pulled and our message printed (Figure 2).
Figure 2: Our simple container has run.
You can now check to see what containers are running with the command:
|
1 |
podman ps -a |
Of course, the container we deployed wasn’t run in detached mode, so it ended almost as soon as it started. Let’s run a more complicated container. This time we’ll deploy a basic web server with the command:
sudo podman run -dt -p 8081:80/tcp -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \
-e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \
-e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \
registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd
Notice we had to employ sudo. This is because we are mapping external port 8081 to internal port 80. The container will deploy. You can see it running (Figure 3) with the command:
sudo podman ps -a
Figure 3: Our container is listed as running.
To stop that container, we’d issue the command:
sudo podman stop ID
Where ID is the first four or five characters of the container ID.
Finally, to remove the container, we issue the command:
sudo podman rm ID
Where ID is the first four or five characters of the container ID.
Let’s deploy a container that includes a webserver we can access. We’ll use the official NGINX image and deploy it with the command:
sudo podman run -dt --name nginx nginx
Once the container is deployed, locate it’s IP address with the command:
sudo podman inspect -f “{{.NetworkSettings.IPAddress}}” nginx
The above command should print out a 10.88.0.x IP address (Figure 4).
Figure 4: Our IP address.
Let’s access the containers bash shell with the command:
sudo podman run -it --rm nginx /bin/sh
You should now see a prompt (by way of the # character). Install the w3m text-based browser with the commands:
apt-get update
apt-get install w3m
Once w3m is installed, make sure the NGINX server is serving up content with the command:
w3m http://IP
Where IP is the IP address of the running container. You should see the NGINX greeting (Figure 5).
Figure 5: NGINX is serving up content.
And that’s the basics of installing and using Podman. There is, of course, much more to it, so we’ll dive back into more use cases later on. Happy podding!
