Podman: A Daemonless Container Engine • Hacker News Board

Re: Podman: A Daemonless Container Engine

#181

Post by SEJeff » Thu, Feb 11, 2021, 11:27 PM UTC

kbenson wrote: post #152

zapita wrote: post #147

Earlier quoted context omitted.

runc, containerd and the docker client are critical infrastructure to a whole lot of people, and they seem to be doing just fine running it and, when needed, contributing back. Only Red Hat seems to have a problem with using those projects without forking or re-writing them. Could it be because Red Hat considers it of strategic importance for their business, not just for those projects to be reliable (they are), but…

That could be, but if Frazelle did actually walk around with a button saying “I will not merge patches for systemd” I think it's simpler and safer to assume Red Hat decided that relying on Docker was risky given how important it was to their future products and the apparent animus on display from the Docker maintainer. If I carpool with someone and they like to go around and loudly proclaim "I refuse to listen to any…

There is a picture of her badge in this article. It is not something I was alleging. It is fact:

https://lwn.net/Articles/676831/

Re: Podman: A Daemonless Container Engine

#182

Post by dnautics » Thu, Feb 11, 2021, 11:32 PM UTC

johnchristopher wrote: post #160

maweki wrote: post #138

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 contai…

I usually share a volume between containers (eg:: a volume for wp-cli cache, another for -g npm_modules). What benefits would toolbox add ?

a lot of software expects a usable home directory. There was another type of containerization (syos) which was designed for HPC use cases (think deploying 10k nodes doing one thing many times in parallel divvying up and pulling a shared dataset on a academic or industry (pharma), cluster with a high performance distributed filesystem underneath) that did this, however syos is not appropriate for most webscale use.

Re: Podman: A Daemonless Container Engine

#183

Post by kbenson » Thu, Feb 11, 2021, 11:41 PM UTC

SEJeff wrote: post #181

kbenson wrote: post #152

Earlier quoted context omitted.

That could be, but if Frazelle did actually walk around with a button saying “I will not merge patches for systemd” I think it's simpler and safer to assume Red Hat decided that relying on Docker was risky given how important it was to their future products and the apparent animus on display from the Docker maintainer. If I carpool with someone and they like to go around and loudly proclaim "I refuse to listen to any…

There is a picture of her badge in this article. It is not something I was alleging. It is fact: https://lwn.net/Articles/676831/

Sorry, it was poorly worded on my part. I didn't actually doubt that, but prefer not to state other people's assertions as fact unless I know it is so for myself. I prefer to have my assertions grounded by what I'm basing them on, which is less about doubt of the source and more about keeping myself honest when arguing and not taking too hard a stance on stuff I haven't verified myself, since it's easy to come across as authoritative when I don't intend to otherwise.

Thanks for the evidence though, it's always best to have, even if it can be a pain to drum up when it might not really be called into question anyways. :)

Re: Podman: A Daemonless Container Engine

#184

Post by gvalkov » Thu, Feb 11, 2021, 11:46 PM UTC

ddtaylor wrote: post #5

I liked podman for what I was working on with it. The only hangup I found was that it couldn't do networking related routing? Does anyone know more?

Quite a lot is possible with CNI [1]. For example, we use this setup to give real IPs to containers:

  # /etc/cni/net.d/testnet.conflist
  {
    "cniVersion": "0.4.0",
    "name": "testnet",
    "plugins": [
      {
        "type": "bridge",
        "bridge": "br0",  # main host interface is part of this bridge
        "ipam": {
          "type": "host-local",
          "subnet": "10.0.0.0/16",
          "gateway": "10.0.0.1",
          "routes": [{ "dst": "0.0.0.0/0"}]
        }
      }
    ]
  }

You can then start a container and operate on its network namespace for added flexibility:

  podman run -it --net testnet --ip 10.0.0.2 ...

  ns=$(basename $(podman inspect $id | jq -r '.[0] .NetworkSettings .SandboxKey'))
  ip netns exec $ns ip route add ...

[1]: https://github.com/containernetworking/cni

Re: Podman: A Daemonless Container Engine

#185

Post by cpuguy83 » Fri, Feb 12, 2021, 12:09 AM UTC

lima wrote: post #70

SEJeff wrote: post #41

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

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

To be fair, much of runc is written in C as well. And go is really terrible specifically for the case of runc.

Re: Podman: A Daemonless Container Engine

#186

Post by SEJeff » Fri, Feb 12, 2021, 12:18 AM UTC

kbenson wrote: post #183

SEJeff wrote: post #181

Earlier quoted context omitted.

There is a picture of her badge in this article. It is not something I was alleging. It is fact: https://lwn.net/Articles/676831/

Sorry, it was poorly worded on my part. I didn't actually doubt that, but prefer not to state other people's assertions as fact unless I know it is so for myself. I prefer to have my assertions grounded by what I'm basing them on, which is less about doubt of the source and more about keeping myself honest when arguing and not taking too hard a stance on stuff I haven't verified myself, since it's easy to come across…

Sorry the way I replied came off as defensive when it wasn’t meant to be. Your approach is to assume the best and that is always a good one.

Re: Podman: A Daemonless Container Engine

#187

Post by TwoNineFive » Fri, Feb 12, 2021, 12:52 AM UTC

I recently passed the RHCSA exam, which as of last October added a containers/podman section to the test. I usually work with lxcs under libvirt and directly, so working with podman was new to me. The test requirements are very simplistic, but I went further and spent a decent amount of time finding annoyances and issues.

I am not impressed with podman. It's buggy and slow. Documentation is very basic and the underlaying mechanics are not covered where needed. Want to reconfigure the command parameters your start your container with to add a exported variable? Gotta remake the entire setup because there's no edit command.

Re: Podman: A Daemonless Container Engine

#188

Post by gvalkov » Fri, Feb 12, 2021, 1:03 AM UTC

It's great to see how far Podman (and its sister projects) have come. I think it's a reliable tool and I'm a happy user both personally and professionally.

We make heavy use of Podman in our infrastructure and it's mostly a pleasure. My current pet peeves are that:

1) Ansible's podman_container module is not as polished as docker_container. I regularly run into idempotency issues with it (so lots of needlessly restarted containers).

2) Gitlab's Docker executor doesn't support Podman and all our CI agents run on CentOS 8. I ended up writing a custom executor for it and it's working quite well though (we're probably not going back to the container executor even if it supported Podman, since the custom executor offers so much more flexibility).

3) GPU support is easier/more documented on Docker. For this reason, the GPU servers we have are all Ubuntu 20.04 + Docker since it's the more beaten path.

4) Podman-compose just needs more work. Luckily for us, it seems that Podman 3.x will support docker-compose natively [1].

As mentioned, our CI environment is very dependent on Podman. The first step of every Gitlab pipelines is to build the container image in which the rest of the jobs will run. I find that it's simpler to have a shell executor in a unprivileged, restricted environment (i.e. can only run `podman build`) than setting up dind just for building images. All jobs that follow are ran in rootless containers, for that nice added layer of security.

Wishing all the best to the Podman, Buildah and Skopeo teams.

[1]: https://www.redhat.com/sysadmin/podman-docker-compose

Re: Podman: A Daemonless Container Engine

#189

Post by zapita » Fri, Feb 12, 2021, 1:06 AM UTC

kbenson wrote: post #175

zapita wrote: post #159

Earlier quoted context omitted.

It’s no secret that there were tensions betwen Docker and Red Hat that culminated around 2016, when Red Hat’s desire to capitalize on the success of containers ran into Docker’s own ambitions to compete with Red Hat. Those tensions were eventually resolved (or at least diminished) by Red Hat shifting gears to Kubernetes as their “next Linux”. The drama you’re talking about is from that period - 2015-16. But “crun” wa…

> It’s just a tremendous waste of energy > The world’s container infrastructure runs on containerd, runc and docker I don't consider alternate implementations of widely used software to be wasted evergy almost ever. Was Clang a waste of energy because everyone was using GCC? There are many reasons why multiple implementations may be useful, competition and being able to cater to slightly different common use cases ob…

That’s fair, there’s always a benefit to alternate implementations. I think those were started for the wrong reasons (interpersonal conflict rather than technical requirements) but perhaps in the end it doesn’t matter.

Re: Podman: A Daemonless Container Engine

#190

Post by zapita » Fri, Feb 12, 2021, 1:18 AM UTC

SEJeff wrote: post #180

zapita wrote: post #164

Earlier quoted context omitted.

Your history is wrong. Docker created the OCI, not Red Hat. Docker donated both the spec and the runc implementation. Containerd was donated (also by Docker) to CNCF, a different organization, and I believe a few years later. You are correct that Docker did those things because of pressure to be more interoperable. Reading your linked tweet (“don’t mess with an engineering behemoth”) you seem to agree that Red Hat is…

Docker and Redhat were both founding members of OCI. CoreOS probably was responsible for a lot of the initial conversations. They wanted a standardized container runtime after finding some limitations in docker which caused them to create rkt. Docker inc wasn’t super into changing anything and as history as shown, wasn’t terribly into working well with others. The industry was going to move forward without them but t…

I understand what you’re saying but it is incorrect. Docker was in fact the originator of OCI in every way that matters. They made the decision to create it; drafted the founding documents and went back and forth with Linux Foundation on the content; chose the names (initially OCF, then later OCI); negotiated with LF the governance structure and initial board composition; negotiated the list of external maintainers with commit access, including a Red Hat and CoreOS employee; chose the announcement date and venue; drafted the announcement content along with LF; coordinated with PR teams of other founding members. All this in addition to being the original authors of both the spec and implementation.

Neither Red Hat nor CoreOS were involved in any of those steps, nor were they even aware of them until the last minute. When they were invited it was on a “take it or leave it” basis. They took it, then tried to pre-empt the Docker/LF announcement by a few hours to make it look like they were launching it. Those were tense days and there was very little trust between those companies.

Source: I was involved in the process of creating OCI.