6 ms·

Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta

tirumaraiselvan 8y ago
Does Buildah build images in a completely unprivileged environment? There are other tools like Kaniko which have few gotchas like although they don't need docker daemon but they still need ROOT access which does not make it truly secure.
- Conan_Kudo 8y ago
  Buildah (1.5+) and Podman (1.0+) will work in an unprivileged environment on Linux systems with Linux kernel 4.18+ or kernels with the relevant changes to userns backported (I believe the latest RHEL 7 kernels qualifies here). [To note, I don't work for Red Hat]
  - Qerub 8y ago
    There's some userspace tooling needed as well. E.g. Buildah can't build images as non-rooot on RHEL 7.6 yet because newuidmap/newgidmap is missing. This will get fixed any day now: https://bugzilla.redhat.com/show_bug.cgi?id=1498628 https://bugzilla.redhat.com/show_bug.cgi?id=1498628
    - rhatdan 8y ago
      Look for a backported shadow-utils in RHEL7.7, which is scheduled for the summer. RHEL8.Beta currently supports rootless podman 1.0.
- nijave 8y ago
  Yep, works perfectly on Fedora 29 with podman from the default repos
tandav 8y ago
Docker R.I.P ?
- pjmlp 8y ago
  Around 8 years ago it was all about Puppet and similar, then Docker, K8s, eventually something else will be the next trend.
- erikb 8y ago
  For some reason kubernetes community doesn't like docker. I'm not sure why, though. Afaik Docker was what started the whole container hype, and docker-swarm having some nice features like dependency tracking that I'm personally missing in kubernetes (there's probably a project for that already which I haven't tried out yet, tho).
  - londt8 8y ago
    Google has internal equivalent of docker which they use instead, and they are one of biggest contributors to kubernetes. Im sure there are more reasons though.
  - ch_123 8y ago
    My understanding is that Docker was the preferred container engine for k8s, but Docker did not reciprocate the interest, instead preferring to push Swarm. Having supported Docker in production, I've found that the stability wasn't quite where it needed to be, but Docker Inc. seemed more interested in adding more and more features rather than stabilizing what they already had. I would definitely welcome a less complex base for running containers in production.
  - puzzle 8y ago
    Docker was at times contentious, like when they injected an embedded DNS server into containers of some network types and refused to add a switch to turn that off: https://github.com/moby/moby/issues/19474 https://github.com/moby/moby/issues/19474 That and, a few years ago, the amount of new bugs that would show up when they had to validate a new version of Docker for kubernetes to support. Eventually Docker adopted a less stressful, dual release cycle.
andor 8y ago
The post links to "Podman - The next generation of Linux container tools" (https://developers.redhat.com/articles/podman-next-generation-linux-container-tools/ https://developers.redhat.com/articles/podman-next-generatio...), in which the author notes that Docker "requires anyone who wants to build a container image to have root access. That can create security risks". I'm extrapolating that an advantage of Podman is that it should not require root permissions. But almost every call to podman in the article involves sudo. Can anyone clarify?
- 9034725985 8y ago
  (not a Red Hat employee) My understanding is that many, if not most, operations should not require sudo as of version 1.0. For example, try the commands at https://github.com/containers/libpod/blob/master/docs/tutorials/podman_tutorial.md https://github.com/containers/libpod/blob/master/docs/tutori...
  - edwintorok 8y ago
    In some situations rootless works better, e.g. I was not able to use podman with sudo in a container that had `ping` in it [1]. OTOH rootless uses `fuse-overlayfs` instead of the in-kernel overlay2 driver, and initially I ran into a few bugs since it is not yet a fully POSIX filesystem (much like how the initial overlay kernel driver was buggy , and it wasn't only until overlay2 when it started working reliably with docker). Having said that I've been using only podman as an experiment at home, and upstream is very responsive in fixing bugs. There is also a `vfs` backend that can be used as a fallback until bugs in fuse-overlays get fixed. Would be nice if someone developed a testsuite that exercises all the usual FS operations that a container uses (permissions, setuid, setcap, symlinks, etc.) and compares vfs vs fuse-overlayfs vs in-kernel overlayfs vs docker? [1]https://github.com/containers/libpod/issues/2015 https://github.com/containers/libpod/issues/2015
- atgreen 8y ago
  The author explained that his version of podman (0.9.3) required root, but version 1.0 doesn't. And, indeed, version 1.0 does not. I use it regularly. It's an amazing improvement over the docker tooling. [disclaimer: I work for Red Hat]
fulafel 8y ago
Is there a connection between the RH stack and Podman, would it just work on Ubuntu, Debian or even OS X/WSL?
- dpwm 8y ago
  Given that podman is in Arch Linux's aur[0] – and on their home page they refer to installing it with apt-get (debian) – then I imagine everything is handled in the podman tool, its userspace dependencies and the kernel. I personally look forward to trying it out. [0] https://aur.archlinux.org/packages/libpod/ https://aur.archlinux.org/packages/libpod/
  - Foxboron 8y ago
    Podman was moved to the community repository a few days ago. https://www.archlinux.org/packages/community/x86_64/podman/ https://www.archlinux.org/packages/community/x86_64/podman/
    - aorth 8y ago
      It's news to me! I was maintaining the libpod package on AUR and I just saw the deletion request now. Happy it's in community now, but would have been nice to hear before it got deleted from AUR! Might also want to delete cni-plugins from AUR now that it was also moved to community. https://aur.archlinux.org/packages/cni-plugins/ https://aur.archlinux.org/packages/cni-plugins/
  - deleted 8y ago
    [deleted]
jamp897 8y ago
It would be nice if this was one tool, rather than two overlapping tools with some incompatiblies between them.
- thinkmassive 8y ago
  They can both build images, and the commands may differ, but the resulting images are all compatible. Under the hood podman uses buildah to build images. What's the specific complaint?
  - fyjvd90 8y ago
    In that it adds complexity to have two tools vs one. And in the wild will add risk of mistakes and wasted time due mixups since they overlap and have incompatibilities. I’d rather give a team one tool, the only reason this is two tools is because they were independent projects, but they realy should be one conceptually.
    - ghaff 8y ago
      What you're describing is pretty much contrary to the philosophy behind podman, buildah, skopeo, etc. though which is to have fairly narrowly scoped tools that serve a specific purpose rather than a big application that does everything.
      - fyjvd90 8y ago
        I may not fully understand what the tools can do but it seems overly narrow scoped. Also in that Unix philosophy you don’t duplicate functionality that’s slightly incompatible between tools to the point you need paragraphs and tables to explain when to use which one.
        thinkmassive 8y ago
        Buildah specializes in building OCI images. Podman allows you to pull/run/modify containers created from OCI images. These are distinctly separate tasks, and it seems a lot more straightforward to me than having a daemon (always running, as root...) that handles both tasks. Podman does allow you to build containers, but my suspicion is it’s intended for easier transitioning from docker (you can alias docker=podman and it just works). Also the build functionality is basically an alias for “buildah bud” so it’s more of a shortcut to another application than re-implementing the same functionality. Edit: more reading on the intended uses of each tool if you feel like understanding them better https://podman.io/blogs/2018/10/31/podman-buildah-relationship.html https://podman.io/blogs/2018/10/31/podman-buildah-relationsh...
throw2016 8y ago
This just runs full circle back to the LXC project which Docker 'forked' without attribution in 2013. Run unprivileged , runs daemon less, support layers, advanced networking and more important a standard OS environment. The whole community around containers is not about the technology or understanding how to use them efficiently but who is marketing it and how many layers of complexity and buzzwords can be added on top. A bash script to build containers thus becomes 'declarative' and running a copy of a container becomes 'immutable'. A non standard OS environment, single process environments, the uncontrolled use of layers, ephemeral storage all add dubious layers of complexity to containers for questionable benefit and increase management overhead and fragility at the base of the your stack. Now 5 years later its back to LXC but 'reinvented' by Redhat. So we get another round of hype to reveal the inadequacies that should have been known 5 years ago but throwing no more light on the core issues lest users get wind its just the LXC project in new clothes.
- orf 8y ago
  The the overwhelming success of Docker (released 2013) over LXC (released 2008) is a great counterpoint to your theory that "we've just come full circle and have learned nothing". Clearly we have, and clearly Docker solved a use case that LXC was in no way solving. So no, we are not "back to LXC", we are two generations ahead of LXC.
  - throw2016 8y ago
    Two generations ahead of LXC in which way? There has been no such thing. No point making blanket statements without substantiating them which is exactly what ails the container discussion, hype driven statements with no technical content perpetuating the cycle of misinformation. All the improvements in containers are happening in the kernel, for instance the long awaited support for cgroup namespaces. Improvements in layers will happen in the overlayfs project with better compatibility for filesystems including possible support for NFS. All this work is happening outside the spotlight while userland runs away with the hype and credit.
    - orf 8y ago

Does Buildah build images in a completely unprivileged environment? There are other tools like Kaniko which have few gotchas like although they don't need docker daemon but they still need ROOT access which does not make it truly secure.

Conan_Kudo 8y ago
Buildah (1.5+) and Podman (1.0+) will work in an unprivileged environment on Linux systems with Linux kernel 4.18+ or kernels with the relevant changes to userns backported (I believe the latest RHEL 7 kernels qualifies here). [To note, I don't work for Red Hat]
- Qerub 8y ago
  There's some userspace tooling needed as well. E.g. Buildah can't build images as non-rooot on RHEL 7.6 yet because newuidmap/newgidmap is missing. This will get fixed any day now: https://bugzilla.redhat.com/show_bug.cgi?id=1498628 https://bugzilla.redhat.com/show_bug.cgi?id=1498628
  - rhatdan 8y ago
    Look for a backported shadow-utils in RHEL7.7, which is scheduled for the summer. RHEL8.Beta currently supports rootless podman 1.0.
nijave 8y ago
Yep, works perfectly on Fedora 29 with podman from the default repos

tandav 8y ago

Docker R.I.P ?

pjmlp 8y ago
Around 8 years ago it was all about Puppet and similar, then Docker, K8s, eventually something else will be the next trend.
erikb 8y ago
For some reason kubernetes community doesn't like docker. I'm not sure why, though. Afaik Docker was what started the whole container hype, and docker-swarm having some nice features like dependency tracking that I'm personally missing in kubernetes (there's probably a project for that already which I haven't tried out yet, tho).
- londt8 8y ago
  Google has internal equivalent of docker which they use instead, and they are one of biggest contributors to kubernetes. Im sure there are more reasons though.
- ch_123 8y ago
  My understanding is that Docker was the preferred container engine for k8s, but Docker did not reciprocate the interest, instead preferring to push Swarm. Having supported Docker in production, I've found that the stability wasn't quite where it needed to be, but Docker Inc. seemed more interested in adding more and more features rather than stabilizing what they already had. I would definitely welcome a less complex base for running containers in production.
- puzzle 8y ago
  Docker was at times contentious, like when they injected an embedded DNS server into containers of some network types and refused to add a switch to turn that off: https://github.com/moby/moby/issues/19474 https://github.com/moby/moby/issues/19474 That and, a few years ago, the amount of new bugs that would show up when they had to validate a new version of Docker for kubernetes to support. Eventually Docker adopted a less stressful, dual release cycle.

andor 8y ago

The post links to "Podman - The next generation of Linux container tools" (https://developers.redhat.com/articles/podman-next-generation-linux-container-tools/ https://developers.redhat.com/articles/podman-next-generatio...), in which the author notes that Docker "requires anyone who wants to build a container image to have root access. That can create security risks". I'm extrapolating that an advantage of Podman is that it should not require root permissions. But almost every call to podman in the article involves sudo. Can anyone clarify?

9034725985 8y ago
(not a Red Hat employee) My understanding is that many, if not most, operations should not require sudo as of version 1.0. For example, try the commands at https://github.com/containers/libpod/blob/master/docs/tutorials/podman_tutorial.md https://github.com/containers/libpod/blob/master/docs/tutori...
- edwintorok 8y ago
  In some situations rootless works better, e.g. I was not able to use podman with sudo in a container that had `ping` in it [1]. OTOH rootless uses `fuse-overlayfs` instead of the in-kernel overlay2 driver, and initially I ran into a few bugs since it is not yet a fully POSIX filesystem (much like how the initial overlay kernel driver was buggy , and it wasn't only until overlay2 when it started working reliably with docker). Having said that I've been using only podman as an experiment at home, and upstream is very responsive in fixing bugs. There is also a `vfs` backend that can be used as a fallback until bugs in fuse-overlays get fixed. Would be nice if someone developed a testsuite that exercises all the usual FS operations that a container uses (permissions, setuid, setcap, symlinks, etc.) and compares vfs vs fuse-overlayfs vs in-kernel overlayfs vs docker? [1]https://github.com/containers/libpod/issues/2015 https://github.com/containers/libpod/issues/2015
atgreen 8y ago
The author explained that his version of podman (0.9.3) required root, but version 1.0 doesn't. And, indeed, version 1.0 does not. I use it regularly. It's an amazing improvement over the docker tooling. [disclaimer: I work for Red Hat]

fulafel 8y ago

Is there a connection between the RH stack and Podman, would it just work on Ubuntu, Debian or even OS X/WSL?

dpwm 8y ago
Given that podman is in Arch Linux's aur[0] – and on their home page they refer to installing it with apt-get (debian) – then I imagine everything is handled in the podman tool, its userspace dependencies and the kernel. I personally look forward to trying it out. [0] https://aur.archlinux.org/packages/libpod/ https://aur.archlinux.org/packages/libpod/
- Foxboron 8y ago
  Podman was moved to the community repository a few days ago. https://www.archlinux.org/packages/community/x86_64/podman/ https://www.archlinux.org/packages/community/x86_64/podman/
  - aorth 8y ago
    It's news to me! I was maintaining the libpod package on AUR and I just saw the deletion request now. Happy it's in community now, but would have been nice to hear before it got deleted from AUR! Might also want to delete cni-plugins from AUR now that it was also moved to community. https://aur.archlinux.org/packages/cni-plugins/ https://aur.archlinux.org/packages/cni-plugins/
- deleted 8y ago
  [deleted]

jamp897 8y ago

It would be nice if this was one tool, rather than two overlapping tools with some incompatiblies between them.

thinkmassive 8y ago
They can both build images, and the commands may differ, but the resulting images are all compatible. Under the hood podman uses buildah to build images. What's the specific complaint?
- fyjvd90 8y ago
  In that it adds complexity to have two tools vs one. And in the wild will add risk of mistakes and wasted time due mixups since they overlap and have incompatibilities. I’d rather give a team one tool, the only reason this is two tools is because they were independent projects, but they realy should be one conceptually.
  - ghaff 8y ago
    What you're describing is pretty much contrary to the philosophy behind podman, buildah, skopeo, etc. though which is to have fairly narrowly scoped tools that serve a specific purpose rather than a big application that does everything.
    - fyjvd90 8y ago
      I may not fully understand what the tools can do but it seems overly narrow scoped. Also in that Unix philosophy you don’t duplicate functionality that’s slightly incompatible between tools to the point you need paragraphs and tables to explain when to use which one.
      - thinkmassive 8y ago
        Buildah specializes in building OCI images. Podman allows you to pull/run/modify containers created from OCI images. These are distinctly separate tasks, and it seems a lot more straightforward to me than having a daemon (always running, as root...) that handles both tasks. Podman does allow you to build containers, but my suspicion is it’s intended for easier transitioning from docker (you can alias docker=podman and it just works). Also the build functionality is basically an alias for “buildah bud” so it’s more of a shortcut to another application than re-implementing the same functionality. Edit: more reading on the intended uses of each tool if you feel like understanding them better https://podman.io/blogs/2018/10/31/podman-buildah-relationship.html https://podman.io/blogs/2018/10/31/podman-buildah-relationsh...

throw2016 8y ago

This just runs full circle back to the LXC project which Docker 'forked' without attribution in 2013. Run unprivileged , runs daemon less, support layers, advanced networking and more important a standard OS environment. The whole community around containers is not about the technology or understanding how to use them efficiently but who is marketing it and how many layers of complexity and buzzwords can be added on top. A bash script to build containers thus becomes 'declarative' and running a copy of a container becomes 'immutable'. A non standard OS environment, single process environments, the uncontrolled use of layers, ephemeral storage all add dubious layers of complexity to containers for questionable benefit and increase management overhead and fragility at the base of the your stack. Now 5 years later its back to LXC but 'reinvented' by Redhat. So we get another round of hype to reveal the inadequacies that should have been known 5 years ago but throwing no more light on the core issues lest users get wind its just the LXC project in new clothes.

orf 8y ago
The the overwhelming success of Docker (released 2013) over LXC (released 2008) is a great counterpoint to your theory that "we've just come full circle and have learned nothing". Clearly we have, and clearly Docker solved a use case that LXC was in no way solving. So no, we are not "back to LXC", we are two generations ahead of LXC.
- throw2016 8y ago
  Two generations ahead of LXC in which way? There has been no such thing. No point making blanket statements without substantiating them which is exactly what ails the container discussion, hype driven statements with no technical content perpetuating the cycle of misinformation. All the improvements in containers are happening in the kernel, for instance the long awaited support for cgroup namespaces. Improvements in layers will happen in the overlayfs project with better compatibility for filesystems including possible support for NFS. All this work is happening outside the spotlight while userland runs away with the hype and credit.
  - orf 8y ago