5 Podman features to try now

The Podman team has added many cool new features to Podman that you might not be aware of. So, this is the first in a series of articles that cover some of the large and small features that make Podman great.

When we first started building Podman, we wanted to match the Docker command-line interface (CLI), and we added features to match. We even have a page on the Podman GitHub called transfer.md that lists Docker's commands, the completed features, and which are still in progress. Now that Podman is basically complete and matches Docker, we rarely update the page.

Last year, we added the Podman service to Podman 3.0, which replicates Docker's REST API. The Podman service supports any tools needed to communicate with the Docker daemon, like Docker-compose and Docker.py. The Podman service also supports its own REST API for advanced Podman features, like pods.

We feel Podman is feature-complete as a Docker replacement. However, I think we sell Podman short when we talk only about features that match Docker. While we were building compatibility, the Podman developers and open source community added large and small features that improve the project. Sometimes we add features just to scratch an itch.

This first article covers five Podman options that I love to use. We want to hear from you about features you love in Podman and features you would like to see added, so reach out to us through our usual communication channels.

1. The --latest flag

The first option I want to discuss is the --latest (-l) flag. The basic idea of the flag is to use the latest or last container that Podman created.

I did not like the idea when this flag was first introduced, but here's why the option has become indispensable. When playing with Podman containers or developing and testing Podman, users constantly create containers and then start, stop, inspect, and remove them.

When creating or running a container, the container gets a default name and ID (although you can override this with the --name option):

$ podman create ubi8 echo hi
Ef3a2d8500b998847cd898af8f5b4580186716a920b6d0c151553da702289c7a

To start the container, you need to cut and paste the ID:

$ podman start --attach ef3a2d8500b9988
hi

To inspect the container, you also need to cut and paste the container ID:

$ podman inspect ef3a2d8500b9988 –format ‘{{ .Id }}’
ef3a2d8500b998847cd898af8f5b4580186716a920b6d0c151553da702289c7a

Finally, to remove it, you once again cut and paste:

podman rm ef3a2d8500b9988
ef3a2d8500b998847cd898af8f5b4580186716a920b6d0c151553da702289c7a

You could have named the container and referred to it by name, but this can be a pain if the container is short lived.

Using -l (--latest) makes this much easier to deal with. Here's the same set of events:

$ podman create ubi8 echo hi
5649a881c12fd26e34febce00887329a9031164733490aef28e7b627cbaaa48c

$ podman start --attach -l
hi

$ podman inspect -l --format '{{ .Id }}'
5649a881c12fd26e34febce00887329a9031164733490aef28e7b627cbaaa48c

$ podman rm -l
5649a881c12fd26e34febce00887329a9031164733490aef28e7b627cbaaa48c

You could even do this in a script. At first, I did not like this because it theoretically could be racey. If some other container is created between my creation and inspection, I could end up inspecting a different container. But usually, I am sitting on my own system and just working with the same container over and over, and the --latest option is a great time saver.

Bottom line, I use the -l option all the time now. Unfortunately, we don't support -l on remote, which means you are out of luck if you are on a Mac.

[ Learn what it takes to develop cloud-native applications using modern tools such as microservices. Download the eBook Kubernetes Native Microservices with Quarkus and MicroProfile. ] 

2. The --replace flag

I was at a talk a couple of weeks ago with one of our engineers, Valentin Rothberg, and he was doing a demonstration. He ran a container with the --replace option. I had never noticed that this option existed, and when I looked it up, I realized it was a game-changer for me:

$ man podman run
…
   --replace
   	If another container with the same name already exists, replace and remove it. The default is false.

Eureka! Have you ever run a container with the --name option and then screwed up the command line option somewhere? The container runs, but it is not what you want:

$ podman run --name test ubi8 echo hello
hello

Oops. I mean to say goodbye:

$ podman run --name test ubi8 echo goodbye
Error: error creating container storage: the container name "test" is already in use by "bd0aff185153c8ae63a876da3fab3010ffdbae5e0413340a62482a49da077336". You have to remove that container to be able to reuse that name.: that name is already in use

Oh no, now I need to remove the container.

The --replace option builds this operation all into a single command:

$ podman run --replace --name test ubi8 echo goodbye
672bcfe2dee6c871f9f8fa8a8a17a8863adff3e322fc282f13fd2c076175620a
d3d1d23782a0daf95654c6b9dbdb3c29c60a0943c0d96d5acfb60bb23b44aaee
goodbye

This option brings me joy.

3. The --all flag

The --all option is also something that I believe you will "all" find useful.

If you google How to stop all Docker containers, you end up with a command like:

# docker stop $(docker ps -aq)

If you ask, How do I remove all Docker containers? the command is:

# docker rm $(docker ps -aq)

Or, How do I remove all Docker images? this command appears:

# docker rmi $(docker images -q)

Yikes, do you have to run a couple of weird Docker commands in a subshell and then execute a parent docker command to actually stop or remove the objects?

If you google How to stop all Podman containers, then this command is shown:

$ podman stop --all

Or, How do I remove all Podman containers?

$ podman rm --all

And what about, How do I remove all Podman images?

$ podman rmi --all

You can remove all containers even if they are running with the Podman command below:

$ podman rm --all -t 0 --force

The --force option tells Podman to stop running containers before removing them, and the -t option tells Podman to immediately send the SIGKILL option to running containers.

That shows why I'm "ALL IN" with the --all option. It's just pretty darn useful.

[ Download the white paper A layered approach to container and Kubernetes security. ]

4. The --ignore flag

Have you ever wanted to remove a group of containers, and you type in:

$ podman rm test1 test2 test3

And get:

Error: no container with name or ID "test1" found: no such container

Sometimes this is an error, or perhaps some other process removed test1, but test2 and test3 still exist. Now you have to edit the command and remove test1. What happens if this happens in a script? Bottom line, you want test1, test2, and test3 gone. You don't care if one of them is already gone.

The Podman team added a --ignore command, which tells Podman to ignore errors when the object does not exist:

$ podman rm --ignore test1 test2 test3
0b739832988300aba6d4423e1cf96d7fc7bc6203543ef4531ba248968800c510
d4ece4d41d0f37e124c46f9436e8569d1fa585e7907f950072ac0ecd688bafb5

All of the podman rm* commands have the --ignore option. I believe this makes scripting commands a lot easier.

5. The --tz flag

Have you ever run a containerized application and found the time zone is wrong?

$ podman run ubi8 date
Thu Feb 3 19:20:31 UTC 2022

Wait, I don't live in England! Why is the time zone set to UTC? Container images have their time zone set within the image. Most images just default to UTC, which works great if you live at the prime meridian, but what about the rest of us?

Podman has a --tz option to set the time zone:

$ podman run --tz=local fedora date
Thu Feb 3 14:21:01 EST 2022

Perfect, I live in Massachusetts, now my time zone is correct. The --tz=local option tells Podman to set the time zone based on the local system's time zone where Podman is running.

You can also pick out any time zone file listed in your system's /usr/share/zoneinfo directory:

$ podman run --tz=Iceland fedora date
Thu Feb 3 19:20:55 GMT 2022

If you want to modify any container you create with a time zone automatically, you can just add a timezone.conf file on your system in /etc/containers/containers.conf.d or $HOME/.config/containers/containers.conf.d that looks like this:

$ cat $HOME/.config/containers/containers.conf.d/timezone.conf
[containers]
tz=”local”

And now Podman will use that time zone in all of its containers:

$ podman run fedora date
Thu Feb 3 14:30:41 EST 2022

Wrap up

These are just simple options added to Podman that I believe make the user experience better and more straightforward. Watch for more articles from the Podman team as we continue to show off the great new features of Podman 3.0. And feel free to submit an article to Enable Architect about your favorite new (or old) features. Email your article idea to enable-sysadmin@redhat.com. 

Quick reference

• --latest (-l): Apply the command to the latest container.
• --replace: Remove the previously named container and create a new container with the same name.
• --all: Perform the command on all Podman objects, containers, images, pods, networks, etc.
• --ignore: Remove the container object and ignore errors when the object does not exist.
• --tz: Set the time zone inside the container.