5 ms·

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

by runeks 6y ago

lmeyerov 6y ago
$ for your favorite infra oss startup or volunteer rhel ~forces you to do podman in rhel 8+. They make it hard enough to do a docker install that corp policies will reject docker (non-standard centos 7 repos etc), while allowing ibm's thing. Ex: Locks podman over docker for a lot of US gov where rhel 8 is preferred and with only standard repos, and anything else drowns in special approvals. subtle and orthogonal to podman's technical innovations.. but as a lot of infra oss funding ultimately comes from what enterprise policies allow, this a significant anti-competitive adoption driver for podman by rhel/ibm.
- op00to 6y ago
  Because people can’t install non-Red Hat software due to internal policy, that’s somehow anti-competitive?
  - lmeyerov 6y ago
    The main repos have plenty of non-rhel sw, and people can expend social capital working around IT policies, but that doesn't change it being against the grain. We are fine because we use Ubuntu for the generally better GPU support, but I don't have control over the reality of others. I repeatedly get on calls with teams where this comes up, and I feel sorry for the individuals who are stuck paying the time etc. cost for this. Docker for RHEL 8 is literally installing Docker for Centos 7, so this isn't a technology thing, but political: A big corporate abusing their trusted neutral oss infra position to push non-neutral decisions in order to prop up another part of its business. This is all bizarre to operators who barely know Docker to beginwith, and care more about say keeping the energy grid running. ("The only authorized thing will likely not work b/c incompatibilities, and I have to spend 2w getting the old working thing approved?") And again, none of this is technical. Docker is great but should keep improving, so competitive pressure and alternatives are clearly good... but anti-competitive stuff isn't.
    - mbreese 6y ago
      But RHEL repositories are always out of date, sorry, I mean "stable". The disconnect is when you try to `yum install docker` on a RHEL system, you get an old version. If you want a newer version of Docker, you need to use the Docker provided repositories. But this is the case for all software on RHEL. It's all older and more stable. Try installing any programming language, database, etc... it's always a version or two older in the official RHEL repositories. RedHat written stuff is always going to be more "current" because they control the repositories, but this isn't any different from how any other package is treated. RHEL has always been slow to update. (Which is why Docker created their own repositories in the first place). It makes sense though... because RHEL has to check all packages that are part of their repository. Specifically because things in their repository are safe and stable. There is only so much time to go around testing updates to packages.
      - lmeyerov 6y ago
        Oof I wish more enterprises/govs could do that. In RHEL 8, a team would need to modify their trust chain to include centos 7 / epel to get at the old and still working `yum install` binaries, and that gets into IT signoffs before we even get into discussing updated versions. I'd totally expect a trade-off for old & stable over new and shiny for RHEL: They're getting paid for that kind of neutral & reliable infra behavior. That'd mean RHEL is packaging docker / docker-compose, and maybe podman as an optional alternative. Instead IBM/RHEL is burning IT dept $ and stability by not allowing docker and only sanctioning + actively promoting IT teams use their alternative in unreliable ways.
CraigJPerry 6y ago
It removes a privilege escalation scenario. With docker i can easily gain root, with podman i can’t. Might not be relevant if it’s your own machine though but for $BIG_CORP desktop that might be useful.
otabdeveloper4 6y ago
podman runs out of the box in normal user mode and doesn't require sudo.
- archi42 6y ago
  This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everything (binding some useful folders, fetching/updating our internal image, starting/stopping the actual container and cleaning up,...). Only change necessary to our [Manjaro] environment was adding podman to the package list and a small bash script that generates the `/etc/sub{u,g}id` from our LDAP.
  - eeZah7Ux 6y ago
    > we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?
    - archi42 6y ago
      With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access. I don't see how that contradicts the use of containers? When we only used docker for the CI we didn't have access to them, because escalating to root from within docker is still pretty easy. But with podman they're running with our privileges (and due to gid/uid mapping, I can run our installer "as root" in the container and see if it sets up everthing correctly - while in reality the process runs under my uid). Disclaimer: This is in a professional enviroment. At home I despise containers and prefer to have all my service installed and easily updated by the system's package manager.
greggyb 6y ago
I can't answer the question well, but I think the opposite is just as valid a question: What does a daemon buy you in practice? Why do you need to run the Docker daemon if it is possible (as appears so from podman's existence) to do the same thing without a daemon?

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

by runeks 6y ago

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

$ for your favorite infra oss startup or volunteer rhel ~forces you to do podman in rhel 8+. They make it hard enough to do a docker install that corp policies will reject docker (non-standard centos 7 repos etc), while allowing ibm's thing. Ex: Locks podman over docker for a lot of US gov where rhel 8 is preferred and with only standard repos, and anything else drowns in special approvals. subtle and orthogonal to podman's technical innovations.. but as a lot of infra oss funding ultimately comes from what enterprise policies allow, this a significant anti-competitive adoption driver for podman by rhel/ibm.

op00to 6y ago
Because people can’t install non-Red Hat software due to internal policy, that’s somehow anti-competitive?
- lmeyerov 6y ago
  The main repos have plenty of non-rhel sw, and people can expend social capital working around IT policies, but that doesn't change it being against the grain. We are fine because we use Ubuntu for the generally better GPU support, but I don't have control over the reality of others. I repeatedly get on calls with teams where this comes up, and I feel sorry for the individuals who are stuck paying the time etc. cost for this. Docker for RHEL 8 is literally installing Docker for Centos 7, so this isn't a technology thing, but political: A big corporate abusing their trusted neutral oss infra position to push non-neutral decisions in order to prop up another part of its business. This is all bizarre to operators who barely know Docker to beginwith, and care more about say keeping the energy grid running. ("The only authorized thing will likely not work b/c incompatibilities, and I have to spend 2w getting the old working thing approved?") And again, none of this is technical. Docker is great but should keep improving, so competitive pressure and alternatives are clearly good... but anti-competitive stuff isn't.
  - mbreese 6y ago
    But RHEL repositories are always out of date, sorry, I mean "stable". The disconnect is when you try to `yum install docker` on a RHEL system, you get an old version. If you want a newer version of Docker, you need to use the Docker provided repositories. But this is the case for all software on RHEL. It's all older and more stable. Try installing any programming language, database, etc... it's always a version or two older in the official RHEL repositories. RedHat written stuff is always going to be more "current" because they control the repositories, but this isn't any different from how any other package is treated. RHEL has always been slow to update. (Which is why Docker created their own repositories in the first place). It makes sense though... because RHEL has to check all packages that are part of their repository. Specifically because things in their repository are safe and stable. There is only so much time to go around testing updates to packages.
    - lmeyerov 6y ago
      Oof I wish more enterprises/govs could do that. In RHEL 8, a team would need to modify their trust chain to include centos 7 / epel to get at the old and still working `yum install` binaries, and that gets into IT signoffs before we even get into discussing updated versions. I'd totally expect a trade-off for old & stable over new and shiny for RHEL: They're getting paid for that kind of neutral & reliable infra behavior. That'd mean RHEL is packaging docker / docker-compose, and maybe podman as an optional alternative. Instead IBM/RHEL is burning IT dept $ and stability by not allowing docker and only sanctioning + actively promoting IT teams use their alternative in unreliable ways.

CraigJPerry 6y ago

It removes a privilege escalation scenario. With docker i can easily gain root, with podman i can’t. Might not be relevant if it’s your own machine though but for $BIG_CORP desktop that might be useful.

otabdeveloper4 6y ago

podman runs out of the box in normal user mode and doesn't require sudo.

archi42 6y ago
This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everything (binding some useful folders, fetching/updating our internal image, starting/stopping the actual container and cleaning up,...). Only change necessary to our [Manjaro] environment was adding podman to the package list and a small bash script that generates the `/etc/sub{u,g}id` from our LDAP.
- eeZah7Ux 6y ago
  > we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?
  - archi42 6y ago
    With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access. I don't see how that contradicts the use of containers? When we only used docker for the CI we didn't have access to them, because escalating to root from within docker is still pretty easy. But with podman they're running with our privileges (and due to gid/uid mapping, I can run our installer "as root" in the container and see if it sets up everthing correctly - while in reality the process runs under my uid). Disclaimer: This is in a professional enviroment. At home I despise containers and prefer to have all my service installed and easily updated by the system's package manager.

greggyb 6y ago

I can't answer the question well, but I think the opposite is just as valid a question: What does a daemon buy you in practice? Why do you need to run the Docker daemon if it is possible (as appears so from podman's existence) to do the same thing without a daemon?