Hacker News Reader

Comment by microtonal | Hacker News Reader

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?

View on HN

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-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-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.

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-...

The second link is the same as the first, did you mean to put a different one?

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.

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.

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.

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.)

I just looked at https://github.com/containers/libpod/blob/master/docs/tutori... .

For debian/ubuntu users (of which there are a fair quantity) whilst podman's install process looks like that, I don't see it taking over from Docker any time soon.

Not to mention Windows/OSX users.

Ease of use should not be overlooked when it comes to developer tooling. Podman can be the most technologically advanced solution, but if it's a pain for developers to get going with it, it's not going to replace Docker any time soon...

I agree that developer experience is paramount. I've actively made choices to choose tooling with better developer experience (Rust and Elixir over C++ and Erlang, for instance), and Podman will need to have Debian/Ubuntu packages eventually. If you're on Fedora, openSUSE, or RHEL, though, Podman is a yum/dnf/zypper install away and works quite well (better than Docker in my experience wrt SELinux issues).

>"CI/CD (that needs to build a container)? Use buildah."

Is buildah an alternative to Kaniko then?

Reply on news.ycombinator.com