systemd Lightweight Containers

Summary

For a longer time systemd already included the systemd-nspawn tool as a more powerful version of chroot(1), primarily inteded for use in development, experimenting, debugging, instrumentation, testing and building of software. With Fedora 19 we want to make nspawn considerably more useful, so that it can easily be used to start containers capable of booting up a complete and unmodified Fedora distribution inside as normal system services.

Owner

Name: Lennart Poettering

Email: lennart at poettering dot net

Current status

Targeted release: Fedora 19

Last updated: 2012-01-17

Percentage of completion: 100%

Detailed Description

systemd-nspawn is already very useful as a development/debugging/testing/building tool for software. With Fedora 19 we to ensure the following things:

An unmodified Fedora 19 shall boot up fine inside a systemd-nspawn container

Fedora 19 shall boot up fine inside a systemd-nspawn container systemd-nspawn shall work fine when invoked as a systemd system service

The system journal of the container shall be available in the host without fiddling

The nspawn container shall be socket-activatable, so that it can be auto-spawning on SSH connections.

Benefit to Fedora

We can more easily test Fedora 19 inside containers in order to ensure it continues to work fine out-of-the-box. This hopefully has the effect that Fedora is and stays bootable in container environments without changes, in the future.

We have a simple to use tool that just works, for development, experimenting, debugging, instrumentation, testing and building of software.

Scope

Primarily only needs changes in systemd upstream.

How To Test

Preparation: Turn off auditing as it is incompatible with containers. Boot your host with audit=0 on the kernel command line.

Use the following to set up a container:

# yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal

Then, set a root password:

# systemd-nspawn -D /srv/mycontainer # passwd ... ^D

Now, boot it up, and check that it booted cleanly:

# systemd-nspawn -bD /srv/mycontainer 3

And make a service out of it:

# cat > /etc/systemd/system/mycontainer.service <<EOF [Unit] Description=My little container [Service] ExecStart=/usr/bin/systemd-nspawn -jbD /srv/mycontainer 3 KillMode=process EOF

And start it:

# systemctl daemon-reload # systemctl start mycontainer

Check if you can see the container's logs from the host:

# journalctl -m

And later on stop it:

# systemctl stop mycontainer

User Experience

It's a tool for developers, hackers, system builders, engineers. Normal users should never see or bother with this.

Dependencies

Nothing really.

Except maybe that ideally the kernel audit layer would gain sane support for containers so that it doesn't have to be turned off explicitly in the kernel via audit=0. Of course, as this is primarily a tool for developers/hackers/gurus adding the kernel command line option isn't too hard. Getting the kernel fixed is hence not a requirement.

Contingency Plan

Nothing. people who don't play with this will never see this.

Documentation

Release Notes

It should be enough to just announce availability of this feature, plus a paste from the Summary section of this feature page, plus maybe a reference to the the docs for this.