Essay 1: Context and Product Vision

If you are new to Docker, containers, daemons and/or Kubernetes, please follow the links to familiarise yourself with these concepts before reading. Very basic introduction videos can be also found here for Docker and Kubernetes.

Containers play a crucial role nowadays in simplifying the production, distribution, discoverability, and usage of applications with their dependencies and default configuration files. There is nothing worse than struggling with dependency or configuration bugs only to explain to yourself that ‘it works on my machine’. Podman provides a container management option for seamless deployment and improving the local development experience.¹ Podman is a daemonless container engine for developing, managing, and running Open Container Initiative (OCI) Containers on Linux Systems. It offers a solid alternative to other daemon-based container management tools like Docker and Kubernetes, with valuable features such as running containers in either root or rootless mode.² Switching workflow from Docker to Podman requires little effort and has a set of key advantages, which we describe in this essay along with the broader context and product vision of Podman.³

Initially released back in 2018 by the Red Hat company without many of the features that now make it stand out from its alternatives, the Podman initiative has gone through a long cycle of technical, compatibility, and accessibility improvements, which now make it one of the most appealing container orchestration tools available. The initial scope of Podman, to provide a specialised container management suite for Red Hat’s Enterprise Linux OS, has long been surpassed. Podman is now available for most large-scale Unix-based systems, including the most popular Linux distributions and macOS, greatly exceeding the initial product vision. Leveraging Red Hat’s low-level component design expertise, Podman is now moving toward providing more versatile features, improving the API implementation, and refining current features to improve the product’s usability and general appeal.⁴

We observe that Docker is more widely adopted. This is because Docker was the first containerisation solution to help standardise container technology and be adopted by others. This helped large organisations to move away from proprietary solutions.⁵ On top of that, the early version of Docker was used by beta banks⁶, which is quite remarkable as these institutions tend to be conservative with picking their technology stacks. While this is great, Docker uses a daemon which is a heavy process, which Podman creators sought to eliminate and provide a standardised alternative without a daemon.

Container Concepts

To fully understand the benefits of Podman, we need to explain some key domain concepts:

• An image is an unchangeable, static file that includes executable code to run an isolated process on IT infrastructure, which can be pulled from the registry from a provider.⁷
• A container is the runtime instantiation of a container image.⁷
• The Open Container Initiative (OCI)⁸ is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes.
• A pod is a group of containers. Podman pods are like Kubernetes pods in the sense that they can hold one or more containers at a time. If something on the pod breaks, it can be replaced with a copy of the setup.⁷
• A daemon is a service process that runs in the background and supervises the system or supplies functionality to other processes. Some container managers, such as Docker and LXD, use this mechanism for directly handling building, running, and distributing containers.
• Some container managers use an API to remotely interact with containers and perform management operations.⁹
• Podman uses the Fork/Exec model for running containers, which runs processes directly on the container kernel and this is the main difference between Podman and Docker, which uses the client/server model. It allows Podman to launch containers as a non-root user, which brings more security than the client/server model.¹⁰

When is Podman used?

The typical user of this tool would be individual developers or DevOps teams who require a single tool for container management. Developers and DevOps engineers can create pods and containers that are not only using Docker and Kubernetes as platforms that provide flexibility. It can also be used by DevOps engineers to define access rights, set up pods and containers in one tool ready for recreating clusters for Kubernetes and deploying to production.

Podman’s capabilities are¹¹:

• Creating, running, managing, and developing OCI containers, container images, and pods
• Providing privileged and unprivileged container access and creation
• Supporting multiple container image formats
• Supporting Docker images and its API supporting Docker API
• Managing and creating pods for Kubernetes

Podman’s Context

Podman can operate in contexts as small as individual usage and as large corporate production environments, offering a sound solution for any use case requiring that software is deployed or run in a domain isolated from the host machine.

Podman’s use case for individual software developers is to create lightweight containers for the software they have made to recreate an isolated production environment to analyse the system’s behaviour. These containers can be automatically and reliably recreated and thus effortlessly shared with other people. If users have multiple containers that need to run on a single host, they can set up a pod. This aids developers in circumventing the tedious configuration process often required by other solutions such as Virtual Machines.

On a large scale, these containers can be placed into pods that can be configured and managed by Podman. Since these environments exist in isolation, they can be moved to the cloud, where they can be deployed, recreated, destroyed, and replaced. Podman allows remotely managing containers and pods, and since these environments are small, they can be set up much more cheaply and quickly in the cloud rather than setting up entire VMs, which could be cumbersome and have less predictable behaviour. Unlike Docker, containers and pods can be set up in either privileged or unprivileged modes.¹¹

Moreover, other open-source tools like crun, runC and Buildah facilitate the subprocesses of the container management toolset for Podman that also follow the OCI standards.

Who is behind Podman?

The Podman project has distinct categories of stakeholders, which can be divided into three specific subgroups. This section analyses the three main stakeholder categories and what they might expect from and contribute to the system.

The first and most influential category is composed of project developers from the Red Hat company. Initially bundled with the Red Hat Enterprise Linux (RHEL) 7.5.1 operating system ¹², Podman is Red Hat’s solution to the problem of secure and lightweight containerisation. This means that developers within the company have the most experience with the system’s evolution and hold the most influence over design and direction decisions. This is relevant not only for open-source contributors whose requests and suggestions may be overruled by company decisions but also for end users, who enjoy privileged enterprise technical support provided by Red Had for its operating systems.¹³

The second group of stakeholders consists of open-source contributors, many of whom are part of the OCI community. With open channels of communication and transparent contribution guidelines, individuals interested in expanding the Podman project are free to do so. Contributions range from simple bug reports and feature requests to concrete implementations and bug fixes. Although the project’s open-source nature is one of its fundamental attributes, the individual contributors are bound by the priorities and decisions set up by the project coordinators at Red Hat.

Finally, the third and perhaps most volatile group of stakeholders is made up of individual end-users. Both individuals and enterprises can freely use, distribute, and modify Podman under its Apache 2.0 License. Both categories of users enjoy access to the same level of functionality and documentation, although technical support for users using Red Hat’s complementary software environments may be more advanced.

What makes Podman unique?

There are many quality attributes a project like this should adhere to, to make it successful, including the attributes that Docker meets, such as described by earlier projects.¹⁴ We provide an overview of the characterisations of the critical quality attributes that specifically the Podman system must meet to stay a viable alternative, based on the descriptions of these attributes from Pautasso.¹⁵

As Podman markets itself as a direct replacement for any container orchestration tool like Docker, compatibility is the most important quality attribute. Hence, the alias docker=podman. All basic features of Docker are expected to be continuously maintained such that the switch between tools delivers the same results and is easy to integrate. Along with the Docker interface, Podman has interoperability according to the OCI specifications, which it should consistently follow.

Podman’s architecture also provides an essential level of modularity, where all different components that are used for the CLI tool are separate projects, such as Buildah, runC and crun, maintained by the container’s community.

Another key quality attribute is security since the deamonless and rootless architecture that distinguishes Podman from Docker provides a mechanism against attacks. By running containers with the user namespace of the executer, a layer of traceability is added, which protects the system’s integrity. Because Docker designed their architecture around their daemon from the start, this architecture was kept because many of their subsystems were designed around it.¹⁶ This allowed Podman to set a unique and more secure alternative as the goal for the project that would circumvent the usage of a daemon.

All these attributes should be adhered to over time, and the project needs to be flexible to react to changes in the OCI specifications if its stakeholders decide upon this. Therefore, it is vital that the source code is sustainable and can change in the future, which is something to keep in mind when contributing new features and components.

Podman’s roadmap

Although heavily involved in Podman’s development, the Red Had company does not provide a detailed overview of the system’s future. Instead, the crucial focus points are highlighted in the project repository. Currently, three directions are at the foreground of development:

1. The refinement of the REST API, focusing on adding functionality and fixing known bugs.
2. The improvement of rootless container functionality, including enhancing the user experience and exposing additional internal features.
3. The improvement of the Pods’ functionality, including resource limitation.

Although anyone is free to contact the development team and propose new features or improvements, the Red Hat project maintainers ultimately decide the production direction. However, the interests of the community and those of the developers often overlap, with many individual feature proposals being actively implemented. In addition to planned improvements, adaptability to contextual changes which affect Podman’s primary use cases is also an important part of the project’s future.

Ethical considerations

Creating a more secure alternative for container management, an increasingly more popular and used practice, is an excellent development for the users’ deployment needs.

The development process and the program specifications are well-defined for Podman, which has good documentation for the code and contributing process and active maintainers who review changes thoroughly. They also have a special procedure for identifying security threats and resolving them with minimal damage. However, since Red Hat owns Podman, they could decide to abandon the project due to a change in priorities. This can cause Podman to lose much of its core contributor base, who are Red Hat employees, which would result in immense knowledge loss. Another possibility is that the project could follow the user license/subscription route which caused companies or open-source enthusiasts to search for or build alternatives and drop Docker.

Lastly, balancing incoming requests can be a challenging task and with a minimal roadmap for the future. This can lead to uncertainty in the product direction and its development.

Conclusion

In this essay we introduced the context and product vision of Podman. It provides a great alternative for Docker and offers a directly interchangeable option with a large set of features and improved security. It has a thriving community of users and developers that benefit from the #nobigfatdaemons experience.

In the next essays we dive deeper into the architectural decision details of Podman and its relevant subsystems.

References: