Using pods with Podman on Fedora

Using Pods with Podman

Photo by Dick Martin on Unsplash

This article shows the reader how easy it is to get started using pods with Podman on Fedora. But what is Podman? Well, we will start by saying that Podman is a container engine developed by Red Hat, and yes, if you thought about Docker when reading container engine, you are on the right track.

A whole new revolution of containerization started with Docker, and Kubernetes added the concept of pods in the area of container orchestration when dealing with containers that share some common resources. But hold on! Do you really think it is worth sticking with Docker alone by assuming it’s the only effective way of containerization? Podman can also manage pods on Fedora as well as the containers used in those pods.

Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images.

From the official Podman documentation at

Why should you switch to Podman?

Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Podman directly interacts with an image registry, containers and image storage.

To install podman, run this command using sudo:

sudo dnf -y install podman

Creating a pod

To start using the pod we first need to create it and for that we have a basic command structure

$ podman pod create

The command above contains no arguments and hence it will create a pod with a randomly generated name. You might however, want to give your pod a relevant name. For that you just need to modify the above command a bit.

$ podman pod create --name climoiselle

The pod will be created and will report back to you the ID of the pod. In the example shown the pod was given the name ‘climoiselle’. To view the newly created pod is easy by using the command shown below:

$ podman pod list
POD ID        NAME              STATUS   CREATED         # OF CONTAINERS  INFRA ID
e65767428fa0  climoiselle       Created  19 seconds ago  1                d74fb8bf66e7
d2a5d381247c  blissful_dewdney  Created  32 minutes ago  1                3185af079c26

As you can see, there are two pods listed here, one named blissful_dewdney and the one created from the example named climoiselle. No doubt you notice that both pods already include one container, yet we didn’t deploy a container to the pods yet.

What is that extra container inside the pod? This randomly generated container is an infra container. Every podman pod includes this infra container and in practice these containers do nothing but go to sleep. Their purpose is to hold the namespaces associated with the pod and to allow Podman to connect other containers to the pod. The other purpose of the infra container is to allow the pod to keep running when all associated containers have been stopped.

You can also view the individual containers within a pod with the command:

$ podman ps -a --pod
CONTAINER ID  IMAGE                 COMMAND  CREATED         STATUS   PORTS   NAMES               POD ID        PODNAME
d74fb8bf66e7           38 seconds ago  Created          e65767428fa0-infra  e65767428fa0  climoiselle
3185af079c26           32 minutes ago  Created          d2a5d381247c-infra  d2a5d381247c  blissful_dewdney

Add a container

The cool thing is, you can add more containers to your newly deployed pod. Always remember the name of your pod. It’s important as you’ll need that name in order to deploy the container in that pod. We’ll use the official Fedora image and deploy a container that uses it to run the bash shell.

$ podman run -it --rm --pod climoiselle fedora /bin/bash

When finished, type exit or hit Ctrl+D to leave the shell running in the container.

Everything in a single command

Podman has an agile characteristic when it comes to deploying a container in a pod which you created. You can create a pod and deploy a container to the said pod with a single command using Podman. Let’s say you want to deploy an NGINX container, exposing external port 8080 to internal port 80 to a new pod named test_server.

$ podman run -dt --pod new:test_server -p 8080:80 nginx
Trying to pull
  manifest unknown: manifest unknown
Trying to pull
  unsupported: This repo requires terms acceptance and is only available on
Trying to pull
  manifest unknown: manifest unknown
Trying to pull
Getting image source signatures
Copying blob e05167b6a99d done
Copying blob 2766c0bf2b07 done
Copying blob 70ac9d795e79 done
Copying blob 6ec7b7d162b2 done
Copying blob cb420a90068e done
Copying config ae2feff98a done
Writing manifest to image destination
Storing signatures

Let’s check all pods that have been created and the number of containers running in each of them …

$ podman pod list
POD ID        NAME              STATUS   CREATED         # OF CONTAINERS  INFRA ID
7495cc9c7d93  test_server       Running  2 minutes ago   2                6bd313bbfb0d
e65767428fa0  climoiselle       Created  11 minutes ago  1                d74fb8bf66e7
d2a5d381247c  blissful_dewdney  Created  43 minutes ago  1                3185af079c26

Do you want to know a detailed configuration of the pods which are running? Just type in the command shown below:

podman pod inspect [pod's name/id]

Make it stop!

To stop the pods, we need to use the name or ID of the pod. With the information from podman’s pod list command, we can view the pods and their infra id. Simply use podman with the command stop and give the particular name/infra id of the pod.

$ podman pod stop test_server

After following this short tutorial, you can see how quickly you can use pods with podman on fedora. It’s an easy and convenient way to use containers that share resources and interact together.

Further reading

FAQs and Guides Fedora Contributor Community For Developers For System Administrators Using Software


  1. Oscar

    Thanks for this article.
    One question, though: is it possible to share a common volume between containers belonging to a pod? If it is so,, how it could be implemented?
    Thanks again!

  2. rimuru

    Cool tutorial. Learned something new. Thanks

  3. Artur

    So small screenshots 🙁

  4. Hello
    Great article. Thanks
    One question:
    Is it possible to create rootless cni bridge network routable from the host?

  5. Martin

    I love the idea of podman, but in my experience it has been incredibly buggy to the point it’s ridiculous. Maybe I was just unlucky to get unstable builds?

    Also, it’s great that there are so many distinct options for networking (and that they don’t bypass the system firewall like Docker does), but I find the documentation quite lacking. We regularly struggle to deploy new services and expose them to the world.

  6. Mark

    Thanks for this article.

    Do the ‘podman’ pods behave exactly as a kubernetes pod does ?.

    I have an issue with K8s in the way every container in a pod can see every other container in that pod as a ‘localhost’ entity, behaviour different to docker, if podman does emulate K8 ‘pods’ this will be very useful in migration testing.

    However if ‘pod’ is being used as a generic term for something that behaves differently to a kubernetes ‘pod’ then the feature is useless and using the teerm confusing.

    Personally I do not like podman from a system administration point of view in that it allows users their own personal copies of suid files under ~/local/share/containers/storage/overlay for any image they build/use which they can run even if 3rd party security products block access to the standard copies under /bin or /sbin. At least docker daemon only allows root to get at those copies. Of course ‘snap’ packages do exactly the same thing in propogating suid files into user directories; I must accept the world is moving to make linux an insecure environment. But not immediately.

    However if the podman ‘pod’ functions do emulate the environment found within a K8 pod deployment this feature can be very useful for desktops and testing even if it has no place on a shared server. If it does an example of a K8 yaml/deployment file added to this post would make this post useful.

  7. Mohnish

    “… But hold on! Do you really think it is worth sticking with Docker alone by assuming it’s the only effective way of containerization? .. ”

    RedHat’s push for daemonless, unprivileged approach is appreciated. The alternative approach and interest may have lead to the implementation of “rootless” Docker daemon since v19. 03.

    It’s worth noting that Docker is well established, has good cross platform support, community momentum, an API that most are familiar with & enjoys wide enterprise adoption. Also the Docker team is active in implementing new features based on feedback. So, Docker is an important skill to learn for those in a tech job – dare I say, much more than Podman at the moment.

    So IMO, Fedora articles should focus on highlighting Podman features and the alternative approach, but drop the “.. you don’t need Docker ..” tagline from its articles!

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions