podman

List all containers (both running and stopped)

$ podman ps --all

$ podman run --name [container_name] [image]

$ podman [start|stop] [container_name]

$ podman pull [image]

$ podman images

$ podman exec --interactive --tty [container_name] [sh]

$ podman rm [container_name]

$ podman logs --follow [container_name] [container_id]

podman [options] [command]
podman [options] command [command options] [arguments...]

--help, -h
    Show help for a command or subcommand.

--version
    Print the version number.

--log-level=level
    Set the logging level (e.g., debug, info, warn, error).

--root=path
    Path to the container storage root directory.

--runroot=path
    Path to the container storage run root directory.

--storage-driver=driver
    Storage driver to use (e.g., overlay, vfs).

--storage-opt=option
    Storage driver options.

--remote, -r
    Connect to a remote Podman service. (Default: false)

--url=URL
    URL to access the Podman service (e.g., ssh://user@host/run/podman/podman.sock).

--connection=name
    Name of the connection to use from containers.conf.

--identity=path
    Path to an SSH identity file for remote connections.

--username=name
    Username for SSH connection to the remote host.

--tls-verify
    Require TLS verification for remote API connections.

Podman is an open-source, daemonless container engine for developing, managing, and running OCI (Open Container Initiative) containers and pods on a Linux system. It offers a command-line interface highly compatible with the Docker CLI, making it a popular choice for users transitioning from Docker.

Unlike Docker, Podman does not require a persistent background daemon, improving security and simplifying its architecture. It excels in enabling rootless containers, allowing users to run containers without requiring root privileges, thus enhancing system security by isolating container processes from the host's root user.

Podman manages the entire container lifecycle, from image pull and creation to execution and removal. It integrates seamlessly with other container tools like Buildah for building container images and Skopeo for inspecting and transferring container images. It supports both standalone containers and pods, which are groups of containers that share resources like network and storage, similar to Kubernetes pods. This makes Podman a versatile tool for both development and production environments, including those that may later deploy to Kubernetes.

While Podman offers significant advantages, especially with rootless containers, it does come with certain considerations:
Daemonless Architecture: The absence of a central daemon means Podman processes are typically user-specific and transient. This differs from Docker's persistent daemon, potentially affecting long-running services unless managed via systemd.
Rootless Limitations: Running containers as a non-root user may introduce limitations, such as inability to bind to privileged ports (below 1024) without additional capabilities, or complexities with certain advanced networking setups.
Resource Management: On systems using cgroups v1, user-defined resource limits for rootless containers can be less straightforward than for rootful containers. cgroups v2 generally offers better support for rootless resource management.
Direct Container Access: Unlike Docker, there's no single 'daemon socket' to connect to for all container operations; each user session manages its own containers. Remote access is facilitated via the Podman API service.

Podman's key feature is its support for rootless containers. This allows unprivileged users to create, run, and manage containers without requiring elevated privileges on the host system. This significantly enhances security by preventing container escape exploits from gaining root access to the host. It utilizes user namespaces to achieve this isolation.

Podman strictly adheres to the Open Container Initiative (OCI) specifications for container images and runtimes. This ensures interoperability with other OCI-compliant tools and runtimes, meaning images built with Buildah or Docker can be run by Podman, and vice-versa. This open standard approach promotes flexibility and avoids vendor lock-in.

Beyond single containers, Podman supports the concept of pods, which are groups of one or more containers that share resources like network namespaces, IPC, and storage volumes. This is a crucial feature for deploying multi-container applications that are often orchestrated by platforms like Kubernetes. Podman can even generate Kubernetes YAML files from existing pods.

Podman can generate systemd unit files for containers and pods, allowing them to be managed as services by the host's systemd init system. This provides robust lifecycle management, automatic restarts, and integration with standard Linux monitoring tools, making Podman suitable for deploying long-running production workloads.

The podman command operates via numerous subcommands (e.g., podman run, podman build, podman images). Each subcommand has its own set of specific options, which can be viewed by running podman <subcommand> --help. The parameters section above focuses on global options applicable to the podman command itself.

Podman originated at Red Hat as a modern, daemonless alternative to traditional container engines like Docker. It was initially developed as part of the libpod project, aiming to provide a compatible command-line interface while adhering strictly to OCI (Open Container Initiative) standards for container images and runtimes.

Its development focused heavily on security and ease of integration with standard Linux tools. The emphasis on rootless containers allowed non-privileged users to manage containers, significantly reducing potential attack surfaces. Over time, it gained widespread adoption, especially in enterprise Linux distributions and environments prioritizing security and system integrity. Its ability to generate systemd units for containers further solidified its position as a robust tool for production deployments.

buildah(1), skopeo(1), podman-systemd(1), containers-registries.conf(5), containers-storage.conf(5), containers-mounts.conf(5), docker(1)