[systemd-devel] Blog on running systemd within a docker container.

[Daniel J Walsh]

On 05/02/2014 11:54 AM, Lennart Poettering wrote:
> On Wed, 30.04.14 14:21, Daniel J Walsh (dwalsh at redhat.com) wrote:
>
>> http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/
> There are a couple of things in the story that I'd like to correct:
>
> 1) udev isn't actually started when systemd detects that /sys is read-only. See:
>
> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
>
> The idea here is that docker should mount /sys read-only (already for
> for security purposes it should do that). When that's done udev is not
> started, and that requires no explicit work by you. I's conditionalized
> via ConditionPathIsWritable=/sys.
There is a pull request to mount /proc and /sys as readonly that looks
like it is going upstream soon.  The readonly mount will only happen in
non-priv containers.  Once we have the ability to add SYS_ADMIN
capability to a non-priv container, I should be able to run systemd
inside a container and this should work.
> 2) systemd doesn't even start getty logins (plural!). If it detects it
> runs inside a container it will actually start exactly one, on
> /dev/console. We can improve systemd to find out a way how to even
> disable that. For example, we could build on $container_ttys (see the
> url above), and maybe intrdouce $container_headless=1 or so, which when
> set will result in systemd to not start any getty at all.
I think this would be good, since we plan on using nsenter to join
containers, don't think we want getty/login running there by default.
> 3) THis is similar for all the other .wants/ links you remove. I think
> we really should avoid doing this. Instead, it sounds better to make
> sure systemd automatically figures out when to start specific services
> and when to not do that. As it turns out we did this for quite a few of
> the services in there already. For example, systemd-binfmt is already
> skipped if /proc/sys is not writable anyway... And so on. So instead of
> doing blanket removals, please let us know which ones you see running
> that you'd rather not see running, and we can figure out a way how to
> conditionaliuze them upstream so that unmodified systemd just works for
> you...
Once we have a better docker, and I can run systemd in a non priv
container, I will attempt this again, and see what processes get started
without the cleanups in the .wants directories.  I too would like to get
rid of these.
> To say this explicitly: we are really interested in making sure that
> systemd runs out-of-the-box in containers, and docker is just one
> implementation of that.
>
> Lennart
>
Great, and I want to make systemd the default tool for running multiple
services within a docker container.  I like it for running a single
service also, since it is so simple.  I would like to talk to you guys
about getting the "journal" information out of the container.  IE with
this model we loose STDOUT/STDERR and /dev/log entries showing up in the
hosts journal.  We can bind mount /dev/log into the container, but we
still loose STDOUT/STDERR