Systemd Introduces "Portable Services" Functionality, Similar To Containers

The past several months Lennart Poettering has been working on a "portable services" concept and that big ticket new feature has now landed in Systemd. Portable services are akin to containers but different.

Portable Services is a big addition to systemd at around six thousand new lines of code for this init system and also brings the new portablectl utility. For the explanation of systemd's Portable Services, here's how the documentation describes it with the code that landed this morning into systemd Git:

This systemd version includes a preview of the "portable service" concept. "Portable Services" are supposed to be an incremental improvement over traditional system services, making two specific facets of container management available to system services more readily. Specifically:

1. The bundling of applications, i.e. packing up multiple services, their binaries and all their dependencies in a single image, and running them directly from it.

2. Stricter default security policies, i.e. sand-boxing of applications.

The primary tool for interfacing with "portable services" is the new "portablectl" program. It's currently shipped in /usr/lib/systemd/portablectl (i.e. not in the `$PATH`), since it's not yet considered part of the officially supported systemd interfaces — it's a preview still after all.

Portable services don't bring anything inherently new to the table. All they do is put together known concepts in a slightly nicer way to cover a specific set of use-cases in a nicer way.

# So, what *is* a "Portable Service"?

A portable service is ultimately just an OS tree, either inside of a directory tree, or inside a raw disk image containing a Linux file system. This tree is called the "image". It can be "attached" or "detached" from the system. When "attached" specific systemd units from the image are made available on the host system, then behaving pretty much exactly like locally installed system services. When "detached" these units are removed again from the host, leaving no artifacts around (except maybe messages they might have logged).

The OS tree/image can be created with any tool of your choice. For example, you can use `dnf --installroot=` if you like, or `debootstrap`, the image format is entirely generic, and doesn't have to carry any specific metadata beyond what distribution images carry anyway. Or to say this differently: the image format doesn't define any new metadata as unit files and OS tree directories or disk images are already sufficient, and pretty universally available these days. One particularly nice tool for creating suitable images is mkosi, but many other existing tools will do too.

If you so will, "Portable Services" are a nicer way to manage chroot() environments, with better security, tooling and behavior.

# Where's the difference to a "Container"?

"Container" is a very vague term, after all it is used for systemd-nspawn/LXC-type OS containers, for Docker/rkt-like micro service containers, and even certain 'lightweight' VM runtimes.

The "portable service" concept ultimately will not provide a fully isolated environment to the payload, like containers mostly intend to. Instead they are from the beginning more alike regular system services, can be controlled with the same tools, are exposed the same way in all infrastructure and so on. Their main difference is that the use a different root directory than the rest of the system. Hence, the intention is not to run code in a different, isolated world from the host — like most containers would do it —, but to run it in the same world, but with stricter access controls on what the service can see and do.

As one point of differentiation: as programs run as "portable services" are pretty much regular system services, they won't run as PID 1 (like Docker would do it), but as normal process. A corollary of that is that they aren't supposed to manage anything in their own environment (such as the network) as the execution environment is mostly shared with the rest of the system.

The primary focus use-case of "portable services" is to extend the host system with encapsulated extensions, but provide almost full integration with the rest of the system, though possibly restricted by effective security knobs. This focus includes system extensions otherwise sometimes called "super-privileged containers".

Note that portable services are only available for system services, not for user services. i.e. the functionality cannot be used for the stuff bubblewrap/flatpak is focusing on.

This beta/preview feature of Portable Services will be part of the upcoming systemd 239 release.