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

[Lennart Poettering]

On Fri, 02.05.14 12:54, Daniel J Walsh (dwalsh at redhat.com) wrote:

> 
> 
> 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.

It really shouldn't mount all of /proc read-oony, just /proc/sys and
/sys. But apps should be allowed to get write access to /proc/self/ and
friends, there are some things in there, that should be writable.

The read-only mounting should happen in all kinds of containers,
priviliged and non-priviliged...

> > 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.

I added this to the todo list now.

> 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

All of journald's communication is via sockets in the fs. There's
/dev/log for syslog, /run/journal/systemd/socket for the native
protocol, and /run/journal/systemd/stdout for the stdout/stderr
thing. In theory it should suffice to bind mount these sockets fromt he
host. In real life though the dependency tree in the container will
still try to invoke a journald for you...

Lennart

-- 
Lennart Poettering, Red Hat