Managing Container Images using Podman

Applications can run inside containers, providing all dependencies, that is, container image and a file system bundle which provides the app files, 3rd party libraries are there. Container images are available from image registries that allow users to search and retrieve container images.

You can use the search subcommand to find available images from remote or local registries.

[user@artcdc ~]$ podman search rhel
INDEX       NAME                            DESCRIPTION   STARS OFFICIAL AUTOMATED This plat...  0
...output omitted...

Once image was found, you can now download it using Podman pull command. This command will fetch the image and save it locally.

[user@artcdc ~]$ podman pull rhel
Trying to pull
Getting image source signatures
Copying blob sha256: ...output omitted...
72.25 MB / 72.25 MB [======================================================] 8s
Copying blob sha256: ...output omitted...
1.20 KB / 1.20 KB [========================================================] 0s
Copying config sha256: ...output omitted...
6.30 KB / 6.30 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures

Container images are named based on the following syntax:


Registry Naming syntax:

  • The registry_name is the name of the registry storing the image. It is usually the FQDN of the registry.
  • The user_name is the name of the user or organization to which the image belongs.
  • The image_name must be unique in user namespace.
  • The tag identifies the image version. If the image name includes no image tag, latest is assumed.

After fetching, Podman stores images locally and you can list them with the images command:

[user@artcdc ~]$ podman images
REPOSITORY                      TAG     IMAGE ID     CREATED    SIZE latest  699d44bc6ea2 4 days ago 214MB
...output omitted...

Running Containers

The podman run command runs a container locally based on an image. At a minimum the command requires the name of the image to execute in the container.

The container image specifies a process that starts inside the container known as the entry point. The podman run* command uses all parameters after the image name as the entry point command for the container. The following example starts a container from a Red Hat Universal Base Image. It sets the entry point for this container to the echo “Hello world” command:

[user@artcdc ~]$ podman run ubi8/ubi:8.3 echo 'Hello world!'
Hello world!

To start a container image as a background process, pass the -d option to the podman run command:

[user@artcdc ~]$ podman run -d -p 8080
[user@artcdc ~]$ podman port -l
8080/tcp ->
[user@arcdc ~]$ curl
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "
<html xmlns="" xml:lang="en">
...output omitted...

This example runs a containerized Apache HTTP server in the background. It uses the -p 8080 option to bind HTTP server’s port to a local port. Then, it uses the podman port command to retrieve the local port on which the container listens. Then, it uses this port to create the target URL and fetch the root page from the Apache HTTP server. This response proves the container is still up and running after the podman run command.

Most Podman commands accept the -l flag (latest flag) as a replacement for the container id.

If the image to be executed is not available locally when using the podman run command, Podman automatically uses pull to download the image.

When referencing the container, Podman recognizes a container either with the container name or the generated container id. Use the –name option to set the container name when running the container with Podman. Container names must be unique. If the podman run command includes no container name, Podman generates a unique random one for you.

If the images require that the user interact with the console, then Podman can redirect container input and output streams to the console. The run subcommand rquirees the -t and -i flags (or the -it flag) to enable interactivity.

Many Podman flags also have an alternative long form; some of these are explained below:

  • -t is equivalent to –tty, meaning a pseudo-tty (pseudo-terminal) is to be allocated for the container
  • -i is the same as –interactive. When used, standard input is kept open into the container.
  • -d, or its long form –detach, means the container runs in the background (detached). Podman then prints the container id.
  • Continue with Podman documentation for the complete list of flags.

The following example starts a Bash terminal inside the container, and interactively runs some commands in it:

[user@artcdc ~]$ podman run -it ubi8/ubi:8.3 /bin/bash
bash-4.2# ls
...output omitted...
bash-4.2# whoami
bash-4.2# exit
[user@artcdc ~]$

Some containers require external parameters at startup. Use environment variables for these instances. Podman can inject environment variables on containers at startup by including -e flag to the run command.

[user@artcdc ~]$ podman run -e VAR1=Hello -e VAR2=World \
> ubi8/ubi:8.3 printenv VAR1 VAR2
[user@artcdc ~]$