Hacker News Reader

Comment by stingraycharles | Hacker News Reader

And not a single mention of the actual weird decision, a client / server model which complicates permission management by at least two orders of magnitude.

View on HN

That's actually a design decision made to work around the limitation of having to run as root. Since the container had to be started as a privileged user, if you want non-privileged users to be able to start contianers you either need a setuid binary or a client/server interface like docker has. There are pros and cons to each of those options.

Now it's possible to create containers without elevated privileges (assuming user namespaces are allowed), but that wasn't possible until long after docker had established the client/server model.

I spent my whole day dealing with Docker permissions today. Whats interesting and dangerous is how docker just overrides ufw rules like they do dont exist.

This is the primary selling point of podman to me actually: If you run any non-standard firewall rules (in my case I use virt-manager to run a handful of VMs using a bridge so each VM can get an IP directly on my router's subnet), some stuff may suddenly break because Docker takes a wrecking ball to the firewall rules.

I’d argue in 2013, the client / server model is what made docker a success. It allowed for a seamless, and mostly identical, experience for docker on Mac, Windows and Linux for one. It met developers where they were, daily-ing a Mac or a Windows and deploying on Linux headless servers. It had benefit on its native Linux system too that took all the alternative solutions another 8 or 9 years for the entire Linux ecosystem to develop enough solutions around containers to make a daemon unnecessary while still offering docker DX.

Oh yes docker-machine was quite good. You can create a machine on a Mac by using VMware, VirtualBox, or using the cloud such as EC2. Then your docker CLI can work with all of these machines seamlessly without knowing any details about the machine.

lxc never had a daemon but Canonical added one (lxd in 2015) and lxc forked it to incus to be community managed.

rkt (2013) was CoreOS's alternative to Docker and was daemon-less and failed.

Podman came along relatively late (2018) and benefited from a lot of Linux kernel and systemd improvements since Docker was designed.

So while arguably the client/server model is outdated for container management tools, I'm not sure it's weird. This is my workstation for example:

  schmichael@fedora:~$ ps -e -o comm= | rg 'd$' | wc -l
  67

Daemons are maybe the least weird paradigm you can choose for a Unix program.

Yeah, the daemon is the real problem with Docker.

This is why I prefer Podman.

Reply on news.ycombinator.com