4 ms·

> I always hated that docker forced you to treat a container as a single process and spoke about it as if it's a virtue. Let me decide how many or little proces

by mayank 11y ago

> I always hated that docker forced you to treat a container as a single process and spoke about it as if it's a virtue. Let me decide how many or little processes I want running in a container. You can have as many processes as you like running inside a Docker container, you just a need a single process to "boot" them, even if it's a simple shell script.

tyingq 11y ago
The big difference is that LXD can run, in an unprivileged fashion, a systemd based distro without issue, and with a sensible view of /proc. Docker can't currently do that, largely because running a distro in a container isn't an important goal for them.
- lisivka 11y ago
  Docker can run systemd in unprivileged container: https://github.com/vlisivka/docker-centos7-systemd-unpriv https://github.com/vlisivka/docker-centos7-systemd-unpriv PS. Try it: docker run -dt --stop-signal=$(kill -l RTMIN+3) -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name centos7_systemd vlisivka/docker-centos7-systemd-unpriv
  - tyingq 11y ago
    My impression is that someone created a specific dockerfile to get around the issues. I'm noting that LXD can run, for example, stock debian.
    - JdeBP 11y ago
      This appears to be a fairly complex subject. See https://news.ycombinator.com/item?id=11216950 https://news.ycombinator.com/item?id=11216950 and the original LWN article that it depends from.
- cyphar 11y ago
  There are quite a few issues with running a systemd-based distro in a container. The first being that /sys and /proc are basically not namespaced. So if you're not careful, systemd might start modifying your host. There's some work to improve this (the cgroup namespace -- yes, that's a thing now) but the point remains that allowing a root process to start touching /proc and /sys inside a container won't end well. I believe that LXD tries to get around this problem by mounting a FUSE filesystem on /proc and /sys that does a bunch of fakery. I don't like that, to be honest. It should be the kernel's job to namespace things properly.
xorcist 11y ago
That's not a good idea, for the same reason you don't want a shell script for /sbin/init.

by mayank 11y ago

tyingq 11y ago

The big difference is that LXD can run, in an unprivileged fashion, a systemd based distro without issue, and with a sensible view of /proc. Docker can't currently do that, largely because running a distro in a container isn't an important goal for them.

lisivka 11y ago
Docker can run systemd in unprivileged container: https://github.com/vlisivka/docker-centos7-systemd-unpriv https://github.com/vlisivka/docker-centos7-systemd-unpriv PS. Try it: docker run -dt --stop-signal=$(kill -l RTMIN+3) -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name centos7_systemd vlisivka/docker-centos7-systemd-unpriv
- tyingq 11y ago
  My impression is that someone created a specific dockerfile to get around the issues. I'm noting that LXD can run, for example, stock debian.
  - JdeBP 11y ago
    This appears to be a fairly complex subject. See https://news.ycombinator.com/item?id=11216950 https://news.ycombinator.com/item?id=11216950 and the original LWN article that it depends from.
cyphar 11y ago
There are quite a few issues with running a systemd-based distro in a container. The first being that /sys and /proc are basically not namespaced. So if you're not careful, systemd might start modifying your host. There's some work to improve this (the cgroup namespace -- yes, that's a thing now) but the point remains that allowing a root process to start touching /proc and /sys inside a container won't end well. I believe that LXD tries to get around this problem by mounting a FUSE filesystem on /proc and /sys that does a bunch of fakery. I don't like that, to be honest. It should be the kernel's job to namespace things properly.

xorcist 11y ago

That's not a good idea, for the same reason you don't want a shell script for /sbin/init.