Creating handy-dandy utility containers
This recipe shows how to use Podman to quickly spin up a container to complete useful tasks.
This recipe will walk you through the process of creating super useful utilities leveraging containers. The basic principle of containers encourages us to formulate our containers to do only one thing – that is, to provide some form of utility and nothing more. You should not create a container that does too much. With that being said, most container images already exist to provide a useful utility. In this recipe, we are going to look at examples of containers that serve a useful purpose, and we’re going to explore how to make use of this.

Getting ready
We will require the following:
• Oracle Linux
• Podman

How to do it…
The main intention of this recipe is to show how we can use containers to achieve a function without installing additional packages on our local machine. Once you have Podman installed on your local machine, you can tap into an entire ecosystem of useful packages and utilities without installing more packages – instead, you simply run a container image that contains those packages, or, alternatively, you create a new container and install the desired packages there.
Why would anyone prefer to do this? For starters, it allows you to minimize the number of packages and dependencies you’re installing on your host machine. With fewer packages, you reduce your attack surface in terms of security. Additionally, your operating system’s repositories might be limited to access to certain packages, or it might not have access to the latest versions. Instead of going through the effort of adding potentially untrusted repositories to install the packages you need, why not simply launch a container that contains everything you need for the specific function you’re trying to achieve?
Before we try to tap into the true potential of containers, we first need to discuss a few important concepts that will make this process a bit easier.
Entrypoint
The entrypoint of a container defines what command the container will run by default. You can find the entrypoint of a container by specifying the inspect command and piping that to jq to extract only the entrypoint.
First, pull the image if you don’t already have it on your system:

$ podman pull docker.io/pandoc/core

Now let’s inspect the image and run jq to query for the entrypoint:

$ podman image inspect pandoc/core | jq -r ‘.[].Config.Entrypoint[0]’

Bonus: Let’s assume we do not have jq installed on our computer. In this case, we can pipe the output of inspect to a container that contains jq:

$ podman image inspect pandoc/core | podman run -i –rm stedolan/jq -r ‘.[].Config.Entrypoint[]’

In either case, the output of this command will be /usr/local/bin/pandoc.
This tells us that when we run the pandoc/core container, the default command that gets executed will be /usr/local/bin/pandoc.
Sometimes, a container’s entrypoint might be a script. For example, you might check for the entrypoint and learn that the entrypoint is docker-entrypoint.sh. You can reveal more about this file by overriding the entrypoint and using cat to see the contents of the file. For example, let’s say we were to inspect the node container image:

$ podman image inspect node | jq -r ‘.[].Config.Entrypoint[]’

We would find that the entrypoint is docker-entrypoint.sh.
Now, let’s override the entrypoint to examine the contents of this file:

$ podman run –rm –entrypoint=/bin/bash node -c ‘cat docker-entrypoint.sh’

In this case, the output is the following:

cat: docker-entrypoint.sh: No such file or directory

This is because in the case of the node image, the docker-entrypoint.sh file is not in the working directory; instead, it is found in the path. So, we’ll try another way to examine this file:

$ podman run –rm –entrypoint=/bin/bash node -c ‘cat $(which docker-entrypoint.sh)’

The output will be as follows:

Figure 11.1 – Output of docker-entrypoint.sh
Now that we know about the default entrypoint, we can use this as we determine what we’re going to do with the container. Sometimes we might want to use the default entry point as intended, whereas other times we might benefit from overriding the default entrypoint to use some other available packages within the container – it all depends on what we’re trying to do.