Handling Container Images

By default, Podman stores container images in the /var/lib/containers directory defined in the Open Container Initiative (OCI) standard. However, because non-privileged users can also work with containers, ~/.local/share/containers/ provides a storage location in the user's home directory in which container images can also be stored.

Podman's storage component is configured in the /etc/containers/storage.conf file. Whether you create an image with Docker or Podman does not matter, because both container engines comply with the OCI standard for container images; therefore, you can import a Docker image on a Podman host without problems. The following call shows which registries are used by default:

podman info --format={{".registries"}}
map[registries:[docker.io registry.fedoraproject.org quay.io registry.access.redhat.com registry.centos.org]]

To fetch the desired image to the local system and start the container, use:

podman pull docker.io/library/httpd

Alternatively, you can start a container directly from a desired image. If it is not yet available locally, Podman will download it from one of the registries. You can also specify the registry directly in the image name:

sudo podman run -dt -p 80:80 docker.io/library/httpd httpd -D FOREGROUND

In this case, the container is launched with root privileges because container port 80 is bound to the same port on the host system. The following call shows that a web server inside the container is now listening on port 80:

links -dump http://localhost
It works!

The call to podman images or podman ps displays the existing images or active containers for a user, whereas the commands

podman rmi <image>
podman rm <container ID>

delete images and containers.

Creating OCI-Compliant Images

Podman itself can also create new OCI-compliant container images based on a Dockerfile, as shown with this very simple Dockerfile that creates a new Fedora image with an Nmap package:

cat Dockerfile
FROM fedora
RUN dnf -y update && dnf -y install nmap && dnf clean all

Next, start the build process from the directory where the Dockerfile is located:

podman build --tag nmap

Podman can also fetch a Dockerfile directly from a web server or from a GitHub repository. More information can be found on the man podman-build help page. The newly created image is then located in the local container storage repository. As Listing 3 shows, you can now use it to create an Nmap container.

$ podman images
REPOSITORY        TAG       IMAGE ID          CREATED             SIZE
localhost/nmap    latest    53890e393585      34 seconds ago      425 MB
 **
$ podman run --rm localhost/nmap rpm -q nmap
nmap-7.70-5.fc29.x86_64

To push the image out to the quay.io public registry (by way of an example), you first need to log in to the server before you push the image into the registry:

podman login quay.io -u <user> -p <password>
podman push localhost/nmap quay.io/tscherf/nmap

If you want to create a new container image independent of a Dockerfile, you should take a look at the Buildah tool [2], which is especially useful if you want to launch new images from scripts.

Pods on a Local System

"Pods" are a term from the Kubernetes world and denote a collection of containers that share certain resources (e.g., the kernel namespace or cgroups). Because containers also use the same network namespace, the containers in a pod can communicate with each other without requiring a routable IP address. Each pod has an infrastructure container based on the k8s.gcr.io/pause image. The task of this container is to provide the resources permanently for all other containers in the pod, including, for example, kernel namespaces, as well as cgroups and network resources. Moreover, this container takes care of communication with the Podman tool.

Each container in a pod is assigned its own monitoring instance (conmon) that monitors the process(es) running in the container and ensures that Podman can connect to a TTY inside the container at any time. This monitoring instance is necessary because Podman does not use a daemon in the background, which would otherwise handle the monitoring work.

To create a new pod and then assign a container to it, enter:

podman pod create --name web

The podman pod ps command reveals whether the pod was successfully generated. At a glance, you can see that only the infrastructure container is currently available in this pod (Listing 4). To add a new container to the pod, simply enter the pod name when starting the container. The call to podman pod list then also confirms that two containers are now in the pod (Listing 5).

$ podman ps -a --pod
CONTAINER ID IMAGE COMMAND        CREATED            STATUS  PORTS NAMES        POD
9062dac6ff19 k8s.gcr.io/pause:3.1 About a minute ago Created dfd09806b03c-infra dfd09806b03c

$ podman run -d --pod web docker.io/library/httpd httpd -D FOREGROUND
 **
$ podman pod list
POD ID            NAME        STATUS        CREATED          # OF CONTAINERS    INFRA ID
dfd09806b03c      web         Created       46 seconds ago   2                  9062dac6ff19

In Podman version 1.0 and newer, you can also create a new pod directly when starting a container (Listing 6). In this case, a single command was all it took to create a new HTTPD container in a new pod. Of course, the infrastructure container was also created when the pod was created. Because the HTTPD port of the web server container is mapped to host port 8080 this time, no root privileges are required to start the container.

$ podman run -dt --pod new:httpd -p 8080:80 docker.io/library/httpd httpd -D FOREGROUND
 **
$ podman ps --pod
CONTAINER ID IMAGE                          COMMAND            CREATED         STATUS              PORTS                NAMES             POD
7e337cbed38e docker.io/library/httpd:latest httpd -D FOREGROU  19 seconds ago  Up 18 seconds ago   0.0.0.0:8080->80/tcp confident_ritchie 119a122bdab3
 **
$ podman pod list
POD ID            NAME        STATUS        CREATED          # OF CONTAINERS    INFRA ID
119a122bdab3      httpd       Running       30 seconds ago   2                  b8301dde3144
 **
$ links -dump http://localhost:8080
It works!

The ability to create local pods is certainly extremely interesting for developers because it allows a microservice-based application to be distributed across multiple containers without the need for a full-fledged Kubernetes cluster. If you want to migrate the application to a cluster of this type, Podman again offers a very elegant option for doing so. A call to podman generate kube tells the tool to create a YAML file, which you can then copy to a Kubernetes system to create the containers and pods exactly as listed in that file.