Hacker News Reader

Comment by raesene9 | Hacker News Reader

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.

View on HN

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