What does section 1.1, About all these terms, cover?

This section defines the main container-tool categories and positions Podman as a container engine for developing and running containers and pods. Distinguish container orchestrators, container engines, and OCI container runtimes by what each does and where it operates. Describe Podman as a daemonless container engine that develops, manages, and runs OCI containers on Linux, as root or rootless, with a command line similar to Docker’s. Explain that Podman runs individual containers as well as pods, and that a pod contains one or more containers sharing namespaces and cgroups.

What does section 1.2, A brief overview of containers, cover?

The section defines Linux containers as isolated groups of processes and introduces the resource controls, security constraints, and namespaces that provide that isolation. Explain that a container is a group of Linux processes isolated from other processes, so applications can run without interfering with one another or conflicting over versions of shared libraries. Describe how cgroups organize processes into groups whose resource use can be limited and monitored, preventing one group from consuming so much memory, CPU, or network capacity that others cannot make progress. Explain that containers use multiple Linux security mechanisms to restrict what their processes can do and help prevent privilege escalation or attacks on the host and other containers. Give examples of the restrictions described in the section.

What does section 1.2.1, Container images: A new way to ship software, cover?

This section explains how container images make software delivery more consistent and why containers require less operating-system management than VMs. Explain how host-installed packages can cause applications to fail across machines with different dependencies, and how container images address this by shipping the application with its libraries, executables, and configuration files. Distinguish running isolated applications in VMs from running them in containers: each VM brings an operating system to manage, while containerized applications use their required user spaces and share the host kernel.

What does section 1.2.2, Container images lead to microservices, cover?

The section explains how container images isolate application dependencies and make it practical to compose reusable microservices. Explain how packaging an application with its required libraries in a container image lets applications with conflicting requirements run on the same host, even when they come from different distributions. Describe how packaging one service or application per container image allows multiple instances and lets separate services, such as a web frontend, load balancer, and database, connect over the network instead of forming one monolithic application. Explain how this supports experimenting with combinations and sharing or reusing software.

What does section 1.2.3, Container image format, cover?

This section explains what a container image contains and how Podman turns a stored image into a running container. Describe the image’s rootfs directory tree, the JSON file that describes how to run its contents, and the manifest list that links images for different architectures. Explain that a manifest list lets users request an image by the same name on different machine architectures, while Podman selects the image matching the machine’s default architecture. Trace how an engine copies a tar-packed image from a registry, unpacks it, combines image JSON settings with engine defaults and user input into an OCI runtime specification JSON file, and hands that file to a container runtime to launch the primary process.

What does section 1.2.4, Container standards, cover?

This section explains how OCI standards define image and runtime formats so container engines such as Podman and Docker can use the same images. Distinguish the OCI Image Format, which standardizes container images and their JSON file, from the OCI Runtime Specification, which standardizes the container JSON file used by OCI runtimes. Explain that following OCI standards lets Podman and other container engines work with images in container registries and run them the same way as other engines, including Docker.

What does section 1.3, Why use Podman when you have Docker?, cover?

Introduces the case for Podman alongside Docker: open-source choice and a design the author argues improves container security and use. Explain why the existence of Docker does not make Podman unnecessary: open source benefits from having alternatives, just as operating systems offer multiple editors, shells, filesystems, and browsers. Describe the author's claim that Podman's design is fundamentally better than Docker's and offers features that advance container security and use, without attributing specific features to this introduction.

What does section 1.3.1, Why have only one way to run containers?, cover?

This subsection explains why Podman’s later arrival gave its developers a chance to rethink Docker’s design and introduce new features. Explain how being developed after Docker let Podman’s developers approach container design differently, while drawing on open-source code, standards such as the Open Container Initiative, and community work on new features.

What does section 1.3.2, Rootless containers, cover?

This section explains why Podman’s rootless mode lets ordinary users run containers without host-root privileges and contrasts it with the risks of conventional Docker access. Explain that Podman lets users run containers and build images with a standard login account, without granting them root access. Distinguish this from conventional Docker access while acknowledging that Docker can also run rootless. Trace how access to the Docker socket through the Docker user group can lead to host-root access: run a privileged container with the host filesystem mounted, then chroot into that mount. Contrast what happens after a container escape or removal: Podman processes retain the user’s UID and ordinary-user privileges, with host actions recorded in audit logs, whereas the described Docker attack can remove the container and, with default file logging, erase records of its launch.

What does section 1.3.3, Fork/exec model, cover?

This section contrasts Docker’s daemon-based path to a container with Podman’s Unix-style fork/exec path and explains how Podman can share storage without a coordinating daemon. Trace how the Docker client contacts the Docker daemon, which works through containerd and an OCI runtime to start the container’s first process. Explain that the daemons relay the container’s input and output, adding complexity and potential failure points. Explain how Podman follows the Unix fork/exec model: it pulls images, configures storage, and launches an OCI runtime that starts the container in its process lineage. Describe how filesystem and IPC facilities, including filesystem locking, let multiple container engines share storage without a daemon coordinating them.

What does section 1.3.4, Podman is daemonless, cover?

This section contrasts Docker’s continuously running daemons with Podman’s daemonless way of launching containers and explains why the difference matters on resource-limited machines. Explain that Podman can run the same container images and use the same container runtimes as Docker without keeping multiple daemons running as root. Contrast what remains running after each tool launches a containerized web service.

What does section 1.3.5, User-friendly command line, cover?

This section explains why Podman follows Docker’s command-line interface and how users can run familiar Docker commands through Podman. Explain why Podman adopted Docker’s command-line interface: Docker was dominant, and container examples commonly used its commands. Describe compatibility as an aim rather than an absolute guarantee, noting that Podman does not support some commands such as Docker Swarm. Describe how aliasing docker to podman lets a user type Docker commands while Podman runs them, and how the podman-docker package provides this alias and links Docker man-page requests to Podman pages.

Chapter 1: Podman: A next-generation container engine

What you will learn in chapter 1 of Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more

This introduction presents Podman as a Docker-familiar container engine with stronger default security and previews the ways the book will use it.

After this chapter you will be able to

Non-root container management. Explain that Podman generally works like Docker but can manage containers without root access or privileges, which the introduction identifies as a major security advantage.
Container tool categories. Distinguish container orchestrators, container engines, and OCI container runtimes by what each does and where it operates.
Podman engine identity. Describe Podman as a daemonless container engine that develops, manages, and runs OCI containers on Linux, as root or rootless, with a command line similar to Docker’s.
Container process isolation. Explain that a container is a group of Linux processes isolated from other processes, so applications can run without interfering with one another or conflicting over versions of shared libraries.
Cgroup resource constraints. Describe how cgroups organize processes into groups whose resource use can be limited and monitored, preventing one group from consuming so much memory, CPU, or network capacity that others cannot make progress.
Kernel security constraints. Explain that containers use multiple Linux security mechanisms to restrict what their processes can do and help prevent privilege escalation or attacks on the host and other containers. Give examples of the restrictions described in the section.
Namespace resource views. Describe how Linux namespaces give groups of processes different views of system resources, making a container feel like its own environment without the overhead of a virtual machine. Illustrate this with network, mount, or PID namespaces.
Image packaging and consistency. Explain how host-installed packages can cause applications to fail across machines with different dependencies, and how container images address this by shipping the application with its libraries, executables, and configuration files.
Container and VM overhead. Distinguish running isolated applications in VMs from running them in containers: each VM brings an operating system to manage, while containerized applications use their required user spaces and share the host kernel.
Isolation of application dependencies. Explain how packaging an application with its required libraries in a container image lets applications with conflicting requirements run on the same host, even when they come from different distributions.
Networked microservice composition. Describe how packaging one service or application per container image allows multiple instances and lets separate services, such as a web frontend, load balancer, and database, connect over the network instead of forming one monolithic application. Explain how this supports experimenting with combinations and sharing or reusing software.
Container image components. Describe the image’s rootfs directory tree, the JSON file that describes how to run its contents, and the manifest list that links images for different architectures.
Image-to-container launch sequence. Trace how an engine copies a tar-packed image from a registry, unpacks it, combines image JSON settings with engine defaults and user input into an OCI runtime specification JSON file, and hands that file to a container runtime to launch the primary process.
OCI image and runtime standards. Distinguish the OCI Image Format, which standardizes container images and their JSON file, from the OCI Runtime Specification, which standardizes the container JSON file used by OCI runtimes.
Cross-engine container compatibility. Explain that following OCI standards lets Podman and other container engines work with images in container registries and run them the same way as other engines, including Docker.
Podman design advantage claim. Describe the author's claim that Podman's design is fundamentally better than Docker's and offers features that advance container security and use, without attributing specific features to this introduction.
Podman’s different design perspective. Explain how being developed after Docker let Podman’s developers approach container design differently, while drawing on open-source code, standards such as the Open Container Initiative, and community work on new features.
Rootless container access. Explain that Podman lets users run containers and build images with a standard login account, without granting them root access. Distinguish this from conventional Docker access while acknowledging that Docker can also run rootless.
Docker socket privilege escalation. Trace how access to the Docker socket through the Docker user group can lead to host-root access: run a privileged container with the host filesystem mounted, then chroot into that mount.
Host privileges and audit trails. Contrast what happens after a container escape or removal: Podman processes retain the user’s UID and ordinary-user privileges, with host actions recorded in audit logs, whereas the described Docker attack can remove the container and, with default file logging, erase records of its launch.
Podman fork/exec architecture. Explain how Podman follows the Unix fork/exec model: it pulls images, configures storage, and launches an OCI runtime that starts the container in its process lineage. Describe how filesystem and IPC facilities, including filesystem locking, let multiple container engines share storage without a daemon coordinating them.
Daemonless container operation. Explain that Podman can run the same container images and use the same container runtimes as Docker without keeping multiple daemons running as root. Contrast what remains running after each tool launches a containerized web service.
Docker CLI compatibility. Explain why Podman adopted Docker’s command-line interface: Docker was dominant, and container examples commonly used its commands. Describe compatibility as an aim rather than an absolute guarantee, noting that Podman does not support some commands such as Docker Swarm.
Docker command alias behavior. Describe how aliasing docker to podman lets a user type Docker commands while Podman runs them, and how the podman-docker package provides this alias and links Docker man-page requests to Podman pages.
Docker API compatibility. Explain that Podman’s socket-activated REST API service supports both the Docker API and the Podman API, with the latter providing access to advanced Podman features. Describe how Docker API support lets existing Docker-socket scripts, docker-compose, and tools using docker-py work with the Podman service.
Remote client access. Describe how the Podman REST API lets clients on Mac, Windows, or Linux remotely manage and launch Podman containers on a Linux machine.
Host systemd container management. Explain how Podman lets systemd manage containers as services, including starting and stopping them at boot, generating unit files, and supporting socket activation and service-ready notifications.
Systemd inside a container. Describe how Podman accommodates systemd running as PID 1 inside a container with limited privileges, so it can run multiple services through systemd unit files.
Pods as managed groups. Explain that Podman can manage either individual containers or pods: groups of one or more containers that share storage and network resources and have a specification for how to run them. Describe how a pod groups separate services into a larger service managed as one entity.
Kubernetes YAML exchange and scope. Describe how podman generate kube creates Kubernetes YAML from running containers and pods, while podman play kube uses Kubernetes YAML to create pods and containers on a host. Distinguish the section’s suggested use of Podman on a single host from Kubernetes across multiple machines.
Short-name registry resolution. Explain how Docker and Podman handle an image name that omits its registry, using ubi8/httpd-24 as the example. Describe what Podman does after the user chooses a registry.
Podman image transports. Explain that transports are the image sources and targets Podman supports, and describe the kinds of sources and formats from which Podman can run images.
Configurable container defaults. Explain that, unlike Docker's mostly hardcoded defaults, Podman lets users configure defaults for how containers run, including security-related settings.
Rootless user namespace isolation. Explain that Podman's rootless mode relies on user namespaces, which let a user have multiple UIDs and keep rootless users running containers isolated from one another.
Per-container namespace separation. Distinguish Podman's ability to give each container a unique user namespace from Docker's support for only a single separate user namespace shared by its containers. Explain that separate namespaces let the kernel isolate container processes from host users and one another by UID, whereas root in one Docker container is root in another when they share that namespace.
Single-host Podman scope. Explain that Podman runs container workloads on one host, in rootless or rootful mode, but does not orchestrate containers across multiple machines; that requires a higher-level tool.

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

liveBook manning.com

Read chapter 1 on liveBook Get the book at manning.com

Section by section

Introduction

This introduction presents Podman as a Docker-familiar container engine with stronger default security and previews the ways the book will use it.

Non-root container management: Explain that Podman generally works like Docker but can manage containers without root access or privileges, which the introduction identifies as a major security advantage.
Why it matters: This distinction motivates the book’s later discussion of rootless containers and Podman’s security design.
Podman usage roadmap: Describe the uses previewed here: Docker-like CLI commands, launching containers on a single node locally or through a remote REST API, and finding, running, and building containers with tools such as Buildah and Skopeo.
Why it matters: These examples show the range of container work the book will cover.

Key terms: Podman, Docker, non-root privileges, security, command-line interface (CLI), local container engine, single node, remote REST API, Buildah, Skopeo

1.1 About all these terms

This section defines the main container-tool categories and positions Podman as a container engine for developing and running containers and pods.

Container tool categories: Distinguish container orchestrators, container engines, and OCI container runtimes by what each does and where it operates.
Why it matters: These terms identify which tool schedules containers, which manages them on a node, and which launches the application.
Podman engine identity: Describe Podman as a daemonless container engine that develops, manages, and runs OCI containers on Linux, as root or rootless, with a command line similar to Docker’s.
Why it matters: This establishes what Podman is before the book compares its features with Docker’s.
Pods and shared resources: Explain that Podman runs individual containers as well as pods, and that a pod contains one or more containers sharing namespaces and cgroups.
Why it matters: The pod definition explains Podman’s name and prepares you for managing pods later.
Image and runtime compatibility: Describe Podman’s stated compatibility with OCI and legacy Docker image formats, images from container registries, and OCI runtimes.
Why it matters: This explains how Podman can use existing container images and runtimes rather than requiring a separate ecosystem.
Single-node application use: Describe the section’s intended uses of Podman for developers and administrators, particularly secure container development and managing application lifecycles on single Linux nodes with systemd.
Why it matters: It connects the terminology to the development and operational work the book will teach.

Key terms: container orchestrators, container engines, OCI container runtimes, Kubernetes, Podman, runc, daemonless container engine, OCI Containers, rootless mode, alias Docker = Podman

1.2 A brief overview of containers

The section defines Linux containers as isolated groups of processes and introduces the resource controls, security constraints, and namespaces that provide that isolation.

Container process isolation: Explain that a container is a group of Linux processes isolated from other processes, so applications can run without interfering with one another or conflicting over versions of shared libraries.
Why it matters: This is the foundation for understanding what Podman runs and why containers are useful.
Cgroup resource constraints: Describe how cgroups organize processes into groups whose resource use can be limited and monitored, preventing one group from consuming so much memory, CPU, or network capacity that others cannot make progress.
Why it matters: Resource limits help keep one container from disrupting other work on the host.
Kernel security constraints: Explain that containers use multiple Linux security mechanisms to restrict what their processes can do and help prevent privilege escalation or attacks on the host and other containers. Give examples of the restrictions described in the section.
Why it matters: A separate view of the system is not, by itself, the whole security story.
Namespace resource views: Describe how Linux namespaces give groups of processes different views of system resources, making a container feel like its own environment without the overhead of a virtual machine. Illustrate this with network, mount, or PID namespaces.
Why it matters: Namespaces explain how container processes can see a private environment while sharing a host.

Key terms: containers, processes, shared libraries, resource constraints, cgroups, control groups, security constraints, dropped Linux capabilities, SELinux, read-only access to kernel filesystems

1.2.1 Container images: A new way to ship software

This section explains how container images make software delivery more consistent and why containers require less operating-system management than VMs.

Image packaging and consistency: Explain how host-installed packages can cause applications to fail across machines with different dependencies, and how container images address this by shipping the application with its libraries, executables, and configuration files.
Why it matters: This explains why the same application is less likely to break between development, testing, and customer environments.
Container and VM overhead: Distinguish running isolated applications in VMs from running them in containers: each VM brings an operating system to manage, while containerized applications use their required user spaces and share the host kernel.
Why it matters: The comparison shows why containers reduce operating-system overhead and maintenance for multiple applications.

Key terms: container image, container registry, dependency management, shared libraries, VMs, containerized applications, host kernel, user spaces

1.2.2 Container images lead to microservices

The section explains how container images isolate application dependencies and make it practical to compose reusable microservices.

Isolation of application dependencies: Explain how packaging an application with its required libraries in a container image lets applications with conflicting requirements run on the same host, even when they come from different distributions.
Why it matters: Dependency isolation removes a barrier to running different applications together.
Networked microservice composition: Describe how packaging one service or application per container image allows multiple instances and lets separate services, such as a web frontend, load balancer, and database, connect over the network instead of forming one monolithic application. Explain how this supports experimenting with combinations and sharing or reusing software.
Why it matters: Separately packaged, network-connected services can be combined and reused without rebuilding a monolithic application.

Key terms: container image, C library, conflicting requirements, microservices, monolithic applications, container images, network, multiple instances

1.2.3 Container image format

This section explains what a container image contains and how Podman turns a stored image into a running container.

Container image components: Describe the image’s rootfs directory tree, the JSON file that describes how to run its contents, and the manifest list that links images for different architectures.
Why it matters: These components explain how an image can carry both application files and instructions for using them.
Architecture-specific image selection: Explain that a manifest list lets users request an image by the same name on different machine architectures, while Podman selects the image matching the machine’s default architecture.
Why it matters: A single image name can work across machines with different architectures.
Image-to-container launch sequence: Trace how an engine copies a tar-packed image from a registry, unpacks it, combines image JSON settings with engine defaults and user input into an OCI runtime specification JSON file, and hands that file to a container runtime to launch the primary process.
Why it matters: This sequence connects an image stored in a registry to a running, constrained process.

Key terms: rootfs, JSON file, manifest list, default architecture, Skopeo, --raw, tar, container registry, OCI runtime specification, container runtime

1.2.4 Container standards

This section explains how OCI standards define image and runtime formats so container engines such as Podman and Docker can use the same images.

OCI image and runtime standards: Distinguish the OCI Image Format, which standardizes container images and their JSON file, from the OCI Runtime Specification, which standardizes the container JSON file used by OCI runtimes.
Why it matters: The two standards cover different parts of storing and running a container.
Cross-engine container compatibility: Explain that following OCI standards lets Podman and other container engines work with images in container registries and run them the same way as other engines, including Docker.
Why it matters: Shared standards explain why an image is not tied to one container engine.

Key terms: OCI, OCI Image Format, OCI Runtime Specification, OCI runtimes, JSON file, OCI standards, Podman, Docker, container registries, container engines

1.3 Why use Podman when you have Docker?

Introduces the case for Podman alongside Docker: open-source choice and a design the author argues improves container security and use.

Open-source container choice: Explain why the existence of Docker does not make Podman unnecessary: open source benefits from having alternatives, just as operating systems offer multiple editors, shells, filesystems, and browsers.
Why it matters: This frames Podman as an alternative rather than something that must replace Docker.
Podman design advantage claim: Describe the author's claim that Podman's design is fundamentally better than Docker's and offers features that advance container security and use, without attributing specific features to this introduction.
Why it matters: This is the claim that motivates the feature discussions that follow.

Key terms: open source, choice, Podman, Docker, Podman's design, security, use of containers

1.3.1 Why have only one way to run containers?

This subsection explains why Podman’s later arrival gave its developers a chance to rethink Docker’s design and introduce new features.

Podman’s different design perspective: Explain how being developed after Docker let Podman’s developers approach container design differently, while drawing on open-source code, standards such as the Open Container Initiative, and community work on new features.
Why it matters: This explains the basis for the Podman–Docker feature comparisons that follow.

Key terms: Podman, Docker, Open Container Initiative, open source

1.3.2 Rootless containers

This section explains why Podman’s rootless mode lets ordinary users run containers without host-root privileges and contrasts it with the risks of conventional Docker access.

Rootless container access: Explain that Podman lets users run containers and build images with a standard login account, without granting them root access. Distinguish this from conventional Docker access while acknowledging that Docker can also run rootless.
Why it matters: Rootless operation lets developers use containers without giving them administrative control of the host.
Docker socket privilege escalation: Trace how access to the Docker socket through the Docker user group can lead to host-root access: run a privileged container with the host filesystem mounted, then chroot into that mount.
Why it matters: A Docker client running as an ordinary user is not necessarily limited to that user’s host privileges.
Host privileges and audit trails: Contrast what happens after a container escape or removal: Podman processes retain the user’s UID and ordinary-user privileges, with host actions recorded in audit logs, whereas the described Docker attack can remove the container and, with default file logging, erase records of its launch.
Why it matters: The difference concerns both the damage an escaped process can do and whether the activity remains visible.

Key terms: rootless mode, standard login account, root access, Docker user group, docker.sock, --privileged, /host, chroot, UID, audit logs

1.3.3 Fork/exec model

This section contrasts Docker’s daemon-based path to a container with Podman’s Unix-style fork/exec path and explains how Podman can share storage without a coordinating daemon.

Docker client-server launch path: Trace how the Docker client contacts the Docker daemon, which works through containerd and an OCI runtime to start the container’s first process. Explain that the daemons relay the container’s input and output, adding complexity and potential failure points.
Why it matters: The Docker launch path makes the architectural contrast with Podman clear.
Podman fork/exec architecture: Explain how Podman follows the Unix fork/exec model: it pulls images, configures storage, and launches an OCI runtime that starts the container in its process lineage. Describe how filesystem and IPC facilities, including filesystem locking, let multiple container engines share storage without a daemon coordinating them.
Why it matters: This is the section’s explanation of how Podman can launch containers without Docker’s chain of daemons.

Key terms: Docker client, Docker daemon, containerd, OCI runtime, PID1, stdin, fork/exec, container registry, container storage, inter-process communication (IPC)

1.3.4 Podman is daemonless

This section contrasts Docker’s continuously running daemons with Podman’s daemonless way of launching containers and explains why the difference matters on resource-limited machines.

Daemonless container operation: Explain that Podman can run the same container images and use the same container runtimes as Docker without keeping multiple daemons running as root. Contrast what remains running after each tool launches a containerized web service.
Why it matters: The difference explains why Podman can reduce overhead on IoT devices and edge servers.

Key terms: daemonless, container images, container runtimes, Docker client, daemons, overhead

1.3.5 User-friendly command line

This section explains why Podman follows Docker’s command-line interface and how users can run familiar Docker commands through Podman.

Docker CLI compatibility: Explain why Podman adopted Docker’s command-line interface: Docker was dominant, and container examples commonly used its commands. Describe compatibility as an aim rather than an absolute guarantee, noting that Podman does not support some commands such as Docker Swarm.
Why it matters: This explains why existing Docker habits and examples often work with Podman.
Docker command alias behavior: Describe how aliasing docker to podman lets a user type Docker commands while Podman runs them, and how the podman-docker package provides this alias and links Docker man-page requests to Podman pages.
Why it matters: The alias shows how someone can switch tools without changing their usual commands.

Key terms: Docker CLI, Podman CLI, Docker Swarm, alias docker=podman, podman-docker, docker ps, podman ps, man page

1.3.6 Support for REST API

This section explains how Podman’s socket-activated REST API service supports existing Docker tools and remote clients.

Docker API compatibility: Explain that Podman’s socket-activated REST API service supports both the Docker API and the Podman API, with the latter providing access to advanced Podman features. Describe how Docker API support lets existing Docker-socket scripts, docker-compose, and tools using docker-py work with the Podman service.
Why it matters: You can use Podman without necessarily replacing the tools and scripts you already use to launch containers.
Remote client access: Describe how the Podman REST API lets clients on Mac, Windows, or Linux remotely manage and launch Podman containers on a Linux machine.
Why it matters: The machine running the client does not have to be the Linux machine running the containers.

Key terms: socket-activated REST API service, Docker API, Podman API, Docker socket, docker-compose, docker-py, Podman REST API, remote Podman clients, Linux machine

1.3.7 Integration with systemd

This section explains how Podman integrates containers with systemd, both as host-managed services and as environments that can run systemd inside the container.

Host systemd container management: Explain how Podman lets systemd manage containers as services, including starting and stopping them at boot, generating unit files, and supporting socket activation and service-ready notifications.
Why it matters: This is the basis for managing Podman containers with the operating system’s service manager.
Systemd inside a container: Describe how Podman accommodates systemd running as PID 1 inside a container with limited privileges, so it can run multiple services through systemd unit files.
Why it matters: Running systemd inside a container lets developers manage its services much as they would on a system or VM.
Docker and systemd design contrast: Distinguish Podman’s decision to integrate with systemd from the upstream Docker community’s preference for its daemon to control container lifecycles, and explain why the section favors systemd’s additional service-management features.
Why it matters: The contrast explains why systemd integration is a deliberate part of Podman’s design.

Key terms: systemd, systemd unit files, socket activation, service notifications, cgroups, PID1, limited privileges, Docker daemon, startup ordering, service ready notifications

1.3.8 Pods

This section introduces pods as groups of containers managed together and shows how Podman connects single-host pods with Kubernetes YAML.

Pods as managed groups: Explain that Podman can manage either individual containers or pods: groups of one or more containers that share storage and network resources and have a specification for how to run them. Describe how a pod groups separate services into a larger service managed as one entity.
Why it matters: Pods let you combine containerized services without managing each one separately.
Kubernetes YAML exchange and scope: Describe how podman generate kube creates Kubernetes YAML from running containers and pods, while podman play kube uses Kubernetes YAML to create pods and containers on a host. Distinguish the section’s suggested use of Podman on a single host from Kubernetes across multiple machines.
Why it matters: These commands provide a way to move between local Podman experiments and Kubernetes definitions.

Key terms: pod, Pod Manager, microservices, shared storage/network resources, podman generate kube, podman play kube, Kubernetes YAML, single host

1.3.9 Customizable registries

This section contrasts Docker’s fixed short-name registry with Podman’s configurable registry choices and remembered aliases.

Short-name registry resolution: Explain how Docker and Podman handle an image name that omits its registry, using ubi8/httpd-24 as the example. Describe what Podman does after the user chooses a registry.
Why it matters: A short image name can resolve to different registries depending on the container engine and its configuration.
Full image names: Distinguish a short image name such as ubi8 from a complete name that specifies its registry, such as registry.access.redhat.com/library/ubi8:latest.
Why it matters: Specifying the registry removes ambiguity about where an image should be pulled from.
Additional registry controls: State that Podman can remove docker.io from its registry list and also supports blocking registries, requiring signed images, image mirrors, and fixed mappings from short names to full names.
Why it matters: Registry configuration can govern both where images come from and which images are accepted.

Key terms: short name, container registry, short-name alias, complete image name, blocking registries, signed images, image mirrors, hardcoded short names

1.3.10 Multiple transports

This subsection introduces Podman’s image transports and the range of sources and formats from which it can run images.

Podman image transports: Explain that transports are the image sources and targets Podman supports, and describe the kinds of sources and formats from which Podman can run images.
Why it matters: This explains why Podman can work with images beyond those in container registries.

Key terms: transports, container registries, local containers storage, OCI format, OCI TAR format, legacy Docker TAR format

1.3.11 Complete customizability

Podman lets users change container-engine defaults through configuration files, including defaults that affect security.

Configurable container defaults: Explain that, unlike Docker's mostly hardcoded defaults, Podman lets users configure defaults for how containers run, including security-related settings.
Why it matters: This explains why Podman can be tailored to a system's needs without changing settings for every container.
Configuration file locations: Describe the three containers.conf locations and their roles: distribution changes under /usr/share, system overrides under /etc, and a home-directory configuration available only in rootless mode.
Why it matters: The location tells you whose defaults a configuration file is intended to set.

Key terms: built-in defaults, containers.conf, namespaces, SELinux, capabilities, /usr/share/containers/containers.conf, /etc/containers/containers.conf, $HOME/.config/containers/containers.conf, rootless mode

1.3.12 User-namespace support

This section explains how Podman uses user namespaces to isolate rootless users and individual containers, and contrasts that support with Docker's.

Rootless user namespace isolation: Explain that Podman's rootless mode relies on user namespaces, which let a user have multiple UIDs and keep rootless users running containers isolated from one another.
Why it matters: User namespaces are the basis for the rootless isolation described later in the book.
Per-container namespace separation: Distinguish Podman's ability to give each container a unique user namespace from Docker's support for only a single separate user namespace shared by its containers. Explain that separate namespaces let the kernel isolate container processes from host users and one another by UID, whereas root in one Docker container is root in another when they share that namespace.
Why it matters: The contrast shows why a separate namespace for each container provides stronger UID-based separation between containers.

Key terms: rootless mode, user namespace, UIDs, unique user namespace, UID separation, single, separate, user namespace

1.4 When not to use Podman

This section defines Podman’s single-host scope and explains why multi-machine orchestration requires another tool, usually Kubernetes rather than Swarm.

Single-host Podman scope: Explain that Podman runs container workloads on one host, in rootless or rootful mode, but does not orchestrate containers across multiple machines; that requires a higher-level tool.
Why it matters: This boundary helps you choose the right tool when a workload spans machines.
Kubernetes and Swarm choice: Describe why the Podman team favors Kubernetes for multi-machine containers and does not support Docker Swarm functionality, while noting that Podman has also been used with other orchestrators and grid/HPC computing.
Why it matters: It explains Podman’s orchestration choices without implying that Kubernetes is its only possible integration.

Key terms: single host, rootless, rootful, container orchestrator, Kubernetes, Swarm, grid/HPC computing

1.5 Summary

The chapter summary recaps how images and registries improve software delivery and why Podman is a practical, Docker-compatible, security-focused engine for single-node containers.

Where this is used later

How does rootless Podman work? (chapter 6) · Explains how rootless Podman works.
Working with containers (chapter 2) · Covers working with containers from the command line.
Building images (chapter 2) · Covers building images.
Introducing the Podman service (chapter 9) · Introduces the Podman service used for API access.
Launching the OCI runtime (chapter 6) · The account of launching an OCI runtime depends on distinguishing the runtime from the engine.
Running pods (chapter 4) · Builds on the definition of a pod when introducing how to run pods.
Pulling images (chapter 2) · Applies the idea of obtaining images from registries.
Starting containers at boot (chapter 7) · Expands on managing containers as services that start at boot.

Concepts explained in this chapter

PodmanPodman is a daemonless container engine that runs containers and builds images, including under an unprivileged user account.
DockerDocker is a container platform that provides a daemon-based engine, client, and ecosystem for building and running containers.
container imageA packaged filesystem and application artifact containing the code, dependencies, and runtime requirements needed to create a container.
cgroupA Linux kernel mechanism for grouping processes and limiting or accounting for their resource usage.
rootless modeA rootless container is a container whose engine and processes run without host-level root privileges.
container registryA container registry is a service that stores, distributes, and serves container images.
linux namespaceA Linux kernel isolation mechanism that provides a process with a separate view of selected system resources.
systemdsystemd is a Linux init system and service manager that starts, supervises, and stops system services.
podA pod is a group of one or more containers that share storage and network resources and a runtime specification.
agent orchestrationA container orchestrator is a system that schedules and manages container workloads across one or more machines.
KubernetesKubernetes is an open-source platform for orchestrating containerized workloads across clusters of machines.
Open Container InitiativeThe Open Container Initiative is an open-governance project that develops open standards for container image formats and container runtimes.
virtual machineA virtual machine is a software-emulated computer that provides an isolated environment with virtualized hardware for running an operating system and its workloads.
user ID namespaceA user namespace is a Linux namespace that isolates security-related identifiers and capabilities and maps host user and group identifiers to namespace identifiers.
Docker CLIThe Docker CLI is the command-line client through which users invoke Docker container operations.
fork/exec modelThe fork/exec model is a process-launching pattern in which a parent process forks a child and the child replaces its program image by executing another program.
systemd unit fileA systemd unit file is a declarative configuration file describing a systemd-managed service or other unit.
rootThe root user is the Unix-like operating-system account with unrestricted administrative authority over the host.
client-server architectureA client-server application is software organized into clients that request services from a separate server process.
root filesystemA root filesystem is the filesystem tree presented as the top-level directory hierarchy to an operating-system environment or container.
command-line interfaceA command-line interface is a text-based interface for invoking software operations by entering commands.
RESTA REST API is a network interface that exposes resources and operations through HTTP using representational state transfer conventions.
short nameA short name is a container image reference that omits the registry and other fully qualified naming components.
podman system serviceThe Podman compatibility service is a background Podman endpoint that accepts Docker-compatible container-management requests.
containers.confcontainers.conf is a configuration file format used to define default settings for Podman and related container tools.
Linux capabilityA Linux capability is a discrete permission that divides traditionally privileged root powers into independently controllable units.
SELinuxAn SELinux system is an operating system environment with SELinux mandatory access-control enforcement enabled.
kernel filesystemA kernel filesystem is a filesystem interface exposed by the operating-system kernel for representing kernel-managed information or resources.
mount namespaceA mount namespace is a Linux namespace that isolates the filesystem mount view available to a process group.
network namespaceA network namespace is a Linux namespace that provides an isolated view of network devices and network configuration.
pid namespaceA PID namespace is a Linux namespace that isolates process identifiers and the visible process tree.
seccompA seccomp filter is a policy configuration that determines which system calls a process and its descendants may invoke.
socket activationA socket-activated service is a service that is started when a connection arrives on a listening socket and may exit while idle.
Docker user groupThe Docker user group is a Unix group whose membership can grant users access to the Docker daemon socket, potentially providing host-root-equivalent control.
containers/storageLocal container storage is the on-host storage managed by a container engine for container images and related container data.
podman generate kubepodman generate kube is a Podman command that generates Kubernetes YAML manifests from running containers and pods.
rootful modeA rootful container is a container whose engine or processes run with host-level root privileges.
Docker ComposeDocker Compose is a tool for defining and running multi-container applications.

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.