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
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.
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 --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
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.
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
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
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.
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.