Podman vs Docker: Which is best to run containers?
Highlights
- When looking at both engines from a security perspective, Podman’s design offers a significant advantage since running as a root daemon can be a vulnerability.
- No central daemon for imagesManages Docker images via Docker daemonRoot PrivilegesContainers run as non-root usersContainers typically require root privilegesNetwork NamespacingNetwork namespaced inside RootlessKitIP address is reachable from the hostLimitations in Rootless ModeFewer limitations compared to DockerLimited storage drivers, no AppArmor, no checkpoint, etc.
- Docker operates using a client-server architecture where the Docker daemon runs as a root user.
You may have seen the name Podman come up recently in looking at Docker containers or containerized technologies. Podman is becoming more popular among those who want to run containers. What is the difference between Podman and Docker? Let’s look at Podman vs Docker as your default virtualization container engine and see the pros and cons and comparison of each one when it comes to running containerization tools.
Table of contents
- TLDR of Podman vs Docker
- 1. Docker Daemon vs Podman Daemonless Design
- 2. Interoperability with Podman vs Docker
- 3. Building Container Images
- 4. Run Containers with Podman vs Docker
- 5. Podman vs Docker extensions
- 6. Kubernetes features
- 7. Future of Podman and Docker
- Installing Podman
- Frequently Asked Questions About Podman and Docker
- Podman vs Docker: The Verdict
TLDR of Podman vs Docker
| Feature/Aspect | Podman | Docker |
|---|---|---|
| Architecture | Daemonless, runs containers directly as child processes | Client-server, uses a daemon |
| Security | Supports rootless containers natively | Supports rootless containers, but with some limitations |
| Storage Drivers | Flexible, similar to Docker | Supports overlay2, fuse-overlayfs, btrfs, vfs |
| Cgroup Support | Compatible with cgroup v2 | Requires cgroup v2 for rootless mode |
| Extensions/Tools | Supports Docker Compose; compatible with Docker tools | Offers Docker Compose, Docker Swarm |
| Kubernetes Integration | Compatible with Kubernetes; generates Kubernetes YAML | Direct integration with Kubernetes environments |
| Container Orchestration | Compatible with Kubernetes but no native tool like Swarm | Docker Swarm for container orchestration |
| Container Images | Handles Docker images; no central daemon for images | Manages Docker images via Docker daemon |
| Root Privileges | Containers run as non-root users | Containers typically require root privileges |
| Network Namespacing | Network namespaced inside RootlessKit | IP address is reachable from the host |
| Limitations in Rootless Mode | Fewer limitations compared to Docker | Limited storage drivers, no AppArmor, no checkpoint, etc. |
| SELinux Support | Requires appropriate SELinux labels for volumes | Similar SELinux considerations as Podman |
| Popularity/Community | Growing user base, less extensive than Docker | Larger community, extensive documentation |
| Use Cases | Preferred for security-focused and rootless operations | Widely used for its comprehensive tools and ecosystem |
1. Docker Daemon vs Podman Daemonless Design
Docker operates using a client-server architecture where the Docker daemon runs as a root user. This Docker daemon creates, runs, and manages Docker containers. When compared to Docker, Podman adopts a daemonless model.
This allows it to operate containers without a root daemon. When looking at both engines from a security perspective, Podman’s design offers a significant advantage since running as a root daemon can be a vulnerability. It instead runs these in user namespaces. However, Podman pods can still include the dependencies in the pods needed to run your application.
Security: Rootless Containers in Focus
It is interesting to note that Docker also supports rootless containers but with limitations. Implementing rootless containers minimizes the risk of unauthorized root-level access to the host system. Podman does not run pods using a daemon requiring root access, so it uses fewer resources. A developer who is security conscious will understand the benefits of minimizing the ways an attacker can compromise the system. Eliminating the need for root is a big win for a higher security standard.
In rootless mode, Docker has certain limitations that users should be aware of. The below is summarized from: Run the Docker daemon as a non-root user (Rootless mode) | Docker Docs.
These constraints primarily revolve around storage drivers, cgroup support, and specific feature support. In rootless mode, Docker’s storage driver support is limited to:
- overlay2: This is only supported if you’re running on a kernel version 5.11 or later, or using an Ubuntu-flavored kernel.
- fuse-overlayfs: Requires kernel version 4.18 or later, and the installation of fuse-overlayfs.
- btrfs: Supported on kernel version 4.18 or later, or if ~/.local/share/docker is mounted with the user_subvol_rm_allowed mount option.
- vfs: This driver is also supported in rootless mode.
Cgroup Support
- Cgroup functionality is available only with cgroup version 2 and when using systemd. This is particularly relevant for limiting resources in Docker containers.
Non-Supported Features in Rootless Mode
There are several features not supported in rootless mode:
- AppArmor: Security features provided by AppArmor are not available.
- Checkpoint: The ability to checkpoint and restore containers is not supported.
- Overlay Network: Overlay networks cannot be utilized in this mode.
- Exposing SCTP Ports: SCTP port exposure is not an option.
- Ping Command: To use the ping command, specific routing adjustments are necessary.
- Exposing Privileged TCP/UDP Ports: For ports under 1024, there are additional steps required for exposure.
- Internal IPAddress: The IP address shown in docker inspect is confined within RootlessKit’s network namespace, making it inaccessible from the host without specific network namespace entry commands.
- Host Network: The –net=host option is also limited to RootlessKit’s namespace.
- NFS Mounts: Using NFS mounts as the Docker data-root is incompatible with rootless mode, though this is not exclusive to the rootless operation.
Interestingly, when using Podman on a host with SELinux enabled, container processes are confined within the system_u:system_r:container_t:s0 SE Linux domain standard. For containers to access volumes, these volumes must have suitable SELinux labels. With this point, containers will be unable to access these volumes if the labels are not correctly set.
2. Interoperability with Podman vs Docker
A key aspect of container management is orchestrating multi-container applications. Docker Compose, a tool for defining and running multi-container Docker applications, is widely used. Podman supports Docker Compose code syntax and Docker commands in the CLI.
Managing Containers with Docker Swarm and Podman
Docker Swarm, Docker’s native clustering and scheduling tool, is not supported by Podman to manage containers across multiple hosts. Podman is compatible with Kubernetes and even Kubernetes manifest files to run applications. Kubernetes is arguably the more popular container orchestration tool. Podman’s support of Kubernetes (Minikube integration and others) as well as the ability to create “pods” of containers that closely aligns with Kubernetes is a great benefit.
3. Building Container Images
Both Docker and Podman deal with container images. Building your own container images allows you to customize containers for your needs. Then, you can create containers using the custom image. Docker images are stored in Docker Hub by default but can work with other registries.
When comparing Podman, it can work with images from any container registry. Building and managing these images are similar but differ subtly in syntax and workflow.
Container Creation and Image Building
Docker uses Dockerfiles to build a container image. Podman uses Containerfiles, as they call them. The syntax for the Containerfile is exactly the same internally in the file. The process involves specifying the base image, adding necessary files, and defining commands.
Building containers with either tool is straightforward, but Podman offers the added benefit of doing this without needing a daemon.
4. Run Containers with Podman vs Docker
Running containers effectively is a basic requirement for either Podman or Docker in development and production environments. The Docker daemon runs Docker containers, while Podman runs containers directly as child processes of the Podman process.
One of the smart things the developers of Podman have done is made the syntax basically the same as Docker, so you have drop-in replacements for the commands used in Docker for Podman.
Using standard commands like podman ps, podman run, and podman inspect, do what you would expect them to do as an equivalent for Docker. Below we are running a new Podman pod using the example podman hello container.
Root Privileges and User Permissions
One of the key differences lies in how Docker and Podman handle user permissions. Docker’s model often requires root privileges, which can pose security risks. Podman addresses this by enabling containers to run as non-root users, thus providing an added layer of security.
5. Podman vs Docker extensions
Docker and Podman both have extensions. Docker Desktop contains many extensions as part of the Docker Desktop tool. This allows extending Docker with new and cool functionality from third-party solutions. You can install tools like Headlamp and Kubescape to name a couple.
The Docker extensions catalog is extensive and contains many extensions you can add to your Docker Desktop installation.
Podman on the other hand also has extensions that allow extending its functionality. Unlike Docker, some of the core functionality you can add with extensions allows Podman to run other types of containers like Docker container runtime, Minikube, Openshift and others from the Podman interface.
As you would expect, the extensions catalog for Podman is a lot smaller than the one with Docker. Docker has been around “forever” in computer years compared to Podman, so it is expected to see more extensions for Docker.
6. Kubernetes features
Both Docker and Podman have strong Kubernetes features built into their interfaces. With Docker, you can run Kubernetes mode natively as part of Docker Desktop. You can reset the cluster and manage other aspects of the configuration from the Docker Desktop program.
Podman also has extensions like Minikube, Kind, and others you can take advantage of. Also, Podman, by its nature, can run “pods”, hence the name. With Podman, you can group containers together into pods that share the same network connection, etc, making these more efficient. Podman I think gives you the Kubernetes feel more than Docker.
7. Future of Podman and Docker
As containerization continues to evolve, Docker and Podman are two of the most popular. Docker is the 800 lb gorilla in the room with an extensive community and comprehensive suite of tools in the ecosystem to build and run software in your environment. This makes it a popular choice for app deployment.
However, Podman’s approach to security and daemonless architecture is gaining ground as security continues to be at the forefront of everyone’s mind. Since the Docker documentation can be easily carried over to Podman projects, for this reason, the barrier to entry is low.
Installing Podman
Since most are probably familiar with installing and configuring Docker Desktop, let’s look at how to install the Podman Desktop product, which is the equivalent solution in the Podman world to the Docker GUI tool for local development.
You can download the Podman Desktop binary from the official Podman download page here: https://podman-desktop.io/downloads.
Also, for the Windows operating system you can now use the winget tool to install Podman Desktop. Use the following winget command:winget install -e –id RedHat.Podman-Desktop
Initial configuration of Podman desktop
After you install Podman desktop, there is some initial configuration you will need to perform.
You can click the Set up button to begin the prerequisites check and configuration of Podman.
Podman desktop requires the underlying Podman to be installed. If it doesn’t find it, it will prompt you to install it from the Podman Desktop GUI. Click Next.
Overcoming an error when installing Podman from Podman Desktop
One of the interesting things I ran into was the prerequisites check saw WSL2 but had an issue with the WSL check. This is noted in the following GitHub bug for the project: Podman Desktop setup failed on requirement check: WSL version should be >= 1.2.5. · Issue #4982 · containers/podman-desktop · GitHub. The workaround is to install Podman manually from the official GitHub releases page here: Releases · containers/podman · GitHub.
After manually downloading the Podman installer, I step through the installation.
Podman is now successfully installed.
Initializing and starting Podman
Now, we can run the initialize and start from the Podman Desktop.
Podman is now running. It will display the featured extensions for Podman.
Frequently Asked Questions About Podman and Docker
While Docker utilizes Docker Compose for orchestrating multi-container environments, Podman can also run Compose files despite its daemonless architecture. This capability means Podman can handle similar tasks without the Docker daemon, offering an alternative approach to managing multi-container setups.
Podman is becoming more popular as a Docker alternative. This is especially true if ones are prioritizing security, due to its daemonless setup daemonless setup. Podman also has native compatibility with Docker tools, and it has native support for Kubernetes performance and scalability. All of these add up to Podman gaining traction.
In many scenarios, Docker and Podman can be used interchangeably, especially since Podman supports Docker Compose and Docker images. However, differences in command syntax and security features mean that while they can often achieve the same goals, the approach and execution may vary.
Podman’s most notable security advantage is its support for rootless containers, reducing the risk associated with granting root privileges. This feature, coupled with its daemonless architecture, minimizes potential attack vectors, making Podman a more secure option in certain environments.
Both Docker and Podman work with OCI (Open Container Initiative) containers and can manage Docker images. However, Podman’s approach to image management aligns with its daemonless structure, allowing for direct interaction with container images without a central daemon.
While Podman does not natively support Docker Swarm, it provides compatibility through other container orchestration tools like Kubernetes. It enables users to manage container clusters effectively with the modern K8s orchestration platform.
Docker is hard to beat for new users since it has been around so long and there is a lot of content you can consume to learn Docker. However, Podman uses many of the same Docker command line commands, so it is almost a drop-in replacement once ones learn the basics of Docker.
Podman is often preferred in environments where security is the priority. Its daemonless and rootless architecture makes it more efficient and more secure by default.
Podman vs Docker: The Verdict
Podman is a great alternative to Docker, especially when security is front and center. While Docker can also be secure, Podman makes this more of a default with the rootless nature of the solution and the lack of a daemon being required. This helps to minimize the attack surface, as we have discussed in this article.
All in all though, Docker is still hard to beat for development, running services, and doing all the things we know and love to do with it. The maturity and wide scope of Docker are hard to beat when you are looking for a way to have the easiest approach possible and use a solution that has maturity behind it. Podman has definitely matured a lot over the past couple of years. Ultimately, it comes down to your priorities and what you are looking to do.
