Systemd und Container: Lernen Sie systemd-nspawn kennen

    PR-1505-3

    Die Containerisierung ist heute eines der wichtigsten Themen. Die Anzahl der Veröffentlichungen über beliebte Tools wie LXC oder Docker liegt bei Tausenden, wenn nicht Zehntausenden.
    In diesem Artikel möchten wir eine andere Lösung diskutieren, zu der es bisher nur wenige Veröffentlichungen in russischer Sprache gibt. Wir sprechen über  systemd-nspawn  - ein Tool zum Erstellen isolierter Umgebungen, das eine der Komponenten von systemd ist. Und systemd als Standard in der Linux-Welt zu reparieren, ist bereits eine vollendete Tatsache. Angesichts dieser Tatsache gibt es allen Grund zu der Annahme, dass sich der Umfang von systemd-nspawn in naher Zukunft erheblich erweitern wird, und es lohnt sich, dieses Tool jetzt kennenzulernen.


    Systemd-nspawn: Allgemeine Informationen



    Der Name systemd-nspawn steht für Namespaces Spawn. Bereits aus diesem Namen folgt, dass systemd-nspawn nur die Isolierung von Prozessen steuert, jedoch keine Ressourcen isolieren kann (dies kann jedoch mit systemd selbst erfolgen, was weiter unten erläutert wird).

    Mit systemd-nspawn können Sie eine vollständig isolierte Umgebung erstellen, in der die Pseudodateisysteme / proc und / sys automatisch bereitgestellt werden. Außerdem können Sie eine isolierte Loopback-Schnittstelle und einen separaten Namespace für Prozess-IDs (PID) erstellen, in denen Sie ein Betriebssystem ausführen können, auf dem die Prozess-IDs basieren Linux-Kernel.

    Wie in Docker gibt es in systemd-nspawn kein spezielles Image-Repository. Sie können beliebige Tools von Drittanbietern zum Erstellen und Herunterladen von Bildern verwenden. Die Formate tar, raw, qcow2 und dkr werden unterstützt (dkr sind Images für Docker; die Dokumentation für systemd-nspawn schreibt darüber nirgendwo explizit und die Autoren meiden das Wort Docker sorgfältig). Die Arbeit mit Bildern basiert auf dem BTRFS- Dateisystem .

    In einem Debian-Container ausführen



    Wir beginnen unsere Einführung in systemd-nspawn mit einem einfachen, aber anschaulichen praktischen Beispiel. Auf einem Server, auf dem OC Fedora ausgeführt wird, werden wir eine isolierte Umgebung erstellen, in der das Debian-Betriebssystem gestartet wird. Alle folgenden Beispielbefehle gelten für Fedora 22 mit systemd 219; In anderen Linux-Distributionen und in anderen Versionen von systemd können sich die Befehle unterscheiden.

    Beginnen wir mit der Installation der erforderlichen Abhängigkeiten:

    sudo dnf install debootstrap bridge-utils
    


    Dann erstelle ein Dateisystem für den zukünftigen Container:

    sudo debootstrap --arch=amd64 jessie /var/lib/machines/container1/
    


    Nach Abschluss aller vorbereitenden Arbeiten können Sie den Container starten:

    sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container 
    


    Die Eingabeaufforderung des Gastbetriebssystems wird auf der Konsole angezeigt:

    root@test_container
    


    Legen Sie das root-Passwort dafür fest:

    passwd
    Enter new UNIX password: 
    Retype new UNIX password: 
    passwd: password updated successfully
    


    Verlassen Sie den Container durch Drücken der Tastenkombination Strg +]]] und führen Sie dann den folgenden Befehl aus:

    sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container  -b
    


    Es enthält das Flag -b (oder −−boot), das angibt, dass beim Starten einer Instanz des Betriebssystems im Container init mit allen ausgeführten Dämonen ausgeführt werden muss.Dieses Flag kann nur verwendet werden, wenn im Container ein systemd-fähiges System ausgeführt wird. Andernfalls kann das Laden des Systems nicht garantiert werden.

    Nach Abschluss all dieser Vorgänge werden Sie vom System aufgefordert, einen Benutzernamen und ein Kennwort einzugeben.
    Daher wird ein vollwertiges Betriebssystem in einer isolierten Umgebung ausgeführt. Jetzt müssen wir ein Netzwerk dafür konfigurieren. Verlassen wir den Container und erstellen eine Brücke, über die die Verbindung zur Schnittstelle auf dem Haupthost hergestellt wird:

    sudo brctl addbr cont-bridge
    


    Vergeben Sie eine IP-Adresse für diese Bridge:

    ip a a [IP-адрес] dev cont-bridge
    


    Führen Sie anschließend den folgenden Befehl aus:

    sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container --network-bridge=cont-bridge -b
    


    Zum Konfigurieren des Netzwerks können Sie auch die Option −−network-ipvlan verwenden, mit der der Container über ipvlan mit der angegebenen Schnittstelle auf dem Haupthost verbunden wird:

    sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container -b --network-ipvlan=[сетевой интерфейс]
    


    Führen Sie den Container als Dienst aus



    Mit systemd können Sie Container so konfigurieren, dass sie beim Systemstart automatisch gestartet werden. Fügen Sie dazu die folgende Konfigurationsdatei zum Verzeichnis / etc / systemd / system hinzu:

    [Unit]
    Description=Test Container
    [Service]
    LimitNOFILE=100000
    ExecStart=/usr/bin/systemd-nspawn --machine=test_container --directory=/var/lib/machines/container1/ -b --network-ipvlan=[сетевой интерфейс] 
    Restart=always
    [Install]
    Also=dbus.service
    


    Lassen Sie uns das gegebene Fragment kommentieren. Im Abschnitt [Description] geben wir einfach den Namen des Containers an. Im Abschnitt [Service] legen wir zunächst das Limit für die Anzahl der geöffneten Dateien im Container fest (LimitNOFILE) und geben dann den Befehl zum Starten des Containers mit den erforderlichen Optionen (ExecStart) an. Die Angabe Restart = bedeutet immer, dass der Container bei einem „Sturz“ neu gestartet werden muss. Im Abschnitt [Install] wird eine zusätzliche Einheit angegeben, die dem Autostart auf dem Host hinzugefügt werden sollte (in unserem Fall das D-Bus-Interprozess-Kommunikationssystem).

    Speichern Sie die Änderungen in der Konfigurationsdatei und führen Sie den Befehl aus:

    sudo systecmctl start test_container
    


    Sie können den Container auf eine andere, einfachere Weise als Dienst starten. Systemd verfügt über eine vorkonfigurierte Konfigurationsdatei zum automatischen Starten von Containern, die im Verzeichnis / var / lib / machines abgelegt sind. Sie können den Start auf der Basis dieses Werkstücks mit den folgenden Befehlen aktivieren:

    sudo systemctl enable machine.target
    mv ~/test_container /var/lib/machines/test_container
    sudo systemctl enable systemd-nspawn@test_container.service
    


    Containerverwaltung: Dienstprogramm machinectl



    Container können mit dem Dienstprogramm machinectl gesteuert werden. Betrachten Sie kurz die wichtigsten Optionen.

    Alle im System verfügbaren Container auflisten:

    sudo machinectl list
    


    Informationen zum Containerstatus anzeigen:

    sudo machinectl status test_container
    


    Geben Sie den Container ein:

    sudo machinectl login test_container
    


    Container nachladen:

    sudo machinectl reboot test_container
    


    Behälter anhalten:

    sudo machinectl poweroff test_container
    


    Der letzte Befehl funktioniert, wenn ein mit systemd kompatibles Betriebssystem im Container installiert ist. Verwenden Sie für Betriebssysteme mit sysvinit die Option terminate.
    Wir haben nur über die grundlegendsten Funktionen des Dienstprogramms machinectl gesprochen. Eine ausführliche Gebrauchsanweisung finden Sie beispielsweise hier .

    Bilder herunterladen



    Wir haben bereits gesagt, dass Sie mit Hilfe von systemd-nspawn Bilder aller anderen Formate ausführen können. Es gibt jedoch eine wichtige Bedingung: Das Arbeiten mit Bildern ist nur auf der Grundlage des BTRFS-Dateisystems möglich, das im Verzeichnis / var / lib / machines bereitgestellt werden muss:

    sudo dnf install btrfs-progs
    mkfs.btrs /dev/sdb
    mount /dev/sdb /var/lib/machines
    mount | grep btrfs
    dev/sdb on /var/lib/machines type btrfs (rw,relatime,seclabel,space_cache)
    


    Wenn keine freie Festplatte vorhanden ist, kann BTRFS auch in einer Datei ausgeführt werden.
    In neueren Versionen von systemd wird das Herunterladen von Bildern sofort unterstützt, und es ist nicht erforderlich, BTRFS zu mounten.

    Laden Sie das Docker-Image:

    sudo machinectl pull-dkr --verify=no library/redis --dkr-index-url=https://index.docker.io
    


    Das Starten eines Containers basierend auf einem geladenen Bild ist einfach:

    sudo systemd-nspawn --machine redis
    


    Containerprotokolle anzeigen



    Informationen zu allen Ereignissen in den Containern werden in den Protokollen aufgezeichnet. Die Protokolleinstellungen können direkt beim Erstellen eines Containers mit der Option
    −−link-journal festgelegt werden. Beispiel:

    sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container -b --link-journal=host
    


    Der obige Befehl gibt an, dass die Protokolle des Containers auf dem Haupthost im Verzeichnis / var / log / journal / machine-id gespeichert werden. Wenn Sie die Option -link-journal = guest setzen, werden alle Protokolle im Container im Verzeichnis / var / log / journal / machine-id gespeichert und auf dem Haupthost im Verzeichnis mit der gleichen Adresse ein symbolischer Link erstellt. Die Option −−link-journal funktioniert nur, wenn im Container ein systemd-System gestartet ist. Andernfalls kann keine korrekte Protokollierung garantiert werden.

    Sie können Informationen zum Starten und Stoppen von Containern mit dem Dienstprogramm journalctl anzeigen, über das wir bereits in einer der vorherigen Publikationen geschrieben haben :

     journalctl -u test_container.service
    


    Journalctl bietet die Möglichkeit, Ereignisprotokolle in einem Container anzuzeigen.
    Verwenden Sie dazu die Option -M (wir präsentieren nur ein kleines Fragment der Ausgabe):

    journalctl -M test_container
    Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Runtime journal is using 8.0M (max allowed 197.6M, trying to leave 296.4M free of 1.9G available <86><92>  current limit 197.6M).
    Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Runtime journal is using 8.0M (max allowed 197.6M, trying to leave 296.4M free of 1.9G available <86><92> current limit 197.6M).
    Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Journal started
    Sep 18 11:50:21 octavia.localdomain systemd[1]: Starting Slices.
    Sep 18 11:50:21 octavia.localdomain systemd[1]: Reached target Slices.
    Sep 18 11:50:21 octavia.localdomain systemd[1]: Starting Remount Root and Kernel File Systems...
    Sep 18 11:50:21 octavia.localdomain systemd[1]: Started Remount Root and Kernel File Systems.
    Sep 18 11:50:21 octavia.localdomain systemd[1]: Started Various fixups to make systemd work better on Debian.
    


    Ressourcenzuweisung



    Die Hauptfunktionen von systemd-nspawn haben wir überprüft. Ein wichtiger Punkt blieb: die Zuordnung von Ressourcen zu Containern. Wie oben erwähnt, isoliert systemd-nspawn keine Ressourcen. Sie können den Ressourcenverbrauch für einen Container mit systemctl einschränken, zum Beispiel:

    sudo systemctl set-property [имя контейнера] CPUShares=200 CPUQuota=30% MemoryLimit=500M
    


    Ressourcenbeschränkungen für den Container können auch in der Unit-Datei im Abschnitt [Slice] angegeben werden.

    Fazit



    Systemd-nspawn ist ein interessantes und vielversprechendes Werkzeug. Unter seinen zweifellos Vorteilen ist hervorzuheben:

    • enge Integration mit anderen Systemkomponenten;
    • die Fähigkeit, mit Bildern in verschiedenen Formaten zu arbeiten;
    • Es müssen keine zusätzlichen Pakete oder Patch-Patches auf dem Kernel installiert werden.


    Natürlich ist es noch zu früh, um über die vollständige Nutzung von systemd-nspawn in der Produktion zu sprechen: Das Tool befindet sich noch im "Rohzustand" und ist nur zum Testen und Experimentieren geeignet. Da sich systemd jedoch weiter ausbreitet, lohnt es sich, auf Verbesserungen von systemd-nspawn zu warten.

    Natürlich ist es im Rahmen des Übersichtsartikels unmöglich, absolut alles zu erzählen. Kommentare sind willkommen, Fragen, Kommentare und Ergänzungen.
    Wenn wir einige Details verpasst haben oder nicht über interessante Funktionen von systemd-nspawn informiert sind, schreiben Sie, und wir werden unsere Bewertung auf jeden Fall ergänzen.
    Und wenn einer von Ihnen systemd-nspawn verwendet, laden wir Sie ein, Ihre Erfahrungen zu teilen.

    Leser, die aus dem einen oder anderen Grund hier keine Kommentare veröffentlichen können, sind in unserem Blog willkommen..

    Jetzt auch beliebt: