[Sandbox] Podman Container Tools

[marrusl]

Application contact emails

Brent Baude - [email protected]
Mark Russell - [email protected]
Neil Smith - [email protected]
Preethi Thomas - [email protected]

Project Summary

The Podman Container Tools project consists of Podman (the Pod Manager), Buildah, Skopeo as well as a number of smaller tools which are used to manage containers and images, volumes mounted into those containers, and pods made from groups of containers.

Project Description

At a high level, Podman, Buildah, and Skopeo are a set of tools that provide full management of containers and container images.

• Full management of OCI and Docker images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
• Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
• Full management of container networking, using Netavark.
• Support for running pods.
• Support or portions of the Kubernetes API via podman kube play command
• Support for running containers and pods without root or other elevated privileges.
• Resource isolation of containers and pods.
• Support for a Docker-compatible CLI interface, which can both run containers locally and on remote systems.
• No manager daemon, for improved security and lower resource utilization at idle.
• Support for a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality.
• Support for running on Windows and Mac via virtual machines run by podman machine.
• Buildah code is used by the podman build command but it is also a standalone tool that allows for building images with and without Dockerfiles while not requiring root privileges. The flexibility of building image layers directive by directive allows for the integration of other scripting languages into the build process.
• Skopeo is a command line tool that allows users to perform many useful operations on remote API V2 container image registries, local directories, and local OCI-layout directories. It supports inspecting remote images without requiring you to pull the image locally, copying images between storage mechanisms without privilege, deleting and syncing images.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A

Project repo URL in scope of application

https://github.com/containers/podman

Additional repos in scope of the application

https://github.com/containers/buildah
https://github.com/containers/skopeo

https://github.com/containers/netavark
https://github.com/containers/aardvark-dns
https://github.com/containers/image
https://github.com/containers/storage
https://github.com/containers/common
https://github.com/containers/conmon
https://github.com/containers/podman-py

Website URL

https://podman.io/

Roadmap

https://github.com/containers/podman/blob/main/ROADMAP.md

Roadmap context

The Podman Container Tools project is continually evaluating issues posted to its github repository as well as ideas brought forward by contributors and other open source projects.

Contributing Guide

https://github.com/containers/podman/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

The containers community currently has its own CoC. If accepted, the repos in scope for this application would switch to the CNCF CoC. https://github.com/containers/common/blob/main/CODE-OF-CONDUCT.md

Adopters

No response

Contributing or Sponsoring Org

www.redhat.com

Maintainers file

https://github.com/containers/podman/blob/main/OWNERS

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

Containers are a fundamental part of cloud-native workloads today and are set to evolve to meet the needs of tomorrow. Through the contribution of these cloud-native container tools, users have better and more consistent access between Linux and Kubernetes. These tools provide users an end-to-end cloud-native stack to build, deploy and manage containers at scale across the hybrid cloud.

Projects like Podman are at the center of this innovation for container technologies. That is why, while already a popular project with a strong user base, Podman is being submitted for contribution at the Sandbox level. Podman as a Sandbox project allows for the community to continue growing organically, fostering broader collaboration and growing the diversity of contributors and maintainers - ultimately making it a stronger technology. We believe the CNCF is the place to make this innovation happen.

Benefit to the Landscape

While the CNCF currently hosts many projects that support developer pipelines and packaging, it does not yet have a complete set of user tools for container building and manipulation. Podman and its subprojects, already utilized by several existing CNCF projects, fills this gap. Together with Podman Desktop (if accepted), this gives the CNCF a more complete stack of developer tools for container application development.

Podman and its subprojects tightly integrate with Kubernetes, targeting pod-based container development, with support for Kubernetes workloads, persistent volumes, and ConfigMaps. This allows container application developers to build their containers targeted directly at Kubernetes, and supports an easier dev-to-prod transition. The subproject Buildah provides an OCI-compliant container build tool that is rootless and daemonless by default, making it ideal for use in CI pipelines.

Cloud Native 'Fit'

Today containers and container images are the primary building block of Cloud Native platforms. Podman, like other container runtimes, provides a human and programmatic interface for working directly with containers--from the simplest of tasks to many of the most sophisticated niche use-cases. Podman provides all the functions needed to create, manage, and run containers on a single container host.

Because of how easily it works with pods and Kubernetes YAML, it also can provide a seamless bridge from developer and a single host to a Kubernetes cluster.

Podman is already listed in the Landscape in the Application Definition & Image Build section.

Cloud Native 'Integration'

Podman is compatible, and even currently used with, many CNCF projects. It works with all container registries, including Harbor and Zot. Developer tools such as ArgoCD, Buildpacks, and Dapr already can use Podman as part of their build pipelines. And other CNCF projects like Cert Manager, Keycloak, and Prometheus document Podman support..

Cloud Native Overlap

Podman Container Tools depend on some of the same libraries as CRI-O, a CNCF Graduated project.
The Podman Container Tool Skopeo has similar capabilities to ORAS - a CNCF Sandbox project.
The Podman Container Tool Buildah is similar in capabilities to Stacker - a CNCF Sandbox project and an OCI image builder that uses yaml in place of Dockerfiles.

Similar projects

Docker CLI, Docker Compose, Docker Swarm

Landscape

Yes, in the Application Definition & Image Build and the App Definition and Development sections.

Business Product or Service to Project separation

Downstream Podman is included as a component of Red Hat Enterprise Linux (RHEL), other Red Hat products, and other paid Linux distributions. It is not sold as a standalone product. As such, roadmap priorities, development plans, and release management for Podman have always been carried out entirely in the open source community, and are already completely separate from products. After joining the CNCF, we plan to mentor additional community leadership, which will help ensure independence.

Project Domain Technical Review

The project plans to present to TAG Runtime and will update this application with the recording and notes after that time.

CNCF Contacts

Jorge Castro, Karena Angell, Josh Berkus

Additional information

No response

[dims]

xref: #308

[mrbobbytables]

For the purposes of review, this will be evaluated as a group including: #308 #309 #310 #311

[edrob999]

TAG Contributor Strategy has reviewed this project and found the following:

• Contributor Guide: is Complete, with detailed getting started instructions. The Seal graphic is a welcoming addition for new contributors
• Governance: project does not yet have a written Governance file (this is NOT a blocking issue for sandbox acceptance)
• Roadmap: is incomplete, listing future feature focus. It would be improved with milestones/task breakdown/who-tasks-are-assigned-to/schedule
• Maintainters: Project does not have a Maintainers file, it does have a codeowners file listing 12 approvers and 17 reviewers. Company affiliation for each approver/reviewer are not yet recorded

This review is for the TOC’s information only. Sandbox projects are not required to have full governance or contributor documentation.

[srust]

FYI Podman Container Tools is currently scheduled to present to tag-runtime on Feb. 6th 2025-02-06

[mrbobbytables]

/vote

@dims to follow up

[git-vote]

Vote created

@mrbobbytables has called for a vote on [Sandbox] Podman Container Tools (#309).

The members of the following teams have binding votes:

Team
@cncf/cncf-toc

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 2months 30days 2h 52m 48s. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[dims]

We have 4 applications #308 #309 #310 #311 ... all originating from the same github org originally ... namely https://github.com/containers. Currently github.com/containers does not have a governance model per se.

TOC recommends RedHat teams that are closely aligned to pool themselves into a github org here as well. For example Podman Container Tools and Podman Desktop could easily be under one github with a single governance and multiple subprojects. This makes it more likely for the larger umbrella project to go to incubation and graduation. Also having a well defined governance including definitions of subprojects and contributor ladder and leadership committees makes it easier for folks outside of RedHat to join the effort (and reduces duplicate overload). Another good thing would be having this setup will make it easier for bringing in other adjacent repos like buildah and skopeo which otherwise will not have a decent path to graduation. I hope this makes sense. TOC would like to see this happen as early as possible organically as the different RedHat teams work together coming into sandbox. TOC will look for progress leading up to incubation of these projects that seem to be joined at the hip. We are happy to talk more as needed. Please review the discussion from the meeting recording as well to get the sense of where this guidance is coming from.

Thanks,
Dims