On: Docker Expands Relationship with Microsoft

[bgorman]

On Linux they aren't even the CLI anymore. Buildah and podman are much better

[stevekemp → bgorman]

The downside to podman is that you lose docker-compose. (Yes I know there is podman-compose, but it isn't as complete.)

docker-compose has issues of its own, but when you can use it then it works really well.

[Macha → stevekemp]

At least for my use case, I haven't really noticed anything missing from podman-compose when I dumped docker-compose for it.

I think ideally they want you to use kube XML for this use case, though I haven't because it doesn't let me associate a named volume with a set of containers. The suggestion is to use bind mounts to the host instead, which feels like an issue for container portability. Podman Compose does not have this limitation

[hiram112 → Macha]

I tried to use the Podman and Podman-compose stack for a large develop docker environment I run locally.

The individual containers build alright, but running the compose with Podman-Compose failed miserably with unhelpful output - just a bunch of Python stack traces. Running it with Docker-Compose just worked.

I think that Docker-Compose is just a lot more lenient with Yaml type errors - where things should and shouldn't be surrounded in quotes. Podman-Compose just needs to be a little more forgiving, and continuing to parse the compose files if the semantics can be assumed, even if the syntax is not perfect.

[boolcow → bgorman]

How are they "much better"? Docker works extremely well. I build and run Docker containers all over the place and they Just Work.

[bgorman → boolcow]

"Docker" is just the userspace component of a Linux kernel feature. "Docker" doesn't run anything, the kernel does.

Podman has three main advantages over docker: Not needing to run as root, not requiring a daemon in the background and being packaged directly by linux distros.

[fulafel → bgorman]

Not so much the distros part, it's not in the latest Ubuntu 20.04 LTS unlike Docker. It's landed in the development branch of Debian though so maybe someday.

(Granted Docker is only in Ubuntu's "universe" section and not as a supported package that would receive security patches etc)

[bgorman → fulafel]

It is in Fedora and Arch. Ubuntu generally doesn't really follow any technologies anyone other than Canonical pushes out.

[boolcow → bgorman]

1. systemd runs as root, doesn't bother me that docker daemon does as well, since they do similar things (for me). Only users with access to the socket file have access.

2. I like the idea of not having a daemon but never actually had a problem with this in practice. The daemon has never crashed on me. systemd also has daemons that have also never crashed on me.

3. It's like 3 lines to install the official docker package. This is a non-issue for me.

Those do not sound like very meaningful advantages. Certainly not significant enough for me to want to switch from something that Just Works.

Thanks for the reply though. I'll be sticking with Docker.

[zapita → boolcow]

The actual advantage of Podman and Buildah is that it is not Docker. Because of the tribal nature of tech communities, that is a desirable property for members of the "anti-Docker" tribe. Everything else is an exercise in retroactively justifying a subjective decision with seemingly objective criteria.

If you don't understand why others are so excited about those tools, it simply means that you're not part of their tribe.

[rtempaccount1 → bgorman]

Podman when not run as root has some significant drawbacks (e.g. containers can't communicate with each other). That's not specific to podman it's just hard to do without root.

Podman has long running processes as well, there's a podman process that'll run once you've launched at least one containner, and a conmon for each container (equivalent to containerd-shim)

Packaged directly... it is by RH and SUSE, don't think by debian/ubuntu. At least for ubuntu, 20.04 packages Docker 19.03 just fine.

[Macha → rtempaccount1]

Containers within the same pod can certainly communicate with each other without root? I'm running that setup right now for my graylog container and it's mongo and elastic search dependencies

[rtempaccount1 → Macha]

Within the same pod sure, they share the same netns. I was talking about individual container comms.

With rootless podman they use slirp4netns and all get the same IP, with rootful podman or Docker a bridge network is established so that containers that aren't in the same pod can communicate with each other.

[scaryclam → bgorman]

Interesting! I now refuse to allow the docker daemon anywhere except a VM on my machine as it does some really stupid things, runs as root etc.

Are there any downsides to podman that you know about?

[yrro → boolcow]

    yrro@host$ podman run --rm -it debian:unstable bash -x -c 'id; cat /proc/self/uid_map'
    + id
    uid=0(root) gid=0(root) groups=0(root)
    + cat /proc/self/uid_map
             0  876099160          1
             1     231073      65536

This is done as a regular user with special rights on the system; all that is required are entries for yrro within /etc/subuid and /etc/subgid. There's no equivalent of Docker's daemon that hands out root on the machine to anyone who can connect to its socket.

[Majestic121 → boolcow]

I had the exact same question, and for podman one of the selling point is that it's a drop in replacement and you don't need root privilege : https://opensource.com/article/19/2/how-does-rootless-podman...

[nikanj → boolcow]

They're newer, and fewer people have heard of them.

[emanlin → boolcow]

Cut out the middle man. They don’t require the Docker daemon for one, which isn’t necessary. The client/server socket interface is the wrong model, the posix userland and filesystem interfaces to the kernel are a much better fit.

[pknopf → boolcow]

Not running as root, for one. There are also many other advantages, such as decoupling the building from the running, and running rootfs tarballs directly, blah blah blah.

[rb808 → bgorman]

I've struggled with podman, esp when following tutorials for docker when podman doesn't quite replicate. Is it worth persisting?

[freedomben → rb808]

Yes, it's definitely worth persisting, especially if you use K8s. Podman can import/export Pod objects with the same API as K8s, so it makes it trivial to run the same k8s yaml locally and in a deployed environment.

[the_duke → freedomben]

Running a light weight Kubernetes setup like k3s locally is a better solution for that use case, imo.

[freedomben → the_duke]

k3s is something I've heard about but know very little. Does it use a VM? I tried skimming their website but couldn't parse that out.

[the_duke → freedomben]

No VM, it is just a light weight distribution of Kubernetes that can be effortlessly installed and run on Linux.

[jkulubya → rb808]

I personally feel that any pain you might face with podman is worth it just for the ability to treat container applications just like any other application on your system

https://www.redhat.com/sysadmin/podman-shareable-systemd-ser...

[harrygeez → bgorman]

so daemonless (tbh I'm not even sure why is this a good thing) and better security through rootless aside, what are some strong points to switch over?

[Macha → harrygeez]

Rootless is really the big selling point for me. Means I can just let gitlab CI log in as a specific user to deploy my personal apps, without someone compromising gitlab/my gitlab account giving them root on my personal servers.

The other advantage is that it can setup containers based on kubernetes xml file or export a local setup to a kube xml file. This is because Podman is really aimed at the small scale setups - if you would have used docker-compose with docker, you might consider Podman, but the export lets you prototype with something convenient locally then export a config when you're happy to test on the big complicated tooling.