What Is Podman and How Does It Differ from Docker?

Podman is a container engine that’s compatible with the OCI Containers specification. Podman is part of RedHat Linux, but can also be installed on other distributions.

As it’s OCI-compliant, Podman can be used as a drop-in replacement for the better-known Docker runtime. Most Docker commands can be directly translated to Podman commands.

Here’s a look at how the two runtimes stack up.

What’s a Runtime?

To a lot of people, a “container” is still a “Docker container.” This isn’t an accurate representation of the current container ecosystem. Docker produces OCI container images, which can be used with other compatible runtimes. Kubernetes is one example, while Podman is another.

As a consequence, Podman and Docker have overlapping core functionality. Both produce images that the other can use to run containers. The two runtimes then add their own specialisms on top of the base containerization features.

How to Install Podman

If you’re using RedHat Linux, Podman’s in the extras repository. Use subscription-manager to add the repository. You’ll then be able to use yum to install Podman.

su -
subscription-manager repos --enable rhel-7-server-extras-beta-rpms
yum -y install podman

Most other popular Linux distributions also include Podman in their default repositories. You can apt install podman, dnf install podman or pacman -S podman to get it installed.

Working with Containers and Images

Podman’s CLI is deliberately aligned with Docker’s. That means that you can use familiar Docker commands to interact with Podman containers:

podman pull my-image:latest

podman run my-image:latest --name my-container

podman ps

podman rm my-container

Podman should be instantly familiar to Docker users. You could alias docker to podman and not notice a difference in day-to-day use. Of course, not every feature is available, though—trying to use Docker Swarm commands will throw an error, as Podman doesn’t have anything equivalent to Swarm.

What’s Different about Podman?

While it feels similar to Docker, Podman has a few distinguishing differences. First and arguably most significant is its architecture. Podman is daemon-less—there’s no long-living process managing your containers.

When you run a podman command, you’re interfacing directly with the process that’s starting your containers and fetching your images. Docker’s CLI is dependent on a connection to the Docker daemon. The CLI sends commands to the daemon, and the daemon then acts on them to create containers.

Podman’s model helps to address some of the concerns around Docker security. The lack of a daemon considerably reduces the container attack surface. If you need remote access, Podman exposes a REST API that lets you interact with all supported resource types.

Pods

Podman comes with unique features that Docker lacks entirely. In Podman, containers can form “pods” that operate together. It’s similar to the Kubernetes Pod concept.

To create a Pod, use the pod create command:

podman pod create --name my-pod

Containers are added to Pods by including the --pod flag with podman run:

podman run --pod my-pod --name image-1 my-image:latest
podman run --pod my-pod --name image-2 another-image:latest

Containers in the Pod can be managed in aggregate by using podman pod commands:

podman kill my-pod      # Kill all containers
podman restart my-pod   # Restart all containers
podman stop my-pod      # Stop all containers

The Pod concept is powerful, as it lets you manage multiple containers in aggregate. You can create app containers, such as a frontend, a backend, and a database, add them to a Pod, and manage them in unison.

The closest Docker gets to this is with Compose. Using Compose requires you to write a docker-compose.yml file and use the separate docker-compose binary. Podman lets you create Pods using one command without leaving the terminal.

When you need to export a Pod’s definition, Podman will produce a Kubernetes-compatible YAML manifest. You can take the manifest and apply it directly to a Kubernetes cluster. This narrows the gap between running a container in development and launching it onto production infrastructure.

podman generate kube

Rootless Containers

Podman supports rootless containers. This helps you lock down your security by preventing containers from running as the host’s root user. Docker now supports rootless mode as a daemon configuration option. Podman had rootless before Docker and places a greater emphasis on its use.

First, install slirp4netns:

yum install slirp4netns

Next, configure a quantity of user-scoped network namespaces:

echo "user.max_user_namespaces=28633" > /etc/sysctl.d/userns.conf
sysctl -p /etc/sysctl.d/userns.conf

This command enables the use of network namespaces without being root.

Now, you’re ready to run a rootless container! Connect to the server as an ordinary user. Start a new container with podman run. It will be created with the UID of your user account instead of root.

Besides fully rootless namespaces, podman is scoped to the current user by default. Your images and containers are stored in your user’s $HOME folder. When you run podman ps or podman images, you’ll only see your content instead of every resource on the system.

Conclusion

Podman is an OCI-compliant container runtime that works without a daemon. The CLI implements all the core Docker commands. You can easily transition to Podman or use it alongside an existing Docker installation.

Unlike Docker, Podman has first-class support for managing multiple containers. The Pod model makes it easy to work with a stack of services. You can stop, restart, and delete all the associated containers by using pod-level commands.

Podman’s also ready to help you make the jump to container orchestration services. The ability to export Kubernetes-compatible YAML makes Podman a closer match to many containerized production environments. Developers and operators can utilize the same tool to manage their containers, enabling more collaboration and flexibility.