3 ms·

my understanding was that it was docker that doesnt need root or a daemon. i always thought it seemed wrong that it needed either of those to start with. in m

by pydry 5y ago

my understanding was that it was docker that doesnt need root or a daemon. i always thought it seemed wrong that it needed either of those to start with. in most other respects i think it's a drop in replacement.

anthropodie 5y ago
What you said is true. Other than those podman: - does not mess with your iptables unlike docker. Because of this docker can bypass firewall rules set by ufw - does not creates bridged networks
- freedomben 5y ago
  If you use K8s or some other production container runtime, those are enormous benefits.
mfer 5y ago
It depends on what you’re looking for. Most people use containerd as their backend to Kubernetes. Docker itself uses it. Podman uses a different engine. That may matter to some folks. There are also a bunch of tools that talk directly to the docker socket. There are a lot of varying use cases here. Disclaimer, I started Rancher Desktop.
- Johnnynator 5y ago
  Podman can also be optionally be run as a system daemon that provides a docker socket, but still has/used to have quite a bit of compatibility isues.
- nhoughto 5y ago
  I think the most surprising coming from docker was that containerd can’t build images, just run them, thus nerdctl and things plus other userspace ways of building images too.. so many options.. Totally makes sense when you understand more but initial is surprising.
stingraycharles 5y ago
From a security perspective, a daemon is a nightmare. It makes so much more sense to inherit the permissions from the process it’s launched from, and as such I’m a big proponent of podman (or rkt in a distant past).
- zaphirplane 5y ago
  there is more to it. If you are running kubernetes there are k8s daemons already possibly CRI-O containerd Otherwise the pod is started by systemd, which is another daemon A Started from the command line using podman, is not a production pattern
  - JMS2021 5y ago
    Correct. We are not allowed any command line access to worker nodes or containers. If it isn't deployed using automation, it isn't deployed.
rodgerd 5y ago
It also has a couple of other handy features: 1. It can form up k8s-style pods for deploying tightly-coupled containers. 2. It can understand k8s YAML for deployment (although obviously it doesn't support everything k8s does), which makes it easier to do deployment config that will work locally with podman and then in a k8s deployment.
- withinboredom 5y ago
  Docker can do 1. as well. Either via compose (network-mode: service:) or cli (--net=container).
  - moondev 5y ago
    you can also run static k8s pods with docker by just running the k8s kubelet which will watch /etc/kubernetes/manifests

by pydry 5y ago

anthropodie 5y ago

What you said is true. Other than those podman: - does not mess with your iptables unlike docker. Because of this docker can bypass firewall rules set by ufw - does not creates bridged networks

freedomben 5y ago
If you use K8s or some other production container runtime, those are enormous benefits.

mfer 5y ago

It depends on what you’re looking for. Most people use containerd as their backend to Kubernetes. Docker itself uses it. Podman uses a different engine. That may matter to some folks. There are also a bunch of tools that talk directly to the docker socket. There are a lot of varying use cases here. Disclaimer, I started Rancher Desktop.

Johnnynator 5y ago
Podman can also be optionally be run as a system daemon that provides a docker socket, but still has/used to have quite a bit of compatibility isues.
nhoughto 5y ago
I think the most surprising coming from docker was that containerd can’t build images, just run them, thus nerdctl and things plus other userspace ways of building images too.. so many options.. Totally makes sense when you understand more but initial is surprising.

stingraycharles 5y ago

From a security perspective, a daemon is a nightmare. It makes so much more sense to inherit the permissions from the process it’s launched from, and as such I’m a big proponent of podman (or rkt in a distant past).

zaphirplane 5y ago
there is more to it. If you are running kubernetes there are k8s daemons already possibly CRI-O containerd Otherwise the pod is started by systemd, which is another daemon A Started from the command line using podman, is not a production pattern
- JMS2021 5y ago
  Correct. We are not allowed any command line access to worker nodes or containers. If it isn't deployed using automation, it isn't deployed.

rodgerd 5y ago

It also has a couple of other handy features: 1. It can form up k8s-style pods for deploying tightly-coupled containers. 2. It can understand k8s YAML for deployment (although obviously it doesn't support everything k8s does), which makes it easier to do deployment config that will work locally with podman and then in a k8s deployment.

withinboredom 5y ago
Docker can do 1. as well. Either via compose (network-mode: service:) or cli (--net=container).
- moondev 5y ago
  you can also run static k8s pods with docker by just running the k8s kubelet which will watch /etc/kubernetes/manifests