OCI containers with Podman

Group Swim

Peas in a Pod

Podman checks a specific set of container image registries defined in the registries.conf file. I used the example configuration file from the installation help page [6] (Listing 1). As you can see in line 12, the following container image registries are to be searched:

  • docker.io
  • registry.fedoraproject.org
  • quay.io
  • registry.access.redhat.com
  • registry.centos.org

Listing 1


01 # This is a system-wide configuration file used to
02 # keep track of registries for various container backends.
03 # It adheres to TOML format and does not support recursive
04 # lists of registries.
06 # The default location for this configuration file is /etc/containers/registries.conf.
08 # The only valid categories are: 'registries.search', 'registries.insecure',
09 # and 'registries.block'.
11 [registries.search]
12 registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']
14 # If you need to access insecure registries, add the registry's fully-qualified name.
15 # An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
16 [registries.insecure]
17 registries = []
19 # If you need to block pull access from a registry, uncomment the section
20 # below and add the registries fully-qualified name.
21 #
22 [registries.block]
23 registries = []

These registries are called when Podman can't find an image locally or if an image doesn't contain a fully qualified registry name within an image name itself.

Vanilla Pod

Operationally, Podman makes use of libpod to fulfill your container needs and boldly makes no bones about usurping Docker as the run time, inviting you to add the following line to your .bash_aliases (or similar) file so that you don't have to run it each time you open up a new shell or log in to a machine:

$ alias docker=podman

Alternatively, you can just run it at the command line. Once you've done that, you can test Podman. For example, to pull the popular nginx container image, enter:

$ podman pull nginx

Figure 2 shows what happens when the command is run as root. In many cases, the command syntax is similar to Docker's, for an easy transition. To check which containers are running on Podman, you can use a command that looks like a Docker command:

$ podman ps
Figure 2: Pulling a container image from Docker Hub with Podman.

To check out the run-time version and technical innards in a bit more detail, you can use the handy command:

$ podman info

If you look carefully at its output, you'll see which registries your configuration file is pointing at, too.

Now, to run the Nginx container, enter:

$ podman run -dit nginx

In Listing 2, you can see the resulting hash, which appears to indicate that the container is running correctly, although with an error. I'll come back to the error in a moment, but first, I'll check that the container is running as hoped by repeating the podman ps command.

Listing 2

Running Nginx Container

$ podman run -dit nginx
ERRO[0000] could not find slirp4netns, the network namespace won't be configured: exec: "slirp4netns": executable file not found in $PATH

Listing 3 shows that I do have a working container, so I'll deal with the network namespace error now.

Listing 3

Checking the Container

CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS
ba99b8a162e2  docker.io/library/nginx:latest  nginx -g daemon o...  4 seconds ago  Up 3 seconds ago

After another look into namespaces on the installation page, a couple of commands jumped out. To fix the problem, you could try running an echo command as root that allows less privileged users to set up namespaces:

$ echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/userns.conf

However, I suspect the PPA and package installation routes already enabled that functionality, and therefore, it's not the issue in this case.

Monkey Pod

Focusing on the error more closely, the network namespace error indicates that Podman needs network plugins to function correctly. To get networking functionality working, you need to look at the Common Networking Interface (CNI) plugins. The following commands also require you to be the root (or use sudo).

First, download the networking configuration and create a directory for it, if it does not already exist:

$ mkdir -p /etc/cni/net.d
$ curl -qsSL https://raw.githubusercontent.com/containers/libpod/master/cni/87-podman-bridge.conflist | sudo tee /etc/cni/net.d/99-loopback.conf

If you list the files in directory /etc/cni/net.d, you'll see two files:

$ ls /etc/cni/net.d
87-podman-bridge.conflist 99-loopback.conf

Next, install the Go programming language (about 220MB):

$ apt install golang-go

That should provide a sane Go environment for the CNI plugins:

$ git clone https://github.com/containernetworking/plugins.git $GOPATH/src/github.com/containernetworking/plugins

If you have a peek inside the directory now, you should see a build_linux.sh script. Check that it's there, change to its directory, and run the script to build the network plugins:

$ ls $GOPATH/src/github.com/containernetworking/plugins
$ cd $GOPATH/src/github.com/containernetworking/plugins
$ ./build_linux.sh

Once that's completed successfully, you can move the plugins out of the build directory into the cni directory with the following commands:

$ mkdir -p /usr/libexec/cni
$ cp bin/* /usr/libexec/cni

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus