Ansible Rolle :vertical_traffic_light: Systemd

Inhaltsverzeichnis

• Unterstützte Plattformen
• Anforderungen
• Rollenvariablen
  • Installieren
  • Konfigurieren
  • Starten
• Abhängigkeiten
• Beispiel-Playbook
• Lizenz
• Autoreninformationen

Ansible-Rolle, die Systemd Einheiten installiert und konfiguriert: Systemkomponenten und Dienste, die vom Linux systemd System-/Dienste-Manager verwaltet werden.

Unterstützte Plattformen:

* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Anforderungen

systemd gilt allgemein als das De-facto-Service-Management-Tool für Linux-Distributionen und sollte mit den meisten OS-Installationen enthalten sein. Während dies normalerweise kein Problem darstellt, ist es erwähnenswert, dass Linux-Kernel >= 3.13 von systemd benötigt wird und Linux-Kernel >= 4.2 für die Unterstützung der vereinheitlichten cgroup-Hierarchie erforderlich ist.

Siehe die systemd README für weitere Details.

Rollenvariablen

Variablen sind verfügbar und entsprechend den folgenden Software- und Maschinenbereitstellungsphasen organisiert:

• install
• config
• launch

Installieren

[unit_config: <config-list-entry>:] path: (standard: /etc/systemd/system)

• Ladepfad zur Systemd-Einheit Konfiguration.

  Neben /etc/systemd/system (Standard) können Einheit-Konfigurationen und zugehörige Drop-In ".d" Verzeichnisüberlagerungen für Systemdienste in den Verzeichnissen /usr/lib/systemd/system oder /run/systemd/system platziert werden.

  Dateien in /etc haben Vorrang vor denen in /run, die wiederum Vorrang vor denen in /usr/lib haben. Drop-In-Dateien in einem dieser Verzeichnisse haben Vorrang vor Einheitendateien, wo auch immer sie sich befinden. Mehrere Drop-In-Dateien mit unterschiedlichen Namen werden in lexikographischer Reihenfolge angewendet, unabhängig davon, in welchem dieser Verzeichnisse sie sich befinden. Siehe die folgende Tabelle und konsultieren Sie systemd(1) für zusätzliche Details zur Ladepriorität.

Ladepfade im Systemmodus (--system)

Einheit Lade-Dateipfad	Beschreibung
/etc/systemd/system	Lokale Konfiguration
/run/systemd/system	Laufzeiteinheiten
/usr/local/lib/systemd/system	Einheiten, die für die lokale Systemadministration installiert wurden
/usr/lib/systemd/system	Einheiten von installierten Paketen

Ladepfade im Benutzermodus (--user)

Einheit Lade-Dateipfad	Beschreibung
$XDG_CONFIG_HOME/systemd/user oder $HOME/.config/systemd/user	Benutzerkonfiguration ($XDG_CONFIG_HOME wird verwendet, wenn gesetzt, andernfalls ~/.config)
/etc/systemd/user	Benutzer-Einheiten, die vom Administrator erstellt wurden
$XDG_RUNTIME_DIR/systemd/user	Laufzeiteinheiten (nur verwendet, wenn $XDG_RUNTIME_DIR gesetzt ist)
/run/systemd/user	Laufzeiteinheiten
$dir/systemd/user für jedes $dir in $XDG_DATA_DIRS	Zusätzliche Standorte für installierte Benutzereinheiten, einer für jeden Eintrag in $XDG_DATA_DIRS
/usr/local/lib/systemd/user	Benutzer-Einheiten, die für die lokale Systemadministration installiert wurden
/usr/lib/systemd/user	Benutzer-Einheiten, die vom Distributionspaketmanager installiert wurden

Beispiel

 unit_config:
   - name: apache
     path: /run/systemd/system
     Service:
       ExecStart: /usr/sbin/httpd
       ExecReload: /usr/sbin/httpd $OPTIONS -k graceful
     Install:
       WantedBy: multi-user.target

[unit_config: <config-list-entry>:] type: <string> (standard: service)

• Art der zu konfigurierenden systemd-Einheit. Derzeit gibt es 11 verschiedene Einheitstypen, die von Daemons bis hin zu Prozessauslösungen reichen. Siehe systemd(1) für die vollständige Liste der verfügbaren Einheiten.

Beispiel

 unit_config:
   - name: apache
     type: socket
     Socket:
       ListenStream: 0.0.0.0:8080
       Accept: yes
     Install:
       WantedBy: sockets.target

Konfigurieren

Die Konfiguration einer systemd-Einheit wird in einer ini-artigen Konfigurationsdatei deklariert. Eine systemd-Einheit INI-Konfiguration besteht aus Abschnitten: 2 allgemein für alle Einheitstypen (Unit und Install) und 1 spezifisch für jeden Einheitstyp. Diese Einheit-Konfigurationen können innerhalb der unit_config Hash-Variable der Rolle als Listen von Dictionnaires mit Schlüssel-Wert-Paaren, die den Namen, Typ, Ladepfad der Einheit und eine Kombination der zuvor genannten Abschnittsdefinitionen darstellen, ausgedrückt werden.

Jede Abschnittsdefinition bietet ein Dictionnaire, das eine Menge von Schlüssel-Wert-Paaren für die entsprechenden Abschnittsoptionen enthält (z. B. die ExecStart-Spezifikation für einen System- oder Webdienst [Service]-Abschnitt oder die ListenStream-Option für einen Web [Socket]-Abschnitt).

[unit_config: <list-entry>:] Unit | <unit-type z. B. Service, Socket, Device oder Mount> | Install: <dict> (standard: {})

• Abschnittsdefinitionen für eine Einheit-Konfiguration

Jede Konfigurationseinstellung/Wert-Schlüssel-Paar sollte innerhalb jeder unit_config Sammlung darstellbar sein und korrekt innerhalb der zugehörigen INI-Konfiguration gerendert werden.

Im Folgenden finden Sie eine Übersicht und Beispielkonfiguration für jeden Einheitstyp zur Referenz.

[Service]

Verwaltet Daemons und die Prozesse, aus denen sie bestehen.

Beispiel

 unit_config:
   - name: example-service
     Unit:
       Description: Schlafdienst
     Service:
       ExecStart: /usr/bin/sleep infinity
     Install:
       WantedBy: multi-user.target

[Socket]

Kapselt lokale IPC oder Netzwerk-Sockets im System.

Beispiel

 unit_config:
   - name: docker
     type: socket
     Unit:
       Description: Hört/akzeptiert Verbindungsanforderungen unter /var/run/docker/sock (implizit *Requires=* zugehöriger docker.service)
     Socket:
       ListenStream: /var/run/docker.sock
       SocketMode: 0660
       SocketUser: root
       SocketGroup: docker
     Install:
       WantedBy: sockets.target

[Mount]

Steuert Einhängepunkte im System.

Beispiel

 unit_config:
   - name: tmp_new
     type: mount
     Unit:
       Description: Neues temporäres Verzeichnis (/tmp_new)
       Conflicts: umount.target
       Before: local-fs.target umount.target
       After: swap.target
     Mount:
       What: tmpfs
       Where: /tmp_new
       Type: tmpfs
       Options: mode=1777,strictatime,nosuid,nodev

[Automount]

Bietet Automount-Funktionen zum bedarfsorientierten Einhängen von Dateisystemen sowie für einen parallelisierten Bootvorgang.

Beispiel

 unit_config:
   - name: proc-sys-fs-binfmt_misc
     type: automount
     Unit:
       Description: Automount-Punkt für beliebige ausführbare Dateiformate
       Documentation: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
       ConditionPathExists: /proc/sys/fs/binfmt_misc/
       ConditionPathIsReadWrite: /proc/sys/
     Automount:
       Where: /proc/sys/fs/binfmt_misc

[Device]

Exponiert Kernel-Geräte und implementiert gerätebasierte Aktivierung.

Dieser Einheitstyp hat keine spezifischen Optionen und daher gibt es keinen separaten [Device] Abschnitt. Die allgemeinen Konfigurationselemente werden im generischen [Unit] und [Install] Abschnitten konfiguriert. systemd erstellt dynamisch Geräteeinheiten für alle Kernel-Geräte, die mit dem „systemd“ udev-Tag gekennzeichnet sind (standardmäßig alle Block- und Netzwerkgeräte sowie einige andere). Um ein udev-Gerät zu kennzeichnen, verwenden Sie TAG+="systemd in der udev-Regeldatei. Beachten Sie auch, dass Geräteeinheiten nach den Pfaden /sys und /dev benannt sind, die sie steuern.

Beispiel

# /usr/lib/udev/rules.d/10-nvidia.rules

SUBSYSTEM=="pci", ATTRS{vendor}=="0x12d2", ATTRS{class}=="0x030000", TAG+="systemd", ENV{SYSTEMD_WANTS}="nvidia-fallback.service"

# Wird die automatische Generierung einer nvidia-fallback.device-Datei mit den entsprechenden [Unit] und [Install] Abschnitten bewirken

[Target]

Bietet Funktionalität zur Organisation von Einheiten und zum Setzen bekannter Synchronisationspunkte während des Bootvorgangs.

Dieser Einheitstyp hat keine spezifischen Optionen, sodass kein separater [Target] Abschnitt existiert. Die allgemeinen Konfigurationselemente werden im generischen [Unit] und [Install] Abschnitten konfiguriert.

Beispiel

 unit_config:
   - name: graphical
     path: /usr/lib/systemd/system/graphical.target
     type: target
     Unit:
       Description: Grafische Benutzeroberfläche
       Documentation: man:systemd.special(7)
       Requires: multi-user.target
       Wants: display-manager.service
       Conflicts: rescue.service rescue.target
       After: multi-user.target rescue.service rescue.target display-manager.service
       AllowIsolate: yes

[Timer]

Löst die Aktivierung anderer Einheiten basierend auf Timern aus.

Beispiel

 unit_config:
   - name: dnf-makecache
     type: timer
     Timer:
       OnBootSec: 10min
       OnUnitInactiveSec: 1h
       Unit: dnf-makecache.service
     Install:
       WantedBy: multi-user.target

[Swap]

Kapselt Speicher-Swap-Partitionen oder -Dateien des Betriebssystems.

Beispiel

 # Sicherstellen, dass die Swap-Datei existiert
 mkdir -p /var/vm
 fallocate -l 1024m /var/vm/swapfile
 chmod 600 /var/vm/swapfile
 mkswap /var/vm/swapfile

------------------------------------

 unit_config:
   - name: var-vm-swap
     type: swap
     Unit:
       Description=Swap für /var/vm/swapfile aktivieren
     Swap:
       What: /var/vm/swapfile
     Install:
       WantedBy: multi-user.target

[Path]

Aktiviert andere Dienste, wenn sich Dateisystemobjekte ändern oder modifiziert werden.

Beispiel

 unit_config:
   - name: Repository-Code-Coverage-Analyse-Trigger
     type: path
     Unit:
       Description: Aktivieren Sie die Code-Coverage-Analyse bei modifizierten Git-Repositories
     Path:
       PathChanged: /path/to/git/repo
       Unit: code-coverage-analysis

[Scope]

Verwaltet eine Gruppe von System- oder Fremd-/Remote-Prozessen.

Scope-Einheiten werden nicht über Einheit-Konfigurationsdateien konfiguriert, sondern werden nur programmgesteuert mit den Bus-Schnittstellen von systemd erstellt. Im Gegensatz zu Dienst-Einheiten verwalten Scope-Einheiten extern erstellte Prozesse und legen selbst keine Prozesse an. Der Hauptzweck von Scope-Einheiten besteht darin, die Arbeitsprozesse eines Systemdienstes zur Organisation zusammenzufassen und Ressourcen zu verwalten.

Beispiel

# *Diese Konfiguration ist für eine transiente Einheitendatei, die programmgesteuert über die systemd-API erstellt wurde. Bitte nicht kopieren oder bearbeiten.*
 unit_config:
   - name: user-session
     type: scope

     Unit:
       Description: Sitzung des Benutzers
       Wants: [email protected]
       Wants: [email protected]
       After: systemd-logind.service systemd-user-sessions.service [email protected] [email protected]
       RequiresMountsFor: /home/user
       Scope:
         Slice: user-1000.slice
      Scope:
         SendSIGHUP=yes
         TasksMax=infinity

[Slice]

Gruppiert und verwaltet Systemprozesse in einem hierarchischen Baum zu Verwaltungszwecken für Ressourcen.

Der Name des Slice kodiert den Standort im Baum. Der Name besteht aus einer durch Bindestriche getrennten Reihe von Namen, die den Pfad zum Slice vom Root-Slice beschreiben. Standardmäßig werden Dienst- und Scope-Einheiten im system.slice platziert, virtuelle Maschinen und Container, die mit systemd-machined(1) registriert sind, befinden sich im machine.slice und Benutzersitzungen, die von systemd-logind(1) verwaltet werden, im user.slice.

Siehe systemd.slice(5) für weitere Details.

[Drop-in]

Bietet Übersteuerungsmöglichkeiten für Einheiten.

Beispiel

 unit_config:
   - name: override.conf
     type: conf
     path: "/lib/systemd/system/[email protected]"
     Service:
       ExecStart:
         - ""
         - "-/sbin/agetty -a muru --noclear %I $TERM"
       EnvironmentFile=/path/to/some/file

Starten

[unit_config: <config-list-entry>:] enabled: (Standard: no)

• ob der Dienst beim Booten gestartet werden soll

[unit_config: <config-list-entry>:] state: (Standard: stopped)

• Aktivierungszustand der Einheit

Abhängigkeiten

Keine

Beispiel-Playbook

Standardbeispiel (keine benutzerdefinierten Einheit-Konfigurationen angegeben):

- hosts: all
  roles:
  - role: 0x0I.systemd

Dienst-/Socket-/Mount-Paar:

- hosts: webservers
  roles:
  - role: 0x0i.systemd
    vars:
      unit_config:
      - name: "my-service"
        Unit:
          After: network-online.target
          Wants: network-online.target
          Requires: my-service.socket
        Service:
          User: 'web'
          Group: 'web'
          ExecStart: '/usr/local/bin/my_service $ARGS'
          ExecReload: '/bin/kill -s HUP $MAINPID'
        Install:
          WantedBy: 'multi-user.target'
      - name: "my-service"
        type: "socket"
        Socket:
          ListenStream: '0.0.0.0:4321'
          Accept: 'true'
        Install:
          WantedBy: 'sockets.target'
      - name: "var-data-my_service"
        type: "mount"
        path: "/run/systemd/system"
        Mount:
          What: '/dev/nvme0'
          Where: '/var/data/my_service'
        Install:
          WantedBy: 'multi-user.target'

Lizenz

MIT

Autoreninformationen

Diese Rolle wurde 2019 von O1.IO erstellt.