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

[Djalal Harouni]

On Fri, May 02, 2014 at 12:54:25PM -0400, Daniel J Walsh 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.
> > 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
You can check systemd-nspawn and the "--link-journal" switch, if set to
"host" the journal '/var/log/journal/machine-id' will be stored on host,
and bind mounted into the container.

Thanks for the blog!

-- 
Djalal Harouni
http://opendz.org