Podman and Buildah

Kubernetes installations can be complex with multiple runtime dependencies and runtime engines. CRI-O was created to provide a lightweight runtime for Kubernetes which adds an abstraction layer between the cluster and the runtime that allows for various OCI runtime technologies. However you still have the problem of depending on daemon(s) in your cluster for builds - I.e. if you are using the cluster for builds you still need a Docker daemon.

Enter Buildah. Buildah allows you to have a Kubernetes cluster without any Docker daemon for both runtime and builds. Excellent. But what if things go wrong? What if you want to do troubleshooting or debugging of containers in your cluster? Buildah isn’t really built for that, what you need is a client tool for working with containers and the one that comes to mind is Docker CLI - but then you’re back to using the daemon.

This is where Podman steps in. Podman allows you to do all of the Docker commands without the daemon dependency. To see examples of Podman replacing the docker command, see Alessandro Arrichiello's Intro to Podman and Doug Tidwell's Podman—The next generation of Linux container tools.

With Podman you can run, build (it calls Buildah under the covers for this), modify and troubleshoot containers in your Kubernetes cluster. With the two projects together, you have a well rounded solution for your OCI container image and container needs.

Buildah and Podman are easily installable via yum install buildah podman on RHEL 7.6 and RHEL 8. They are also available on Fedora and most recent Linux platforms. On RHEL 7.6 make sure you enable the rhel-7-server-extras-rpms repo.

When to use Buildah and when to use Podman

Buildah and Podman are two complementary open-source projects that  reside on GitHub: Buildah (containers/buildah) and Podman (containers/libpod). Both Buildah and Podman are command line tools that work on OCI images and containers. The two projects are related, but differ in their specialization.

Buildah specializes in building OCI images. Buildah’s commands replicate all of the commands that are found in a Dockerfile. Buildah’s goal is also to provide a lower level coreutils interface to build container images, allowing people to build containers without requiring a Dockerfile. Buildah’s other goal is to allow you to use other scripting languages to build container images without requiring a daemon.

Podman specializes in all of the commands and functions that help you to maintain and modify those OCI container images, such as pulling and tagging. It also allows you to create, run, and maintain those containers. If you can do a command in the Docker CLI, you can do the same command in the Podman CLI. In fact you can just alias podman for docker on your machine and you can then build, create and maintain container images and containers without a daemon being present, just as you always have.

Although Podman uses Buildah’s build functionality under the covers to create a container image, the two projects have differences. The major difference between Podman and Buildah is their concept of a container. Podman allows users to create traditional containers and the intent of these containers is to be controlled through the entirety of a container life cycle (pause, checkpoint/restore, etc). While Buildah containers are really created just to allow content to be added to the container image. Each project has a separate internal representation of a container that is not shared. Because of this you cannot see Podman containers from within Buildah or vice versa. However the internal representation of a container image is the same between Buildah and Podman. Given this, any container image that has been created, pulled or modified by one can be seen and used by the other.

Some of the commands between the two projects overlap significantly but in some cases have slightly different behaviors. The following table illustrates the commands with some overlap between the projects.

Command Podman Behavior Buildah Behavior
build Calls buildah bud Provides the build-using-dockerfile (bud) command that emulates Docker’s build command.
commit Commits a Podman container into a container image. Does not work on a Buildah container. Once committed the resulting image can be used by either Podman or Buildah. Commits a Buildah container into a container image. Does not work on a Podman container. Once committed, the resulting image can be used by either Buildah or Podman.
mount Mounts a Podman container. Does not work on a Buildah container. Mounts a Buildah container. Does not work on a Podman container.
pull and push Pull or push an image from a container image registry. Functionally the same as Buildah. Pull or push an image from a container image registry. Functionally the same as Podman.
run Run a process in a new container in the same manner as docker run. Runs the container in the same way as the RUN command in a Dockerfile.
rm Removes a Podman container. Does not work on a Buildah container. Removes a Buildah container. Does not work on a Podman container.
rmi, images, tag Equivalent on both projects. Equivalent on both projects.
containers and ps ps is used to list Podman containers. The containers command does not exist. containers is used to list Buildah containers. The ps command does not exist.

A quick and easy way to summarize the difference between the two projects is the buildah run command emulates the RUN command in a Dockerfile while the podman run command emulates the docker run command in functionality.

Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container CLI commands. Together they form a strong foundation to support your OCI container image and container needs. Best yet, they are both Open-source projects and you are more than welcome to contribute to either or both projects. Hope to see you there!

An earlier version of this article appeared on the podman.io blog.

Additional Resources

Last updated: July 25, 2023