Add these 4 tools to your Linux container toolbox

When you need the right tool, there's nothing like going to your local hardware store and walking the aisles. It's great to go down the hand tools aisle and check out all the screwdrivers, hammers, hex wrenches, tape measures, and more. Just when you think you've discovered the right tool, a thought hits you, if I can do it with a hand tool, I can really get it done with the perfect power tool!

At least that's what my wife tells me, and you see, she's the handy person in our family. My tools of choice are tech tools. Give me an aisle of video cards at a computer store, and I'm a happy camper.

Recently I did a demo at the Podman Community Meeting showing off some of the shinier new container tools that we've developed for Podman and Buildah. We've had many big announcements with Podman v3.0, so I thought some of these tools might have been overshadowed. As I received some nice feedback from that demonstration, I felt a follow-up post might be helpful too. So let's dive in and break out these shiny new container tools.

Change the first FROM in your Containerfile

There's a new --from option in the buildah bud command that will soon make its way into Podman v3.0. This option allows you to replace the value associated with the first—and only the first—FROM statement in the Containerfile. For instance, if we have this Containerfile:

# cat ~/Containerfile.multifrom
FROM fedora as builder
FROM busybox
COPY --from=builder /bin/df /tmp/df_tester

We can do an initial run, and it will show that we used the fedora container image. Then the busybox image is used and then finally copying the files from fedora's /bin/df directory into the busybox images' /tmp/df_tester directory.

# buildah bud -t multi -f ~/Containerfile.multifrom .
STEP 1: FROM fedora AS builder
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Getting image source signatures
Copying blob 157ab8011454 done  
Copying config 9f2a560376 done  
Writing manifest to image destination
Storing signatures
--> 9f2a5603764
STEP 2: FROM busybox
Resolved "busybox" as an alias (/root/.config/containers/short-name-aliases.conf)
Getting image source signatures
Copying blob 4c892f00285e done  
Copying config 22667f5368 done  
Writing manifest to image destination
Storing signatures
STEP 3: COPY --from=builder /bin/df /tmp/df_tester
STEP 4: COMMIT multi
Getting image source signatures
Copying blob 6b245f040973 skipped: already exists  
Copying blob 9b68b051b385 done  
Copying config 187c956137 done  
Writing manifest to image destination
Storing signatures
--> 187c9561378
187c9561378efb043dfd0e8fa9c0afbdc0cf2faeb244e0dd7f2003321feab524

Now imagine a more real-world situation, one where your FROM statement points to a custom-built image with a variety of tags for different versions of the image. It would be nice, especially in a CI environment, to just pass in the container image that you want to use on the next run rather than recreate the entire Dockerfile. That's the job that --from fills.

In this example, we'll run the same bud command, but this time we'll add --from alpine:latest.

# buildah bud -t multi -f ~/Containerfile.multifrom --from alpine:latest .
STEP 1: FROM alpine:latest AS builder
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Getting image source signatures
Copying blob 4c0d98bf9879 done  
Copying config e50c909a8d done  
Writing manifest to image destination
Storing signatures
--> e50c909a8df
STEP 2: FROM busybox
STEP 3: COPY --from=builder /bin/df /tmp/df_tester
STEP 4: COMMIT multi
Getting image source signatures
Copying blob 6b245f040973 skipped: already exists  
Copying blob b498f23d5c32 done  
Copying config d7e92107ed done  
Writing manifest to image destination
Storing signatures
--> d7e92107edf
d7e92107edf42f046f6a7faddade4825ef1c2361ae21eb0ac3694871dcdb496c

You can see that the alpine:latest container image was first used, and now after the busybox image was created, the files from alpine's /bin/df were copied into the /tmp/df_tester directory on busybox. The value of the first FROM statement in the Containerfile was replaced with the argument that we passed with the --from option.

[ You might also like to read: Rootless containers using Podman ]

Accept input during a build

Another new tool is the --stdin option that goes along with buildah bud or podman build (as of Podman v3.0). When you use this option, the build process will pause and ask for keyboard input if the process running during the build procedure asks for it.

Take a look at this Containerfile:

# cat /root/Containerfile.stdin
FROM ubi8
RUN yum install iputils
RUN touch /tmp/done

This Containerfile uses the ubi8 image and then installs iputils. As you can probably guess, the yum command will ask us to verify the installation of iputils. Let's look at what happens without the --stdin option in play.

# cat /root/Containerfile.stdin
FROM ubi8
RUN yum install iputils
RUN touch /tmp/done

# cat /root/Containerfile.stdin
FROM ubi8
RUN yum install iputils
RUN touch /tmp/done

# buildah bud -t mystdin -f ~/Containerfile.stdin .
STEP 1: FROM ubi8
Resolved "ubi8" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Getting image source signatures
Copying blob d9e72d058dc5 done  
Copying blob cca21acb641a done  
Copying config 3269c37eae done  
Writing manifest to image destination
Storing signatures
STEP 2: RUN yum install iputils
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

Red Hat Universal Base Image 8 (RPMs) - BaseOS  2.5 MB/s | 774 kB     00:00    
Red Hat Universal Base Image 8 (RPMs) - AppStre 7.6 MB/s | 5.0 MB     00:00    
Red Hat Universal Base Image 8 (RPMs) - CodeRea  75 kB/s |  13 kB     00:00    
Dependencies resolved.
================================================================================
 Package        Architecture  Version                 Repository           Size
================================================================================
Installing:
 iputils        x86_64        20180629-2.el8          ubi-8-baseos        149 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 149 k
Installed size: 361 k
Is this ok [y/N]: Operation aborted.
error building at STEP "RUN yum install iputils": error while running runtime: exit status

When yum installed iputils, it asked for a confirmation and failed as it never received a response. Now let's look at what happens with the --stdin option in play.

# buildah bud -t mystdin --stdin -f ~/Containerfile.stdin .
STEP 1: FROM ubi8
STEP 2: RUN yum install iputils
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

Red Hat Universal Base Image 8 (RPMs) - BaseOS  2.8 MB/s | 774 kB     00:00    
Red Hat Universal Base Image 8 (RPMs) - AppStre 7.5 MB/s | 5.0 MB     00:00    
Red Hat Universal Base Image 8 (RPMs) - CodeRea  86 kB/s |  13 kB     00:00    
Dependencies resolved.
================================================================================
 Package        Architecture  Version                 Repository           Size
================================================================================
Installing:
 iputils        x86_64        20180629-2.el8          ubi-8-baseos        149 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 149 k
Installed size: 361 k
Is this ok [y/N]: y

It doesn't come across as well in a blog as in person, but the build process stops at the line Is this ok [y/N]: and I entered the character y and the build continued (see below output).

Downloading Packages:
iputils-20180629-2.el8.x86_64.rpm               972 kB/s | 149 kB     00:00    
--------------------------------------------------------------------------------
Total                                           952 kB/s | 149 kB     00:00    
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Installing       : iputils-20180629-2.el8.x86_64                          1/1
  Running scriptlet: iputils-20180629-2.el8.x86_64                          1/1
  Verifying        : iputils-20180629-2.el8.x86_64                          1/1
Installed products updated.

Installed:
  iputils-20180629-2.el8.x86_64                                                

Complete!
STEP 3: RUN touch /tmp/done
STEP 4: COMMIT mystdin
Getting image source signatures
Copying blob 92538e92de29 skipped: already exists  
Copying blob eb7bf34352ca skipped: already exists  
Copying blob f9ed641975cb done  
Copying config b2742f08a7 done  
Writing manifest to image destination
Storing signatures
--> b2742f08a7a
b2742f08a7ae2cb76a2cd0c481f2d2d66b303379d23e5260577ea09476a8a486

This is another simplistic example, especially since you could add a -y argument to the yum command. Still, there might be other commands that you'd like to run during the build process that you'd like to get more significant input into easily.

Find the tags for a container image

This next tool that's relatively new to Podman shows all of the tags for a container image on a registry. I use images on quay.io for Buildah, Podman, and Skopeo, and sometimes I want to use a particular version of one of the projects and can't remember which is out there. If you're familiar with Skopeo, it works really well in this space. But if you've not installed Skopeo locally, or can't for some reason, then the new --list-tags option for the podman search command is your ticket.

So let’s look at all of the tags that the stable Podman image has on quay.io:

# podman search --list-tags quay.io/podman/stable
NAME                   TAG
quay.io/podman/stable  v1.4.4
quay.io/podman/stable  v1.4.2
quay.io/podman/stable  v1.5.1
quay.io/podman/stable  v1.5.0
quay.io/podman/stable  v1.6.2
quay.io/podman/stable  auto
quay.io/podman/stable  v1.6
quay.io/podman/stable  v1.9.0
quay.io/podman/stable  v1.9.1
quay.io/podman/stable  v2.0.2
quay.io/podman/stable  v2.0.6
quay.io/podman/stable  v2.1.1
quay.io/podman/stable  master
quay.io/podman/stable  latest

Quick, easy, and handy.

Using the Skopeo container image

This tool is kind of the ying to the last tools yang. The Skopeo project is filled with many tools to use with container images. It, too, will show you the list of tags that an image has on a registry. Skopeo can also display information about a registry, allow you to copy a container image between storage mechanisms including registries, synchronize a container registry, delete an image from a registry, and more.

Now I'm not going to dive into each of these Skopeo commands here. I'm just going to do the search capability to show the tags. The twist is I'm only going to use Podman to run the quay.io/skopeo/stable:latest image, therefore removing the need to have Skopeo installed yet still have all of its functionality available.

So let's list the tags of the quay.io/podman/stable:latest image again, but this time via the Skopeo container image:

# podman run quay.io/skopeo/stable:latest list-tags docker://quay.io/podman/stable
Trying to pull quay.io/skopeo/stable:latest...
Getting image source signatures
Copying blob 6629904ed3b7 done  
Copying blob 2b74ed94761c done  
Copying blob 692512e477a1 done  
Copying blob 166a3cbbffd1 done  
Copying blob b1e90be38d32 done  
Copying blob a5dc7d6cfd62 done  
Copying blob a3ed95caeb02 done  
Copying blob a3ed95caeb02 done  
Writing manifest to image destination
Storing signatures
{
    "Repository": "quay.io/podman/stable",
    "Tags": [
        "v1.4.4",
        "v1.4.2",
        "v1.5.1",
        "v1.5.0",
        "v1.6.2",
        "auto",
        "v1.6",
        "v1.9.0",
        "v1.9.1",
        "v2.0.2",
        "v2.0.6",
        "v2.1.1",
        "master",
        "latest"
    ]
}

The first time you run this command, it is slower than Podman's equivalent as you incur the cost of the skopeo container image being pulled. After that, the speed is equivalent on secondary runs, and then you can do any other Skopeo command that you want to also.

I'll let you explore further on your own, and I'd suggest starting your exploration with Valentin Rothberg's How to run Skopeo in a container.  I think the Skopeo container image is the shiniest tool in my container toolbox.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

All the shiny new tools

Now my wife can still have all of her shiny tools from the local hardware store, and I'll keep my new container tools in my virtual toolbox. I hope you find these new commands and options to be useful in your own toolbox.