4 ms·

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

rb808 6y ago
I've struggled with podman, esp when following tutorials for docker when podman doesn't quite replicate. Is it worth persisting?
- freedomben 6y ago
  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 6y ago
    Running a light weight Kubernetes setup like k3s locally is a better solution for that use case, imo.
    - freedomben 6y ago
      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 6y ago
        No VM, it is just a light weight distribution of Kubernetes that can be effortlessly installed and run on Linux.
- jkulubya 6y ago
  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-services https://www.redhat.com/sysadmin/podman-shareable-systemd-ser...
harrygeez 6y ago
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 6y ago
  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.
boolcow 6y ago
How are they "much better"? Docker works extremely well. I build and run Docker containers all over the place and they Just Work.
- nikanj 6y ago
  They're newer, and fewer people have heard of them.
- pknopf 6y ago
  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.
- Majestic121 6y ago
  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-work https://opensource.com/article/19/2/how-does-rootless-podman...
- bgorman 6y ago
  "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.
  - boolcow 6y ago
    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.
stevekemp 6y ago
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 6y ago
  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 6y ago
    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.

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

freedomben 6y ago
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 6y ago
  Running a light weight Kubernetes setup like k3s locally is a better solution for that use case, imo.
  - freedomben 6y ago
    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 6y ago
      No VM, it is just a light weight distribution of Kubernetes that can be effortlessly installed and run on Linux.
jkulubya 6y ago
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-services https://www.redhat.com/sysadmin/podman-shareable-systemd-ser...

harrygeez 6y ago

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 6y ago
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.

boolcow 6y ago

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

nikanj 6y ago
They're newer, and fewer people have heard of them.
pknopf 6y ago
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.
Majestic121 6y ago
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-work https://opensource.com/article/19/2/how-does-rootless-podman...
bgorman 6y ago
"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.
- boolcow 6y ago
  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.

stevekemp 6y ago

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 6y ago
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 6y ago
  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.