Podman in Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more

Q: How deeply does Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more cover Podman?

Explains process ancestry, namespaces, image formats, transports, registries, and command workflows; defers deeper security and service details to later treatment.

Podman is a daemonless container engine that runs containers and builds images, including under an unprivileged user account.

Podman is a daemonless container engine for developing, managing, and running OCI containers on Linux. It runs rootful or rootless, supports individual containers and pods, and provides a Docker-compatible command-line interface. section 1.1 section 1.0

Podman follows a fork/exec design: the user invokes Podman, Podman launches an OCI runtime, and that runtime starts the container as a child process. No continuously running, root-owned daemon is required; containers continue running after the Podman command exits. section 1.3.3 section 1.3.4

Figure 1.9 Podman fork/exec architecture. The user launches Podman, which executes the OCI runtime, which then launches the container. The container is a direct descendant of Podman.

The process-flow diagram contrasts Podman’s direct parent-child relationship with Docker’s client, daemon, and containerd chain. section 1.3.3

Podman’s operational model combines familiar workflows with Linux-native isolation and configuration:

Runs containers under an unprivileged account through user namespaces; processes remain owned by the user and retain no capabilities beyond a normal user. section 1.3.2 section 1.3.12
Uses Linux namespaces, cgroups, storage, and an OCI runtime such as runc, crun, Kata, or gVisor to construct and launch containers. section 1.2.3 section 1.1
Manages pods containing one or more containers that share storage and network resources, while remaining primarily a single-host engine rather than an orchestrator. section 1.3.8 section 1.4
Accepts registry, OCI, directory, Docker archive, OCI archive, and Docker-daemon image transports, with configurable registries, mirrors, blocking, and signature policies. section 1.3.10 section 1.3.9

Run and publish a web service

Run an interactive disposable shell with `podman run -ti --rm registry.access.redhat.com/ubi8/httpd-24 bash`. For a background service, use `podman run -d -p 8080:8080 --name myapp registry.access.redhat.com/ubi8/httpd-24`; inspect its binding with `podman port myapp` and stop it with `podman stop myapp`. section 2.1.1 section 2.1.2 section 2.1.3

Table 1.2 Podman and Docker feature comparison (view table figure)

Feature	Podman	Docker	Description
Supports all OCI and Docker images	✔	✔	Pulls and runs container images from container registries (i.e., quay.io and docker.io). See chapter 2.
Launches OCI container engines	✔	✔	Launches `runc`, `crun`, Kata, gVisor, and OCI container engines. See appendix B.
Simple command-line interface	✔	✔	Podman and Docker share the same CLI. See chapter 2.
Integration with systemd	✔	✘	Podman supports running systemd inside the container as well as many systemd features. See chapter 7.
Fork/exec model	✔	✘	The container is a child of the command.
Fully supports user namespace	✔	✘	Only Podman supports running containers in separate user namespaces. See chapter 6.
Client-server model	✔	✔	Docker is a REST API daemon. Podman supports REST APIs via a systemd socket-activated service. See chapter 9.
Supports `docker-compose`	✔	✔	Compose scripts work against both REST APIs. Podman works in rootless mode. See chapter 9.
Supports docker-py	✔	✔	Docker-py Python bindings work against both REST APIs. Podman works in rootless mode. Podman also supports podman-py for running advanced features. See chapter 9.
Daemonless	✔	✘	The Podman command runs like a traditional command-line tool, while Docker requires multiple root-running daemons.
Supports Kubernetes-like pods	✔	✘	Podman supports running multiple containers within the same pod. See chapter 4.
Supports Kubernetes YAML	✔	✘	Podman can launch containers and pods based on Kubernetes YAML. It can also generate Kubernetes YAML from running containers. See chapter 8.
Supports Docker Swarm	✘	✔	Podman believes the future for orchestrated multinode containers is Kubernetes and does not plan on implementing Swarm.
Customizable registries	✔	✘	Podman allows you to configure registries for short-name expansion. Docker is hardcoded to docker.io when you specify a short name. See chapter 5.
Customizable defaults	✔	✘	Podman supports fully customizing all of its defaults, including security, namespaces, and volumes. See chapter 5.
macOS support	✔	✔	Podman and Docker support running containers on a Mac via a VM running Linux. See appendix E.
Windows support	✔	✔	Podman and Docker support running containers on a Windows WSL 2 or a VM running Linux. See appendix F.
Linux support	✔	✔	Podman and Docker are supported on all major Linux distributions. See appendix C.
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.

The comparison table highlights Podman’s Docker-compatible CLI alongside rootless namespaces, fork/exec, systemd integration, and REST API support. section 1.3.1

How Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more covers it

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more. The section links point to the parts of the book it draws on.