Die meisten Neuerungen in der aktuellen systemd-Version betreffen die beden Komponenten networkd und nspawn. Sie sind schon länger Teil von systemd, haben im aktuellen Release aber zusätzliche Funktionen bekommen, die die Arbeit mit ihnen teilweise erheblich erleichtern.
Der Netzwerk-Manager systemd-networkd kann nun mit einer Vielzahl unterschiedlicher Netzwerkgeräte umgehen und wurde funktional so erweitert, dass er den reibungslosen Einsatz in Container-Umgebungen besser unterstützt. Das folgende Beispiel zeigt, wie einfach sich der Daemon dazu verwenden lässt, um beispielsweise ein Bridge-Device einzurichten. Networkd soll nicht den gut etablierten Gnome-NetworkManager ersetzen. Eher ist der Daemon für spezielle Umgebungen gedacht, etwa auf Container-Hosts oder im Embedded-Bereich.
Listing 1 zeigt die notwendigen Vorarbeiten, um den neuen Netzwerk-Manager einsetzen zu können. Er setzt zur Namensauflösung auf den LLMNR-fähigen (Link-local Multicast Name Resolution) Stub-Resolver resolved, der ebenfalls zum systemd-Paket gehört.
Listing 1: Basis-Setup
systemctl enable systemd-networkd systemctl disable NetworkManager systemctl enable systemd-resolved cp /etc/resolv.conf /etc/resolv.conf.bak ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf mkdir /etc/systemd/network
Listing 2 und 3 zeigen die beiden Konfigurationsdateien für die reguläre Ethernet-Karte (Listing 2) und für das Bridge-Device (Listing 3). Welches Gerät über diese Dateien konfiguriert wird, können Sie innerhalb des Match-Abschnitts bestimmen. Hier tragen Sie beispielsweise den Gerätenamen oder auch die MAC-Adresse ein. Über die Network-Sektion wird im Anschluss das so identifizierte Gerät konfiguriert. In Listing 2 wird lediglich bestimmt, an welche Bridge die Netzwerkkarte zu binden ist, in Listing 3 wird das Bridge-Gerät dann mit einer IP-Adresse und anderen Parametern entsprechend konfiguriert.
Bevor die Konfiguration des Bridge-Gerätes erfolgen kann, müssen Sie aber erst einmal dafür sorgen, dass dieses überhaupt vorhanden ist. Hierfür können Sie Konfigurationsdateien mit der Endung .netdev an systemd übergeben. Diese werden unmittelbar nach dem Start des Dienstes ausgelesen und die darin definierten virtuellen Netzwerk-Geräte angelegt. Listing 4 zeigt eine Konfiguration für ein Bridge-Gerät. Die gewohnt gute systemd-Dokumentation beschreibt in den beiden Hilfeseiten zu systemd.network und systemd.netdev alle möglichen Konfigurationsoptionen für diese Art von Dateien.
Rufen Sie nun das Tool networkctl auf, erhalten Sie eine Statusübersicht der vorhandenen Netzwerkgeräte aus Sicht des systemd-Netzwerk-Managers.
Schließlich sei noch darauf hingewiesen, dass der zurvor eingerichtete DNS Stub-Resolver von nun an den DNS-Server verwendet, der innerhalb der »docker0.network
«
-Konfigurationsdatei definiert wurde. Diesen hält systemd in der temporären Datei »/run/systemd/resolve/resolv.conf
«
vor. Da der direkte Zugriff auf diese Datei nicht empfohlen ist, wurde ein entsprechender Softlink für die Datei »/etc/resolv.conf
«
eingerichtet.
Listing 2: Netzwerkkonfiguration (1)
[Match] Name=enp2s25 [Network] Bridge=docker0
Listing 3: Netzwerkkonfiguration (2)
[Match] Name=docker0 [Network] DNS=192.168.100.1 Address=192.168.100.42/24 Gateway=192.168.100.1
Listing 4: Bridge-Konfiguration
[NetDev] Name=docker0 Kind=bridge
Das systemd-Init-Framework bietet unter dem Namen systemd-nspawn schon seit geraumer Zeit einen eigenen Container-Service an. Gerne wird hierfür auch der Begriff "chroot on steroids" verwendet, was die Nähe zum bekannten chroot verdeutlichen soll. Der Service basiert auf der unter [1] aufgeführten Container-Interface-Spezifikation und kann eigenständige Namespace-Container verwalten. Im Gegensatz zu Docker liegt der Fokus hier nicht auf Applikations-Containern, stattdessen soll systemd-nspawn seine Anwender in die Lage versetzen, schnell und unkompliziert einen eigenständigen Container zu booten, der dann zum Debugging und Testen von Systemkomponenten dienen kann. Sicherheitsfeatures, wie Docker sie beispielsweise in aktuellen Versionen bereitstellt, werden von systemd-nspawn in dieser Form nicht umgesetzt.
Listing 5: Das neu eingerichtete Netzwerk-Gerät
IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp2s25 ether off unmanaged 3 enp3s25 ether off unmanaged 4 enp4s25 ether degraded configured 5 enp5s25 ether off unmanaged 6 docker0 ether routable configured 7 virbr0 ether no-carrier unmanaged
Der Container Registration Manager systemd-machined.service verwaltet Container ebenso wie andere virtuelle Systeme und stellt über das Tool machinectl einen einfachen Zugang für sie zur Verfügung. Um einen neuen Container zu erzeugen, können Sie entprechende Images der gewünschten Distribution im Raw-, Tar- oder Docker-Format herunterladen, um dann im Anschluss einen Container auf Basis dieses Images zu starten. Listing 6 zeigt den Download eines Fedora-22-Images und wie Sie darauf basierend einen neuen Container starten.
Listing 6: Download und Start des Containers
# machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-22-20150521.x86_64.raw.xz # systemd-nspawn -M Fedora-Cloud-Base-22-20150521.x86_64 Spawning container Fedora-Cloud-Base-22-20150521.x86_64 on /var/lib/machines/Fedora-Cloud-Base-22-20150521.x86_64.raw. Press ^] three times within 1s to kill container. [root@Fedora-Cloud-Base-22-20150521 ~]#
Dass der so erzeugte Container tatsächliche eigene Namespaces verwendet, können Sie leicht bestätigen, indem Sie einen Blick in das Verzeichnis »/proc/self/ns/
«
innerhalb des Containers und des Hosts werfen. Bis auf den User-Namespace verwenden Host und Container tatsächlich voneinander unabhängige Namespaces. Beispielsweise verbirgt sich für den PID-Namespace auf dem Host hinter der PID 1 der systemd-Prozess, während innerhalb des Containers die PID 1 von der dort gestarteten bash-Shell verwendet wird (Listing 7).
Listing 7: Getrennte Namespaces von Container und Host
[root@Fedora-Cloud-Base-22-20150521 ~]# readlink /proc/self/ns/* ipc:[4026532776] mnt:[4026532771] net:[4026531969] pid:[4026532777] user:[4026531837] uts:[4026532775] # ps -p 1 PID TTY TIME CMD 1 ? 00:00:00 bash # readlink /proc/self/ns/* ipc:[4026531839] mnt:[4026531840] net:[4026531969] pid:[4026531836] user:[4026531837] uts:[4026531838] # ps -p 1 PID TTY TIME CMD 1 ? 00:02:39 systemd
Einen so erzeugten Container können Sie mit »machinectl start Fedora-Cloud-Base-22-20150521.x86_64
«
als System-Service definieren und sich im Anschluss mit »machinectl login
«
in den Container einloggen. Tatsächlich wird hierbei eine neue Instanz des systemd-nspawn-Dienstes erzeugt, was einem »systemctl start Container
«
entspricht.
»machinectl list
«
zeigt eine Übersicht aller aktiven virtuellen Maschinen:
# machinectl list
MACHINE
CLASS SERVICE
Fedora-Cloud-Base-22-20150521.x86_64 container nspawn
qemu-rhel-standalone_vagrant_rhel vm libvirt-qemu
Auch für diese Tools halten die Hilfeseiten zu systemd-nspawn, systemd-machined und machinectl jede Menge hilfreiche Informationen bereit.