Features/SystemdLightweightContainers

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Dependencies)
(Feature accepted en block on Feb 06 FESCo meeting)
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= systemd Message Catalog =
+
= systemd Lightweight Containers =
  
 
== Summary ==
 
== 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, debugging, 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.
+
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 ==
 
== Owner ==
Line 16: Line 16:
 
'''systemd-nspawn''' is already very useful as a development/debugging/testing/building tool for software. With Fedora 19 we to ensure the following things:
 
'''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
+
* 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
 
* 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 system journal of the container shall be available in the host without fiddling
Line 24: Line 24:
 
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 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.
+
We have a simple to use tool that just works, for development, experimenting, debugging, instrumentation, testing and building of software.
  
 
== Scope ==
 
== Scope ==
Line 35: Line 35:
 
Use the following to set up a container:
 
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
+
  # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal
  
 
Then, set a root password:
 
Then, set a root password:
  
  $ sudo systemd-nspawn --capability=cap_audit_control,cap_audit_write -D /srv/mycontainer
+
  # systemd-nspawn -D /srv/mycontainer
 
  # passwd
 
  # passwd
 
  ...
 
  ...
Line 46: Line 46:
 
Now, boot it up, and check that it booted cleanly:
 
Now, boot it up, and check that it booted cleanly:
  
  $ sudo systemd-nspawn --capability=cap_audit_control,cap_audit_write -bD /srv/mycontainer 3
+
  # systemd-nspawn -bD /srv/mycontainer 3
  
 
And make a service out of it:
 
And make a service out of it:
Line 78: Line 78:
 
Nothing really.
 
Nothing really.
  
Except maybe that ideally the kernel audit layer would gain sane support for containers to 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.
+
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 ==
 
== Contingency Plan ==
Line 84: Line 84:
  
 
== Documentation ==
 
== Documentation ==
http://0pointer.de/public/systemd-man/systemd-nspawn.html
+
* http://0pointer.de/public/systemd-man/systemd-nspawn.html
 +
* http://0pointer.de/blog/projects/socket-activated-containers.html
  
 
== Release Notes ==
 
== Release Notes ==
No need for additions.
+
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.
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
 
* See [[Talk:Features/SystemdLightweightContainers]]
 
* See [[Talk:Features/SystemdLightweightContainers]]
  
[[Category:FeatureReadyForWrangler]]
+
[[Category:FeatureAcceptedF19]]

Latest revision as of 14:55, 8 February 2013

Contents

[edit] systemd Lightweight Containers

[edit] 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.

[edit] Owner

[edit] Current status

  • Targeted release: Fedora 19
  • Last updated: 2012-01-17
  • Percentage of completion: 100%

[edit] 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.

[edit] 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.

[edit] Scope

Primarily only needs changes in systemd upstream.

[edit] 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

[edit] User Experience

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

[edit] 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.

[edit] Contingency Plan

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

[edit] Documentation

[edit] 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.

[edit] Comments and Discussion