Podman: A Daemonless Container Engine

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • pq

    a command-line Protobuf parser with Kafka support and JSON output (by sevagh)

    I have a Makefile for a Rust project which binds the local repository to a Docker volume, builds it in the container using muslrust, and then does a chown to change the target directory back from root ownership to my own user.

    All I had to do was 's/docker/podman/g' and remove the chown hack and it works fine: https://github.com/sevagh/pq/commit/6acf6d05a094ac2959567a9a...

    It understands Dockerfiles and can pull images from Dockerhub.

  • crun

    A fast and lightweight fully featured OCI runtime and C library for running containers

    Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster:

    https://github.com/containers/crun

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • podman

    Podman: A tool for managing OCI containers and pods.

    Not entirely true.

    I was researching this few hours ago and according to https://github.com/containers/podman/issues/6114#issuecommen... it just works when you add another network.

    Docker registry having no IPv6 is another fun story tho.

  • conmon

    An OCI container runtime monitor.

    Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.

    I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.

  • railcar

    Discontinued RailCar: Rust implementation of the Open Containers Initiative oci-runtime (by drahnr)

  • asciinema

    Platform for hosting and sharing terminal session recordings

    I you'd like to know what it is like to use Podman, I've found those Asciinema snippets by Matthew Heon (Podman contributor) quite helpful: https://asciinema.org/~mheon

  • toolbox

    Tool for interactive command line environments on Linux (by containers)

    One very interesting piece of tech coming from it, is toolbox (https://github.com/containers/toolbox). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local.

    You have root in the container without having root in the host system. That takes care of a lot of issues as well.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • runc

    CLI tool for spawning and running containers according to the OCI specification

  • go

    The Go programming language

    > Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0]

    This was addressed in 2017/2018 [0], it's no longer a poor choice.

    [0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...

  • Moby

    The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

    Alexander Larsson did the lions share of the work on device mapper, and here are 29 PRs to show it:

    https://github.com/moby/moby/pulls?page=2&q=is%3Apr+is%3Aclo...

    In fact, Solomon's own words from https://github.com/moby/moby/pull/2609 "Integrate lvm/devicemapper implementation by @alexlarsson into a driver", so unless you're more knowledgeable about the history than Solomon, I'm going to have to discount your take on this entire thing.

    Regardless, I think things are at a much better place now.

  • docker

    Docker - the open-source application container engine (by alexlarsson)

    It is absolutely not correct that Larsson did the lion’s share. What he did was implement a Go wrapper for libdevmapper, which exposes a very low-level API. It is the Docker team that implemented devmapper-based container storage, as well as the whole storage plugin system which was now required to support more than one storage method. The original devmapper lib is utterly undocumented and Larsson’s wrapper did not fix that. So getting that feature to work was an all-consuming task and it is the Docker team that did the bulk of it.

    You can see all this from the early history of the devmapper directory: https://github.com/alexlarsson/docker/commits/a14496ce891f1f...

  • storage

    Container Storage Library (by containers)

    Docker is properly attributed to, see https://github.com/containers/storage/blob/a4cc7aa79e050c976...

    I think OP wanted to say that Podman hates Docker what is not I feel when I'm interacting with the community there. People who use Podman do it because of it's additional features that Docker does not have, like starting an Container from a rootfs or mounting the currect directory in a container using "." as path. It's a lot of small things that make Podman better.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts