5 ms·

This post links to podman. But the podman website is completely useless, because it does not tell me what it does differently/better than docker, only that

This post links to podman. But the podman website is completely useless, because it does not tell me what it does differently/better than docker, only that What is Podman? Simply put: `alias docker=podman` So, for someone who occasionally uses Docker for running services or creating specific build environments (manylinux1): what are the benefit of podman over Docker?

rmk2 8y ago
Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel... Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel...
- nirv 8y ago
  > Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally? I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1]. [1] https://opensource.com/article/18/10/podman-more-secure-way-run-containers https://opensource.com/article/18/10/podman-more-secure-way-...
- detaro 8y ago
  The second link is the same as the first, did you mean to put a different one?
raesene9 8y ago
for me the problem of the RH container landscape is that it's way more complex for new users than Docker. In docker-land, `apt install docker.io` gets you a working container system with image management, network management and container operation. To get the same functionality on the RH side it is (from what I can see) skopeo+buildah+podman+CNI for networking, then if you want to run that under Kubernetes add in CRI-O Sure for more advanced use cases breaking that all apart could well have benefits, but for ease of getting started, Docker seems better.
- kubeguy 8y ago
  Dev computer? Use podman. Server? Use CRI-O + kube. CI/CD (that needs to build a container)? Use buildah. And use skopeo for copying images around when needed You could argue this makes it more difficult to run containers on the server without kube, and you'd be right. Whether or not that is a bad of red hat to do I'll leave up to others.
  - raesene9 8y ago
    On your dev computer though you might want to .. build containers to confirm that your build steps all work ok, so Podman + buildah, then you might want to ... push them to a repository to collaborate with a colleague without setting up CI/CD, so Podman + Buildah + skopeo. Then you might want to execute the containers to test to see whether your code is running ok.... the point I was making didn't relate to running containers on servers where typically things like CI/CD will be part of the process, but to new developers and devops people getting started with containers.
    - moosingin3space 8y ago
      Podman and Buildah have registry push/pull built in, so technically you don't need Skopeo except in CI. (Honestly I'm still a little unsure what Skopeo's ideal use case is.) Podman also has a `build` subcommand that takes a Dockerfile, so I'd argue if you're on a development workstation where you only use Dockerfiles to build containers, all you need is Podman. (Buildah supports more interesting build pipelines that can be driven without a Dockerfile.)

rmk2 8y ago

Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel... Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel...

nirv 8y ago
> Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally? I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1]. [1] https://opensource.com/article/18/10/podman-more-secure-way-run-containers https://opensource.com/article/18/10/podman-more-secure-way-...
detaro 8y ago
The second link is the same as the first, did you mean to put a different one?

raesene9 8y ago

for me the problem of the RH container landscape is that it's way more complex for new users than Docker. In docker-land, `apt install docker.io` gets you a working container system with image management, network management and container operation. To get the same functionality on the RH side it is (from what I can see) skopeo+buildah+podman+CNI for networking, then if you want to run that under Kubernetes add in CRI-O Sure for more advanced use cases breaking that all apart could well have benefits, but for ease of getting started, Docker seems better.

kubeguy 8y ago
Dev computer? Use podman. Server? Use CRI-O + kube. CI/CD (that needs to build a container)? Use buildah. And use skopeo for copying images around when needed You could argue this makes it more difficult to run containers on the server without kube, and you'd be right. Whether or not that is a bad of red hat to do I'll leave up to others.
- raesene9 8y ago
  On your dev computer though you might want to .. build containers to confirm that your build steps all work ok, so Podman + buildah, then you might want to ... push them to a repository to collaborate with a colleague without setting up CI/CD, so Podman + Buildah + skopeo. Then you might want to execute the containers to test to see whether your code is running ok.... the point I was making didn't relate to running containers on servers where typically things like CI/CD will be part of the process, but to new developers and devops people getting started with containers.
  - moosingin3space 8y ago
    Podman and Buildah have registry push/pull built in, so technically you don't need Skopeo except in CI. (Honestly I'm still a little unsure what Skopeo's ideal use case is.) Podman also has a `build` subcommand that takes a Dockerfile, so I'd argue if you're on a development workstation where you only use Dockerfiles to build containers, all you need is Podman. (Buildah supports more interesting build pipelines that can be driven without a Dockerfile.)