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
- 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
- http://0pointer.de/public/systemd-man/systemd-nspawn.html
- http://0pointer.de/blog/projects/socket-activated-containers.html
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.