[systemd-devel] systemd as Docker process manager (was: Docker, Supervisor and systemd)

[Lennart Poettering]

On Sun, 19.07.15 22:38, Paul Menzel (paulepanter at users.sourceforge.net) wrote:

> 1. The capability `SYS_ADMIN` has to be given(?) to the Docker
> container.
> 
>     --cap-add SYS_ADMIN

systemd should work OK now even if you don't pass the cap. That said,
this takes away the effect of things like PrivateNetwork=,
PrivateDevices=, PrivateTmp= and other namespace-related things from
the containers, as well as a few other things. Hence I'd not recommend
doing that, the kernel isn't really ready for this...

> So a container with that capability won’t be that contained anymore.

Currently, containers on Linux are not a security technology. Don't
mistake them for that. Without --private-users there are more holes in
them than in swiss cheese. And even if you do use that, it's still no
security technology, yet.

> 2. systemd-docker [4][7]
> 
> Quoting the systemd-docker README.md [4]:
> 
> > Why I wrote this?
> >
> > The full context is in Docker Issue #6791 [5] and this mailing list
> > thread [6]. The short of it is that systemd does not actually
> > supervise the Docker container but instead the Docker client. This
> > makes systemd incapable of reliably managing Docker containers
> > without hitting a bunch of really odd situations.
> 
> Is it planned to solve this in systemd somehow or is it a Docker issue
> from systemd’s standpoint?

THis is something to fix in Docker. rkt handles this much nicer btw.

> 3. There must also have been some “container improvements” between
> systemd 215 and 221. At least I think, that running systemd 215 in the
> container with Debian Jessie/stable it starts unnecessary(?) processes
> like systemd-udev, while that doesn’t happen when Debian
> Stretch/testing with systemd 221 [8] is used. `systemctl status` and
> `ps aux` just show the journal and the configured programs like Cron
> and Rsyslog.
> 
> Is that just equivalent of deleting the “wants targets”, Dan talked
> about in his blog post [1][2], or some big code changes? Would that be
> easily “backportable” to systemd 215?

We have adjusted systemd all the time. Especially to make it work in
CAP_SYS_ADMIN-less and userns containers. But please don't ask me
which fix we made when, that'd be a lot of work to figure out. I can
only direct you towards the git history for that.

> 4. Current developments
> 
> Is there an overview of the latest developments in this regard, like
> logging and other things? So many things are created and developed,
> that I might have missed something.
> 
> Like some parser of Docker Compose configuration files creating systemd
> unit files from it?

I am not invovled with Docker, I cannot really answer these questions.

> Or should Docker be avoided anyway, because systemd-nspawn or something
> similar does something similar in a much easier fashion?

Well Docker solves a different problem set, such as orchestration over
multiple machines in a cluster, it has build tools and whatnot. nspawn
is just a container executor, with a focus on reusing existing
standards, and good intgeration of the rest of the OS.

Lennart

-- 
Lennart Poettering, Red Hat