10 ms·

Podman and Buildah for Docker Users

156 points by devy 7y ago

Proven 7y ago
I wonder if users of non-RPM distros would be eager use these tools. Even if these tools are a little better (maybe they are), my guess would be only medium sized K8s users may find it worthwhile to switch. Large users usually build their own, and small users are lazy to chase incremental improvements (if they do change they'll move to public build services).
- pabs3 7y ago
  It looks like at least two people want buildah/podman on non-RPM distros. buildah recently entered Debian unstable and podman is in the process of being packaged: https://metadata.ftp-master.debian.org/changelogs//main/g/golang-github-containers-buildah/unstable_changelog https://metadata.ftp-master.debian.org/changelogs//main/g/go... https://bugs.debian.org/930440 https://bugs.debian.org/930440
- detaro 7y ago
  (without first-hand experience with it) I could see it being popular with people not going all-in with containers. We have a few machines with services that are conventionally managed and a few services being stuffed into docker containers, and it feels slightly odd that some services are managed through systemd and some through docker commands.
  - viraptor 7y ago
    Why not provide systemd service files for your docker services as well?
    - detaro 7y ago
      guess one could use --interactive calls to docker to keep the process attached maybe? Haven't thought of that before.
  - mclehman 7y ago
    I ended up writing a mostly-declarative tool for managing my mix of docker-composed and init-system-ed services at home when that got too unmanageable.
cabraca 7y ago
They claim "Podman provides a Docker-compatible command line front end and one can simply alias the Docker cli, `alias docker=podman`". That claim alone shows they dont know or dont care how people use container engines outside the k8s space. I know a lot of orgs that simply use docker-compose files to spin up simple setups. There is podman-compose[1] but its "still underdevelopment". Then there is software using the docker socket. Portainer? No Podman support [2] Testcontainers? No Podman support [3] Traefik? No Service discovery for you [4] Should i go on? yeah its rootless and i like the idea podman and buildah represent. What i dont like is the way they break at least part of the ecosystem. [1] https://github.com/containers/podman-compose https://github.com/containers/podman-compose [2] https://github.com/portainer/portainer/issues/2991 https://github.com/portainer/portainer/issues/2991 [3] https://www.testcontainers.org/supported_docker_environment/ https://www.testcontainers.org/supported_docker_environment/ [4] https://github.com/containous/traefik/issues/5730 https://github.com/containous/traefik/issues/5730
- zaro 7y ago
  I think that removing the docker socket is a feature of podman. I never really understood the need for the docker daemon anyway, especially when you are building container.
  - windexh8er 7y ago
    If you are only building a container then you can use BuildKit. But there are plenty of instances where having the socket is extremely useful. For example I've seen plenty of test suites run in a container on a unique host that uses Docker socket to build containers on many other hosts. The Docker daemon used to be required. It has always done a lot of things. I don't understand your comment given the fact minimizing Docker today is easy because functions of container operations have been broken out into unique tools over time. Part of Dockers success, I believe, is that you could do everything in a single install.
    - zaro 7y ago
      > But there are plenty of instances where having the socket is extremely useful. Of course there are plenty of cases where the socket is useful, but you can have the daemon on top of non daemon requiring tools. Which BTW is the direction docker is going in now, when it is an industry standard. >The Docker daemon used to be required. It has always done a lot of things. But initially docker was doing two things only, build a container and run a container. And for both daemon is not required. > Part of Dockers success, I believe, is that you could do everything in a single install. Single install has to do only with packaging, not the architecture or docker.
esamatti 7y ago
> If you are a Docker user, you understand that there is a daemon process that must be run to service all of your Docker commands. I can’t claim to understand the motivation behind this but I imagine it seemed like a great idea, at the time, to do all the cool things that Docker does in one place and also provide a useful API to that process for future evolution. I guess that would be for the Windows and macOS support as it should make things easier implement in a cross platform way when you can just proxy the cli commands to a daemon running in a Linux VM even when you are on Windows or macOS?
- ffk 7y ago
  There were a few reasons for this. The original golang version of docker required root, full stop. There was no difference between the client and server. The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers. A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host. Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself. Source: I was there. :)
  - marmaduke 7y ago
    Since you were there, can you comment on discussions you might have had, where tradeoffs were chosen which would have led to buildah instead of Docker e.g. prioritization on cross platform support? Your comment seems written in a very after the fact way, but surely someone was agonizing overs these choices before they became history.
    - ffk 7y ago
      Sorry for the slow response, just got off an airplane. These were not after the fact. Instead, we knew these were the potential benefits and we moved over. I personally wasn't happy about having to run a daemon to get a container, but we saw the benefits far outweighed the downside for the approach. The other approach on the table was for docker (pre client/server split) to continue requiring sudo. I don't recall anyone suggesting an alternative approach though.
InTheArena 7y ago
Redhat continues to try and eliminate Docker as a competitive threat. Water is wet. They are winning, but it still leaves a bad taste in my mouth. This won't be good over the long run for the Linux community.
- xnxn 7y ago
  Huh. I think that Redhat's work here is a boon to the community. Docker was trying to become synonymous with containerization (they would have me say "dockerization"). We benefit from open specs and multiple implementations.
- freedomben 7y ago
  Do you think it's all about "eliminating Docker as a competitive threat" or is it possible they believe the arguments they put forward? I'm a skeptical person in general, but I try to give the benefit of the doubt and not always assume the worst.
- akdor1154 7y ago
  They are certainly trying to compete with Docker, but are doing so by implementing a (subjectively) superior architecture. The community is winning here.
- ipbabble 7y ago
  I'd like to reiterate that the Podman and Buildah projects were started in order to address business needs for specific risk averse customers. The upstream work we had started with Docker still could not meet those requirements and so investment was started in alternative OCI based approaches that were essentially daemonless and were taking advantage of other enhancements in namespaces and CGroups.
mwcampbell 7y ago
Does Red Hat have a solution for using Kubernetes (or OpenShift) in development? Something similar to Skaffold or Tilt? AFAIK, those tools depend on DOcker to do builds.
- tyingq 7y ago
  Not Redhat provided, but there's Minishift: https://github.com/minishift/minishift https://github.com/minishift/minishift and Codeready Containers: https://github.com/code-ready/crc https://github.com/code-ready/crc
  - Ezku 7y ago
    Anecdotally, both of these were difficult to get to run at all and offered subpar developer experience on macos. :(
    - mroche 7y ago
      What difficulty (or subpar experience) are you running into with CRC? Initially it was a bit weird, but getting up and running is fairly simple. 1) Go to Red Hat’s cloud site (linked on GitHub) and download the latest CRC release and your pull secret. This does require having at least an empty Red Hat account, which may bother some. 2) Extract the release and run `crc setup` and let it do it’s thing. 3) Run `crc start -p /path/to/pull/secret` and wait for it to finish getting up and running. First time this may take 10 minutes, follow up starts 4. You can pass other options as well as needed. 4) Run `eval $(crc oc-env)` and start working with developer:developer credentials (or the provided kubeadmin creds). Use `crc console` to get to the WebUI. We use this on Linux and macOS here just fine for local development and testing. As always, though, YMMV. CRC still has some other quirks that need to be ironed out, but it is generally useable. So far for us the weird parts are the limited self-signed certs and lack of cluster metrics, but both are known issues to the project. And that you can’t have a VPN process running as the startup will restart network services on your system.
alias_neo 7y ago
I've started using podman for my personal projects where I want to deploy just a single service in perhaps a couple of containers on a VM. I rebooted a box one time, and some sort of tracking for the podman networking decided that my listening port was still in use even though no container was running. The only way I fixed it was to uninstall the networking tool podman uses (I forget it's name; slirp4ns or something) and podman itself then reinstall and start again. I use docker daily, professionally, it has it's issues, but a lack of docker-compose like files and anecdotal reliability issues I've seen, I can't see it taking over from, or even competing with Docker for some time yet.
- ipbabble 7y ago
  I'm sure that project would benefit from your feedback and information on what looks like a bug. What did upstream Podman community say? Did they understand your issues? Were they able to reproduce the error? Were they able to fix it?
  - alias_neo 7y ago
    Honestly, I haven't been in touch with the community yet. I needed it working quickly so I solved my issue and I moved on. If it happens again, I'll be expecting it and I'll collect data to report it.
GordonS 7y ago
The only thing I know about podman is that it doesn't require a daemon like docker does. Could someone who knowa more summarize any other benefits over docker?
- mceachen 7y ago
  The article discusses this, but the big win is that podman runs "rootless" (as a role user, not root), which can reduce system security exposure when building images. It also doesn't require a daemon which could be considered a single point of failure.
- coldtea 7y ago
  That's exactly what the article does...
  - GordonS 7y ago
    The article is comparing podman to Docker, and discussion of benefits is largely centred around the part I already know - there is no daemon. I was wondering if those that have actually worked with podman had more insights.
whalesalad 7y ago
I can’t get over the name buildah. It’s so bad.
freedomben 7y ago
Some useful further reading regarding "why" of podman and buildah (for those interested in hearing the case): http://crunchtools.com/docker-support/ http://crunchtools.com/docker-support/ http://crunchtools.com/why-no-docker/ http://crunchtools.com/why-no-docker/ I work for Red Hat, but I find myself pretty centrist on this issue. There's good arguments on all sides. Red Hat isn't doing podman and buildah etc because they want to crush or destroy docker. There are legitimate arguments and they have been open about them. One big one is security. You may think it's overly paranoid to be concerned about having a daemon (especially one running as root, tho rootless docker is either here or near), but keep in mind different people have different requirements. If you're a bank securing billions of dollars, that attack surface is scary.
- InTheArena 7y ago
  I find this argument not very convincing given that I have been in the audience when a red hat engineer who was giving a overview of open shift and related technologies started a presentation and started by making the audience “swear” not to call things docker containers, but just containers. Are there things that would be better with a different model then the runc:containerd? Sure. But is that really the primary factor here? I very much doubt it. Red hat and google wanted docker gone, and have spent the capital to do so. Good business move for open shift, GKE and RHEL, but not necessarily in the long term interest of the open source community.
  - zaro 7y ago
    > Good business move for open shift, GKE and RHEL, but not necessarily in the long term interest of the open source community. But same applies to Docker (the company). In the end, their decisions are also business moves, and they are not necessarily better for the open source community. And they have also proven that they don't always work in the interest of the community - remember the "I don't accept systemd patches" ?
samtrack2019 7y ago
podman doesnt support osx via a vm layer or natively, so that's a deal break for me, docker is really about the developer desktop experience which RedHat (IMO) is not great at.
ipbabble 7y ago
Thanks for all the feedback. I will try to address many of the comments in a follow up blog. I will also try to address some of them here in reply to the comments. First I want to mention a couple of things: 1) My blog didn't recognize the diversity of meanings for "Docker" to the Docker community. This is a problem when there is confusion over Docker company, Docker community, Docker as a collective of products, Docker as a single command line project/product. My blog was specifically focused on Docker CLI users. The Docker command line tool that so many of us grew to love. To say I "don't know our care how people use containers" is an unfortunate conclusion to make. I'm sorry of my restricted use made it seem that way. I will say I wrote all of the original Docker CLI manual pages. So I can claim a very deep knowledge of the Docker CLI. I had to test almost every aspect of the CLI in order to write those manual pages. As a result I filed several bugs too. But I do understand the the Docker CLI is just one part of the tooling that many Docker community users take advantage of. My definition of Docker was limited in my blog. It did not address projects like docker-compose etc. 2) It is unfair to say that Red Hat employees set out to destroy/ruin/whatever Docker. Very early on we wanted to help the Docker community. Red Hat provided a lot of validation to the Docker community by jumping on board and providing a lot of technical expertise and including it in RHEL and OpenShift. People like Dan Walsh and others tried very hard to explain both enterprise features required by risk averse users and also how to build a sustainable inclusive community model. Unfortunately much of our enthusiasm to help make Docker successful, based on our proven track record, fell on deaf ears. Perhaps their was s suspicion that were were looking after our own self interests but it really was a genuine effort to share our experiences in the community. Our open source first approach is always in the interest of the community and our customers and we know that that benefits us too. We know that strong inclusive communities benefit everyone. We sometimes get this wrong. But most times it works out - consider out move from our OpenShift cartridges technology to Docker. We didn't try to kill Docker, we knew it had the right approach. We wanted to make it better through open source community contributions. And we invested in Docker very heavily. Eventually some of our customer concerns with security could not be met with Docker's daemon approach (btw dockerd or containerd) and so wehad to address those requirements. I have continued to talk about the value of Docker to the container community and how they revolutionized the industry because of their unique value add on Linux containers. 3) There are areas that Podman still needs to address. Some hare been worked on - podman-compose and a Mac client etc. Plenty of work to be done. If you're interested then please consider contributing to Podman (libpod) Podman-Compose etc. at https://github.com/containers https://github.com/containers -ipbabble

156 points by devy 7y ago

I wonder if users of non-RPM distros would be eager use these tools. Even if these tools are a little better (maybe they are), my guess would be only medium sized K8s users may find it worthwhile to switch. Large users usually build their own, and small users are lazy to chase incremental improvements (if they do change they'll move to public build services).

pabs3 7y ago
It looks like at least two people want buildah/podman on non-RPM distros. buildah recently entered Debian unstable and podman is in the process of being packaged: https://metadata.ftp-master.debian.org/changelogs//main/g/golang-github-containers-buildah/unstable_changelog https://metadata.ftp-master.debian.org/changelogs//main/g/go... https://bugs.debian.org/930440 https://bugs.debian.org/930440
detaro 7y ago
(without first-hand experience with it) I could see it being popular with people not going all-in with containers. We have a few machines with services that are conventionally managed and a few services being stuffed into docker containers, and it feels slightly odd that some services are managed through systemd and some through docker commands.
- viraptor 7y ago
  Why not provide systemd service files for your docker services as well?
  - detaro 7y ago
    guess one could use --interactive calls to docker to keep the process attached maybe? Haven't thought of that before.
- mclehman 7y ago
  I ended up writing a mostly-declarative tool for managing my mix of docker-composed and init-system-ed services at home when that got too unmanageable.

cabraca 7y ago

They claim "Podman provides a Docker-compatible command line front end and one can simply alias the Docker cli, `alias docker=podman`". That claim alone shows they dont know or dont care how people use container engines outside the k8s space. I know a lot of orgs that simply use docker-compose files to spin up simple setups. There is podman-compose[1] but its "still underdevelopment". Then there is software using the docker socket. Portainer? No Podman support [2] Testcontainers? No Podman support [3] Traefik? No Service discovery for you [4] Should i go on? yeah its rootless and i like the idea podman and buildah represent. What i dont like is the way they break at least part of the ecosystem. [1] https://github.com/containers/podman-compose https://github.com/containers/podman-compose [2] https://github.com/portainer/portainer/issues/2991 https://github.com/portainer/portainer/issues/2991 [3] https://www.testcontainers.org/supported_docker_environment/ https://www.testcontainers.org/supported_docker_environment/ [4] https://github.com/containous/traefik/issues/5730 https://github.com/containous/traefik/issues/5730

zaro 7y ago
I think that removing the docker socket is a feature of podman. I never really understood the need for the docker daemon anyway, especially when you are building container.
- windexh8er 7y ago
  If you are only building a container then you can use BuildKit. But there are plenty of instances where having the socket is extremely useful. For example I've seen plenty of test suites run in a container on a unique host that uses Docker socket to build containers on many other hosts. The Docker daemon used to be required. It has always done a lot of things. I don't understand your comment given the fact minimizing Docker today is easy because functions of container operations have been broken out into unique tools over time. Part of Dockers success, I believe, is that you could do everything in a single install.
  - zaro 7y ago
    > But there are plenty of instances where having the socket is extremely useful. Of course there are plenty of cases where the socket is useful, but you can have the daemon on top of non daemon requiring tools. Which BTW is the direction docker is going in now, when it is an industry standard. >The Docker daemon used to be required. It has always done a lot of things. But initially docker was doing two things only, build a container and run a container. And for both daemon is not required. > Part of Dockers success, I believe, is that you could do everything in a single install. Single install has to do only with packaging, not the architecture or docker.

esamatti 7y ago

> If you are a Docker user, you understand that there is a daemon process that must be run to service all of your Docker commands. I can’t claim to understand the motivation behind this but I imagine it seemed like a great idea, at the time, to do all the cool things that Docker does in one place and also provide a useful API to that process for future evolution. I guess that would be for the Windows and macOS support as it should make things easier implement in a cross platform way when you can just proxy the cli commands to a daemon running in a Linux VM even when you are on Windows or macOS?

ffk 7y ago
There were a few reasons for this. The original golang version of docker required root, full stop. There was no difference between the client and server. The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers. A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host. Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself. Source: I was there. :)
- marmaduke 7y ago
  Since you were there, can you comment on discussions you might have had, where tradeoffs were chosen which would have led to buildah instead of Docker e.g. prioritization on cross platform support? Your comment seems written in a very after the fact way, but surely someone was agonizing overs these choices before they became history.
  - ffk 7y ago
    Sorry for the slow response, just got off an airplane. These were not after the fact. Instead, we knew these were the potential benefits and we moved over. I personally wasn't happy about having to run a daemon to get a container, but we saw the benefits far outweighed the downside for the approach. The other approach on the table was for docker (pre client/server split) to continue requiring sudo. I don't recall anyone suggesting an alternative approach though.

InTheArena 7y ago

Redhat continues to try and eliminate Docker as a competitive threat. Water is wet. They are winning, but it still leaves a bad taste in my mouth. This won't be good over the long run for the Linux community.

xnxn 7y ago
Huh. I think that Redhat's work here is a boon to the community. Docker was trying to become synonymous with containerization (they would have me say "dockerization"). We benefit from open specs and multiple implementations.
freedomben 7y ago
Do you think it's all about "eliminating Docker as a competitive threat" or is it possible they believe the arguments they put forward? I'm a skeptical person in general, but I try to give the benefit of the doubt and not always assume the worst.
akdor1154 7y ago
They are certainly trying to compete with Docker, but are doing so by implementing a (subjectively) superior architecture. The community is winning here.
ipbabble 7y ago
I'd like to reiterate that the Podman and Buildah projects were started in order to address business needs for specific risk averse customers. The upstream work we had started with Docker still could not meet those requirements and so investment was started in alternative OCI based approaches that were essentially daemonless and were taking advantage of other enhancements in namespaces and CGroups.

mwcampbell 7y ago

Does Red Hat have a solution for using Kubernetes (or OpenShift) in development? Something similar to Skaffold or Tilt? AFAIK, those tools depend on DOcker to do builds.

tyingq 7y ago
Not Redhat provided, but there's Minishift: https://github.com/minishift/minishift https://github.com/minishift/minishift and Codeready Containers: https://github.com/code-ready/crc https://github.com/code-ready/crc
- Ezku 7y ago
  Anecdotally, both of these were difficult to get to run at all and offered subpar developer experience on macos. :(
  - mroche 7y ago
    What difficulty (or subpar experience) are you running into with CRC? Initially it was a bit weird, but getting up and running is fairly simple. 1) Go to Red Hat’s cloud site (linked on GitHub) and download the latest CRC release and your pull secret. This does require having at least an empty Red Hat account, which may bother some. 2) Extract the release and run `crc setup` and let it do it’s thing. 3) Run `crc start -p /path/to/pull/secret` and wait for it to finish getting up and running. First time this may take 10 minutes, follow up starts 4. You can pass other options as well as needed. 4) Run `eval $(crc oc-env)` and start working with developer:developer credentials (or the provided kubeadmin creds). Use `crc console` to get to the WebUI. We use this on Linux and macOS here just fine for local development and testing. As always, though, YMMV. CRC still has some other quirks that need to be ironed out, but it is generally useable. So far for us the weird parts are the limited self-signed certs and lack of cluster metrics, but both are known issues to the project. And that you can’t have a VPN process running as the startup will restart network services on your system.

alias_neo 7y ago

I've started using podman for my personal projects where I want to deploy just a single service in perhaps a couple of containers on a VM. I rebooted a box one time, and some sort of tracking for the podman networking decided that my listening port was still in use even though no container was running. The only way I fixed it was to uninstall the networking tool podman uses (I forget it's name; slirp4ns or something) and podman itself then reinstall and start again. I use docker daily, professionally, it has it's issues, but a lack of docker-compose like files and anecdotal reliability issues I've seen, I can't see it taking over from, or even competing with Docker for some time yet.

ipbabble 7y ago
I'm sure that project would benefit from your feedback and information on what looks like a bug. What did upstream Podman community say? Did they understand your issues? Were they able to reproduce the error? Were they able to fix it?
- alias_neo 7y ago
  Honestly, I haven't been in touch with the community yet. I needed it working quickly so I solved my issue and I moved on. If it happens again, I'll be expecting it and I'll collect data to report it.

GordonS 7y ago

The only thing I know about podman is that it doesn't require a daemon like docker does. Could someone who knowa more summarize any other benefits over docker?

mceachen 7y ago
The article discusses this, but the big win is that podman runs "rootless" (as a role user, not root), which can reduce system security exposure when building images. It also doesn't require a daemon which could be considered a single point of failure.
coldtea 7y ago
That's exactly what the article does...
- GordonS 7y ago
  The article is comparing podman to Docker, and discussion of benefits is largely centred around the part I already know - there is no daemon. I was wondering if those that have actually worked with podman had more insights.

whalesalad 7y ago

I can’t get over the name buildah. It’s so bad.

freedomben 7y ago

Some useful further reading regarding "why" of podman and buildah (for those interested in hearing the case): http://crunchtools.com/docker-support/ http://crunchtools.com/docker-support/ http://crunchtools.com/why-no-docker/ http://crunchtools.com/why-no-docker/ I work for Red Hat, but I find myself pretty centrist on this issue. There's good arguments on all sides. Red Hat isn't doing podman and buildah etc because they want to crush or destroy docker. There are legitimate arguments and they have been open about them. One big one is security. You may think it's overly paranoid to be concerned about having a daemon (especially one running as root, tho rootless docker is either here or near), but keep in mind different people have different requirements. If you're a bank securing billions of dollars, that attack surface is scary.

InTheArena 7y ago
I find this argument not very convincing given that I have been in the audience when a red hat engineer who was giving a overview of open shift and related technologies started a presentation and started by making the audience “swear” not to call things docker containers, but just containers. Are there things that would be better with a different model then the runc:containerd? Sure. But is that really the primary factor here? I very much doubt it. Red hat and google wanted docker gone, and have spent the capital to do so. Good business move for open shift, GKE and RHEL, but not necessarily in the long term interest of the open source community.
- zaro 7y ago
  > Good business move for open shift, GKE and RHEL, but not necessarily in the long term interest of the open source community. But same applies to Docker (the company). In the end, their decisions are also business moves, and they are not necessarily better for the open source community. And they have also proven that they don't always work in the interest of the community - remember the "I don't accept systemd patches" ?

samtrack2019 7y ago

podman doesnt support osx via a vm layer or natively, so that's a deal break for me, docker is really about the developer desktop experience which RedHat (IMO) is not great at.

ipbabble 7y ago

Thanks for all the feedback. I will try to address many of the comments in a follow up blog. I will also try to address some of them here in reply to the comments. First I want to mention a couple of things: 1) My blog didn't recognize the diversity of meanings for "Docker" to the Docker community. This is a problem when there is confusion over Docker company, Docker community, Docker as a collective of products, Docker as a single command line project/product. My blog was specifically focused on Docker CLI users. The Docker command line tool that so many of us grew to love. To say I "don't know our care how people use containers" is an unfortunate conclusion to make. I'm sorry of my restricted use made it seem that way. I will say I wrote all of the original Docker CLI manual pages. So I can claim a very deep knowledge of the Docker CLI. I had to test almost every aspect of the CLI in order to write those manual pages. As a result I filed several bugs too. But I do understand the the Docker CLI is just one part of the tooling that many Docker community users take advantage of. My definition of Docker was limited in my blog. It did not address projects like docker-compose etc. 2) It is unfair to say that Red Hat employees set out to destroy/ruin/whatever Docker. Very early on we wanted to help the Docker community. Red Hat provided a lot of validation to the Docker community by jumping on board and providing a lot of technical expertise and including it in RHEL and OpenShift. People like Dan Walsh and others tried very hard to explain both enterprise features required by risk averse users and also how to build a sustainable inclusive community model. Unfortunately much of our enthusiasm to help make Docker successful, based on our proven track record, fell on deaf ears. Perhaps their was s suspicion that were were looking after our own self interests but it really was a genuine effort to share our experiences in the community. Our open source first approach is always in the interest of the community and our customers and we know that that benefits us too. We know that strong inclusive communities benefit everyone. We sometimes get this wrong. But most times it works out - consider out move from our OpenShift cartridges technology to Docker. We didn't try to kill Docker, we knew it had the right approach. We wanted to make it better through open source community contributions. And we invested in Docker very heavily. Eventually some of our customer concerns with security could not be met with Docker's daemon approach (btw dockerd or containerd) and so wehad to address those requirements. I have continued to talk about the value of Docker to the container community and how they revolutionized the industry because of their unique value add on Linux containers. 3) There are areas that Podman still needs to address. Some hare been worked on - podman-compose and a Mac client etc. Plenty of work to be done. If you're interested then please consider contributing to Podman (libpod) Podman-Compose etc. at https://github.com/containers https://github.com/containers -ipbabble