Open Source-Tipp

Starthelfer

Mit der Version 219 hat das umstrittene Init-System systemd einige umfassende Änderungen mit sich gebracht. Der Open Source-Tipp in diesem Monat schaut sich die Neuerungen beim Netzwerkmanagement und dem Umgang mit Containern näher an.
Mit der heraufziehenden dunklen Jahreszeit beginnt auch wieder die Einbruchsaison. Mit dem Schutz vor digitalen Einbrechern befasst sich IT-Administrator in der ... (mehr)

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.

Bridge-Devices einrichten

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

Container-Manager

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.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023