« Previous 1 2 3 Next »
Managing containers with Podman
Same but Different
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.
Listing 3
Creating 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).
Listing 4
Displaying Containers in a Pod
$ 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
Listing 5
Two Containers in a Pod
$ 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.
Listing 6
Creating a Pod at Container Startup
$ 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.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)