Group Swim

Over the years, Docker container software has caused a metaphorical tsunami among software developers and, along with agile principles, improved productivity and DevOps working practices to speed code releases. Docker has had an unprecedented global effect on how applications are built and deployed.

Thanks in part though to an eye-watering rate of evolution in the industry, Docker is no longer the default container software. Some members of the commentariat have unfairly already read the company their last rites. However, in this article, I don't ring the death knell for Docker's fantastic container software, because in my opinion, it is far from receiving its coup de grâce. However, I do look at an alternative to Docker called Podman, its feature set, and some notable differences in its container run time relative to Docker.

Docker Dominance

The first version of Docker [1] was released March 20, 2013. Although containers had already been available on Unix-like systems for a few years, Docker's software allowed small units of code to focus on one specific process to run a single service or perform a single task. By deploying these small code units, software developers improved the portability, consistency, and therefore the predictability of the services and tasks they were running.

As Docker Inc. rode on the crest of their very large wave, containers were invariably the talk of the town. Containers helped shape how architects designed, created, and then deployed their software amid an unremitting level of cloud adoption.

As concepts evolved further, microservices gained consensus as the best way forward, which meant modern software applications were broken down into small, modular, and independently deployable chunks. Soon after, cloud native became the way to discuss complex infrastructure based on microservices deployed in containers with an orchestrator (to help manage multiple containers running at once) in the cloud.

At this point, Google drew on an unparalleled 15 years of production experience running a containerized cluster system called Borg and released the open source Kubernetes orchestrator. On an exponentially growing proliferation of popularity, Kubernetes, akin to Docker's stratospheric rise, soon became the orchestrator of choice and in turn began forging the way that container software was to be used.

Now the Docker container software, after pioneering strides, was no longer the default container software used within the orchestrator, which led to Docker focusing more on the professional services side of its business.

In this article for the purposes of simplicity, I'll assume a container run time is the container software required for actually running containers directly. (See the "Oh, I See … OCI" box.)

Rougher and Tougher

The Podman website [5] greets you with a logo of marine mammals, representing the Kubernetes "pod" (one or more containers), and, hence, the run time's name.

At first glance, Podman is intriguing because it is daemonless; that is, it has no background service and the run time is executed only when requested. From a security perspective, that's good news: Podman offers less attack surface, because it's not running around the clock.

Additionally, Podman is OCI-friendly, helping to propagate the results of hard-fought standards battles in an effort to normalize what containers look like and how they act.

To my mind, however, the most valuable addition to Podman's credentials relates to something else. Unlike Docker, which has made great leaps in the right direction but historically struggled to keep all users happy with security, Podman lets users fire up the run time without being the root superuser. When Podman is run as a less privileged user, it sets up and then enters a user namespace . Once inside, Podman runs as a privileged user (but only with privileges inside that namespace) and has permission to mount certain filesystems and create a container. From a DevSecOps perspective, this means developers can run containers without having superuser permissions.

Believe me when I say that this provides a far higher degree of comfort when it comes to leaving containers running on a system – development and production environments alike – 24 hours a day. By design, Linux has a number of sophisticated mechanisms to help isolate critical functionality and keep it away from less privileged users to ensure that only the root user can affect such services.

The container image format also supports other valuable features: image verification, so you know you're using a trusted container image; container image layer management functionality; pod management (managing groups of containers); and resource isolation between containers.

For the non-Linux aficionados among us, a number of other features are in the planning, such as connecting into remote Mac and Windows systems.

Bigger and Bolder

I'm using the Debian derivative Linux Mint, which harks from Ubuntu 18.04. Detailed Podman installation instructions can be found on GitHub [6]. The instructions offer a number of options, as shown in Figure 1, which details the packages required to build Podman from scratch.

Figure 1: The packages Podman needs on Debian derivatives if installed from scratch [6].

For my install, I take the path of least resistance and use the Personal Package Archive (PPA) as root or with sudo:

$ apt-get update -qq
$ apt-get install -qq -y software-properties-common uidmap
$ add-apt-repository -y ppa:projectatomic/ppa
$ apt-get update -qq
$ apt-get -qq -y install podman

You're helpfully advised to check the build and run dependencies on the install page [7] if you encounter any issues.

If you're concerned about what those commands are doing to your machine, then simply remove the -y (automatic "yes" to prompts) and -qq (logging output) options for more details. To check that all is well following those commands, run:

$ podman --help

If you see lots of output and the minor complaint

WARN[0000] unable to find /etc/containers/registries.conf

don't worry, because I'll fix that problem next.