Systemd-nspawn [1]is a lightweight container tool that can run a command or full operating system in a contained environment on Linux. According to the systemd-nspawn man page, systemd-nspawn is "…similar to chroot(1) but more powerful since it fully virtualizes the filesystem hierarchy as well as the process tree, the various IPC subsystems, and the host and domain names." (See also the "Other Container Tools" box.)

chroot /home/editorial/images/jessie/ /bin/ls

Figure 1: A chroot environment offers a simple, but insecure, form of isolation.

The systemd-nspawn container tool began as a means for systemd developers [2] to test building and running systemd itself without affecting the host operating system. Systemd-nspawn lets you launch an application in an isolated container with a single command, making it quite handy for developers who want to run buggy pre-release code without risking damage to the system.

Since the first release, systemd-nspawn has evolved to include a swath of functionality, ranging from advanced networking configurations to SELinux integration and native overlay filesystem support. Modern systemd-nspawn is a versatile and full-featured tool you can use for a variety of different Linux use cases, but its primary purpose is to serve as a tool for developing and testing.

Namespaces and Cgroups

Internally, systemd-nspawn uses several features of the Linux kernel to provide process and resource isolation. The first and foremost of these features is namespaces [9].

Linux namespaces isolate various system resources in a way that is abstracted from processes. For example, if a process is in its own unique PID (process ID) namespace, it will not see any other processes on the system that aren't in that same namespace. In this way, users can restrict processes from interacting with each other along various different axes. The Linux kernel provides a number of different namespaces (Table 1).

A process generates a namespace by issuing the system call unshare(). This call detaches the calling process from its existing namespace and creates a new namespace. A process can also use the setns() system call to change to an existing namespace on the system.

Systemd-nspawn's extensive use of namespaces is reflected in its name. "Nspawn" refers to the fact that the tool generates new namespaces. By default systemd-nspawn will run processes in their own IPC, mount, PID, and UTS namespaces. You can also give the container an independent network namespace and a flag to enable rudimentary user namespace support. For more information on namespaces, refer to the excellent series of introductory articles on LWN [10].

Another key container technology for Linux is cgroups [11]. (When people use the term "Linux containers," they're typically referring to a combination of cgroups and namespaces.) The name cgroups is an abbreviation for "control groups." Cgroups are a means for organizing processes on a Linux system into a hierarchical tree, and then optionally applying different resource parameters to sections of the hierarchy. For example, you can use cgroups to apply memory limits to a particular process or group of processes, and these limits are then enforced by the kernel.

Now, systemd-nspawn itself doesn't do a whole lot with cgroups; it just makes sure the cgroup tree is available within the mount namespace it sets up.

Getting Started with systemd-nspawn

Systemd-nspawn is provided out of the box on any modern Linux distribution that uses systemd as its init system (which these days is almost all of them). In its most basic invocation, you can point systemd-nspawn at a directory and tell it to execute a binary in that directory, but systemd-nspawn also provides over 30 command-line flags to customize different aspects of the containers it creates.

Recent versions of systemd-nspawn also introduced a configuration file, which you can use to encode most of the settings that are available through the flags in a reusable format.

The simple example in Listing 1 shows systemd-nspawn in action. The example downloads an image of the Debian Jessie [12] distribution and then launches it in a container (Figure 2). You need to run these steps with root privileges.

Figure 2: Systemd-nspawn lets you launch Jessie as a container in a few simple steps.

Additionally, you need to delete the root password in the /home/redaktion/jessie/etc/passwd file to use Jessie. The process looks very similar to this with rkt by the way (Listing 2).

The commands shown in Listing 2 download an ACI of Etcd version 2.0.0 and launch it (Figure 3). In this scenario, Rkt has set up the required file system in the directory – including a copy of systemd, which it calls using systemd-nspawn [...].

Figure 3: Rkt also retrieves and launches containers with a single command, relying on systemd-nspawn under the hood.

Conclusion

Systemd-nspawn is very much production ready. Many Linux users – on CoreOS and other platforms – are actively using both rkt and systemd-nspawn directly in production and seeing great success.

Having said that, the systemd developers are still careful about how they position systemd-nspawn. For example, the manpage states that systemd-nspawn is not suitable for secure container setups and explains that the intended use is more for debugging and testing.

Although systemd-nspawn is quite fully featured, it still needs some work. One of the areas that could use some improvement is user namespaces [13], which are not very usable in their current form.

With mature and configurable tools like rkt, Docker, and systemd-nspawn, developers and systems administrators have plenty of options for running application containers.

All of the projects described in this article are completely open source and have active, vibrant communities. Anyone interested in helping to define and implement the future of containers on Linux is encouraged to get involved!