On Fri, 11 Oct 2019 at 18:49:37 -0400, Scott Kitterman wrote:
> I have been told by docker users (I'm not one) that systemd as provided on
> Debian can't be used in docker. I have no idea if that's true or not.
It isn't, as noted elsewhere on this thread.
However, my understanding is that they are sort of correct, because
systemd can't be used *in a Docker container that isn't specially
configured*.
It used to be the case that systemd needed `docker run --privileged`,
which removes the security boundary between host and container (aka
"containers don't contain"). systemd has improved since then, and if given
some specific bind-mounts from the host system (which can be read-only)
it will adapt its behaviour to be more container-friendly - so it still
needs special configuration from outside the container, but the special
configuration is now simpler and "more contained".
> If it is true, then to the extent we want Debian to be useful for docker does
> that mean we ought to maintain sysv init scripts?
I think it's necessary to distinguish between two aspects of init here:
* pid 1 (process reaper of last resort)
* service manager
In systemd-world, both of these are the systemd manager,
/lib/systemd/systemd.
In sysvinit-world, sysvinit itself is a process reaper with some
mostly-vestigial service management (configured in /etc/inittab), but 95%
of the service management is delegated to sysv-rc, OpenRC or some similar
framework (for services that start during boot), or to service(8) and
friends (for services that are restarted or otherwise controlled after
the system is booted).
With Debian's historical (non-systemd) defaults, a small minority of
services (mostly just getty) are managed by sysvinit itself, but if it
involves init.d or rc.d, then it's really sysv-rc's job, not sysvinit's;
and The Thread about systemd vs. sysvinit was in fact mostly about
systemd vs. sysv-rc. The fact that we call that configuration "sysvinit"
is not really very helpful, because it makes sysvinit's pid 1 seem more
important than it actually is.
If you will ever have more than one process in your container, you need
a pid 1 that reaps processes, but it doesn't have to be as big as systemd
or even sysvinit: tini will do fine. `docker run --init` provides a
miniature init process for this purpose.
Booting a full operating system in a Docker container is not what it is
designed for (perhaps you *can*, but that doesn't necessarily mean you
*should*). The way I tend think about it is that Docker is a heavyweight
chroot, rather than a lightweight virtual machine. Some other container
frameworks, like lxc/lxd, aim to behave more like a virtual machine,
and for those you do need a full service management framework like
systemd or sysv-rc.
smcv
