systemd Lightweight Containers
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 Fedora distribution inside as normal system services.
- Name: Lennart Poettering
- Email: lennart at poettering dot net
- Targeted release: Fedora 19
- Last updated: 2012-01-17
- Percentage of completion: 100%
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, debugging, testing and building of software.
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
Then, set a root password:
$ sudo systemd-nspawn --capability=cap_audit_control,cap_audit_write -D /srv/mycontainer # passwd ... ^D
Now, boot it up, and check that it booted cleanly:
$ sudo systemd-nspawn --capability=cap_audit_control,cap_audit_write -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
It's a tool for developers, hackers, system builders, engineers. Normal users should never see or bother with this.
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.
Nothing. people who don't play with this will never see this.
No need for additions.