podman container - ghdrako/doc_snipets GitHub Wiki
| Feature | Podman | Docker | Description |
|---|---|---|---|
| Support all OCI and Docker images | ✔ | ✔ | Pull & run container images from container registries, ie quay.io, docker.io. |
| Launch OCI container engines | ✔ | ✔ | Launch containers runc, crun,kata, gVisor OCI Container engines |
| Simple command line interface | ✔ | ✔ | Podman and Docker share the same CLI. |
| Integration with systemd | ✔ | ✘ | Podman supports running systemd inside of the container. As well as many systemd features. |
| Fork/Exec Model | ✔ | ✘ | Container is a child of the command |
| Fully support user namespace | ✔ | ✘ | Only Podman supports running containers in separate user namespaces. |
| Client Server Model | ✔ | ✔ | Docker is a REST API daemon. Podman supports REST API via systemd socket activated service. |
| Support docker-compose | ✔ | ✔ | Compose scripts work against both REST APIs. Podman’s works in rootless mode. |
| Support docker-py | ✔ | ✔ | docker-py python bindings work against both REST APIs. Podman’s works in rootless mode. Podman also supports podman-py, for running advanced features. |
| Daemon-less | ✔ | ✘ | The Podman command runs like a traditional command line tool. While Docker requires multiple root running daemons. |
| Support Kubernetes like pods | ✔ | ✘ | Podman supports running multiple containers within the same pod. |
| Support Kubernetes yaml | ✔ | ✘ | Podman can launch containers and pods based on Kubernetes yaml. It can also generate Kuberenetes.yaml from running containers. |
| Support docker swarm | ✘ | ✔ | Podman believes the future for orchestrated multi node containers is Kubernetes and does not plan on implementing Swarm. |
| Customizable registries | ✔ | ✘ | Podman allows you to configure registries for short name expansion. Docker is hard coded to docker.io when you specify a short name. |
| Customizable defaults | ✔ | ✘ | Podman supports fully customizing all of its defaults including security, namespaces,volumes … |
| Mac OS Support | ✔ | ✔ | Podman and Docker support running containers on a Mac via a VM running linux. |
| Windows Support | ✔ | ✔ | Podman and Docker support running containers on a Windows WSL2 or a VM running linux. |
| Linux Support | ✔ | ✔ | Podman and Docker are supported on all major linux distributions. |
| Containers aren’t stopped on software upgrade. | ✔ | ✘ | Podman is not required to remain running when containers are running. Since the Docker daemon is monitoring containers, by default when it stops all containers stop. |
Podman employs a daemonless architecture. This direct management often results in Podman containers launching significantly faster, sometimes up to 50% quicker than Docker, depending on the image used.
In Docker, initiating a container means sending a request to the Docker daemon via the Docker client which subsequently launches the container, which means that the container processes are children of the Docker daemon, not the user session:
As a result, any significant event coming from a container process that's picked up by the Linux Audit system (auditd) specifies its audit user ID as unset rather than the actual ID of the user who started the respective container in the first place. This makes it extremely difficult to link malicious activity to a specific user and taints the security of the system.
With Podman, since each container is instantiated directly through a user login session, the container process data retains this information and auditd can accurately detect and list the ID of each user who started a specific container process, maintaining a clear audit trail.
The absence of a daemon in Podman leads to relies extensively on Systemd for managing container lifecycles. For instance, to correctly enforce restart policies for containers using the --restart always flag, Podman relies on a systemd service called podman-restart. This service automatically restarts all designated containers after each system reboot.
Podman exposes a handy command for generating Systemd service files from running containers. This allows you to bring your containers under systemd management to start, stop, and inspect the various services running inside of them more easily. In contrast, Docker handles all these tasks internally through the daemon itself.
Podman doesn't support Compose files out of the box, it provides a compatible alternative called Podman Compose, which typically works seamlessly with existing docker-compose.yml files.
Podman container launch flow
podman system reset
If that did not work, then use the really big hammer:
$ podman system reset
$ podman system reset ; yes, twice.
$ podman system renumber ; gets rid of ...id already in use by...