While docker has undoubtedly revolutionized the way we develop, deploy, and run applications, it's worth exploring what sets Podman (Pod Manager) apart and why you may want to start using it instead.
In this article, we'll dive into the core features of podman assuming that everyone is already familiar with Docker.
Let's Start!
What is Podman?
In simple words, Podman is an open-source container and pod manager.
Similar to docker, it allows you to create, start, stop, and delete OCI containers, as well as manage container images but also supports pods as part of its feature set wich means you can create and manage pods just like you would with Kubernetes.
But wait OCI Containers ?
OCI (Open Container Initiative) : is an industry-standard organization that aims to create set of rules (specifications and standards) that ensure containers work consistently across different platforms.
So what does this mean ?
It means that Podman's images/containers are fully compatible with docker's or any containerization technology that relies on an OCI compliant container runtime.
Great so now we know that podman is fully compatible with docker but wait it's more interesting.
Most docker users can simply alias Docker to Podman (alias docker=podman) without any problems.
This means that all docker's commands stay the same with the exception of docker swarm.
Your probably wondering what does Podman bring to the table.
Let's dive deeper!
Architecture
Can you spot the difference ?
Podman's architecture is daemonless.
Wow what is that and why are we trying to get rid of the good old docker daemon ?
Daemons are processes that run in the background of the system, they typically run continuously in the background, waiting for certain events or requests to occur.
Back to containers, Think of the docker daemon as the intermediary communicating between the user and the container itself.
Problems ?
There are few problems with using a daemon to manage containers :
Single point of failure
Once the daemon crashes, all containers do.
Requires root privileges
This makes the docker daemon an ideal target for hackers who want to gain control of your containers and infiltrate the host system.
Podman addresses the mentioned challenges by directly interacting with container registries, containers, and image storage without the need for a daemon hence the daemonless architecture.
By going rootless (not requiring root privileges), users can create, run, and manage containers without requiring processes with admin privileges reducing the security risks
The buildah utility takes the place of docker build as a container image building tool. Similarly, skopeo replaces docker push and enables the movement of container images between registries. These tools provide efficient and direct interactions with the necessary components, eliminating the need for a separate daemon in the process.
Should I re-write every dockerfile and docker-compose file to be able to use podman with my existing projects ?
Answer : Absolutley Not
Podman aims to provide a familiar developer experience by offering compatibility with docker's containerfile syntax.
Additionally, Podman introduces a similar tool called pod compose as an alternative to docker compose.
Pod compose utilizes the same syntax allowing you to define and manage multi-container applications using the same approach or even using existing "docker-compose.yml" files.
As for Docker desktop, Podman also comes with Podman desktop offering enhanced features that make it more powerful and streamlined. It offers compatibility with Docker and Kubernetes, amplifying its capabilities and delivering a smoother experience.
You can find Podman's installation guide and documentation in their official website podman.io
Conclusion
Given Podman's daemonless architecture, comparable developer experience to Docker, and the fact that both are open-source projects with thriving communities, there are no significant advantages to sticking with Docker over Podman.
Top comments (19)
I'm confused by the statement "Podman's architecture is daemonless." Followed by "Podman addresses the mentioned challenges by directly interacting with container registries, containers, and image storage without the need for a daemon hence the daemonless architecture."
It really sounds like Podman is a daemon. Is it daemonless in the same senses as no-code (there is code, just not written by you) or serverless (there are servers, you just have no control over them)? So there is a daemon it just doesn't run as root?
When you say Podman directly interacts with containers, how is it not a daemon?
A daemon typically runs as a long-lived background process, starting at system boot and continuing to run indefinitely.
the Podman process in other hand is invoked when you execute a specific command . Once the command is completed the Podman process terminates.
Also a daemon don't require a user session or a user interacting with them while podman requires to be invoked by a user in the terminal for it to run after getting the job done it terminates.
Hope I answered your question
Yes. Thank you.
A container is actually a "containerized process" (within a user namespace, network namespace, chroot, mount namespace, cgroup, etc.) Podman arranges for starting that containerized process from an OCI image. It does not need a daemon for that, at most does it need a process that runs for as long as the containerized process (which could be long-running, or just a few milliseconds/seconds long)
Docker has a daemon that receives commands from a client, and that daemon will start/stop containers. It has to be running early and stop late to be able to receive the commands you'll send it (most likely through the Docker CLI, or Docker Desktop)
The rootless mode of Podman is the main reason why I started adopting it as a primary builder in my open source project (Diginext), definitely worth it.
The "single point of failure" argument is not true, it was in the past but since a few years ago the containers launched by docker are not child processes, and will continue to run even if the docker deamon stops
Well since most of my docker containers run in my Synology NAS, is there an easy way for Podman on Synology?
if your os is based on linux , depending on the distro, they have official repos for each.
while im not familiar with Synology NAS if you have a terminal and a package manager like apt or dnf installed on it you good to go
Right now, I'm trying to pick apart how podman is handling a bridge network, and I can't find the bridge device even though there very clearly is one because several pods have distinct IPs in a /24 and they can talk to each other. Somehow, this is being managed, and it's not by the daemon that creates a userspace fake NAT connection (slirp4netns).
So, podman does have daemons that get launched as needed as ordinary user processes (not root processes) that manage certain resources.
And I'm being very frustrated by my inability to find the network namespace the bridge is living in, which appears to not be managed by any daemon at all. :-(
I’m confused why this article essentially concludes with, “Don’t use this”??
The “absolutely not” answer is never explained nor justified, so I don’t understand the point of this article if you believe no one should replace Docker with this.
Nice, what is the alternative to kubernetes then ?
There are couple alternatives
the ones i know are Aws Elastic Container Service and docker swarm (deprecated)
But kubernetes is the most widely adopted container orchestration platform with a large community
it's the best out there
I think that the daemonless architecture of podman is the reason for managing containers without kernel namespaces like docker, is that true ?
When it comes to containerization they both utilize kernel features such as namespaces, cgroups ...
daemonless only means that podman don't rely on a central daemon process
Does podman takes images from the same docker registry or does it have some own registry , can it pull images from third party registries
Podman does not have a "default registry" configured by default, so you have (by default) to used qualified names (i.e.
docker.io/…for the Docker Hub)But it can pull from any OCI-compatible registry: Docker Hub, Quay.io, GitHub, GCR, etc.
I don't get it. If a container crashed who is going to restart it?