Ansible systemd Dienstrolle

Eine Ansible-Rolle, die systemd service unit-Dateien erstellt und konfiguriert. Damit kannst du bestimmte Dienste automatisch im Hintergrund ausführen, sie für bestimmte Ereignisse aktivieren oder deaktivieren, Gruppen von Prozessen verwalten und Abhängigkeiten zu anderen Einheiten konfigurieren.

Die Rolle umfasst folgende Aufgaben:

1. Erstelle eine systemd Dienstdatei in /etc/systemd/system/ mit einem angegebenen Namen service_name.service für jedes systemd_service-Element.
2. Konfiguriere wichtige Optionen in den Abschnitten Unit, Service und Install.
3. Informiere systemd über die neu vorhandenen Dienstdateien. Starte den Dienst neu.
4. Aktiviere den automatischen Start des Dienstes beim Booten, falls erforderlich.

Anforderungen

Diese Rolle erfordert Root-Zugriff. Führe sie entweder in einem Playbook mit dem globalen Parameter become: yes aus oder rufe die Rolle in deinem Playbook wie folgt auf:

- hosts: apps
  roles:
    - role: systemd_service
      become: yes

Rollenvariablen

Alle erforderlichen Dienste können über die Variable systemd_service (siehe defaults/main.yml) angegeben werden:

systemd_service: {}

Für jeden Dienst musst du service_name und die erforderlichen Parameterwerte festlegen. Zum Beispiel, um anzugeben, ob der Dienst beim Booten starten soll, verwende den Parameter enabled.

systemd_service:
  service:
    service_name:
    enabled:

Alle anderen verfügbaren Parameter, die für einen bestimmten service_name-Schlüssel (als geschachtelte Parameter) angegeben werden sollten, sind unten aufgeführt.

Optionen im Abschnitt Unit

Diese Gruppe von Parametern enthält allgemeine Informationen über die Einheit.

description:   # Ein freier Text, der die Einheit beschreibt

Die nächsten zwei Parameter konfigurieren Abhängigkeiten zu anderen Einheiten. Wenn der Dienst aktiviert wird, werden auch die dort aufgeführten Einheiten aktiviert. Wenn eine der requires-Einheiten nicht ausgeführt werden kann oder plötzlich ausfällt, wird der Dienst ebenfalls gestoppt. Bei der wants-Liste wird der Dienst nicht gestoppt, wenn eine der Einheiten aus ihr deaktiviert wird. Die Parameter können aus mehreren durch Leerzeichen getrennten Einheitsnamen bestehen. Sie können auch mehr als einmal angegeben werden.

requires:   # Einheiten, die zusammen mit dem Dienst gestartet werden müssen
wants:      # Einheiten, die zusammen mit dem Dienst gestartet werden sollten

Um die Reihenfolge zu konfigurieren, in der Dienste gestartet oder gestoppt werden, verwende die folgenden Parameter. Beachte, dass, wenn Einheiten keine Ordnungsabhängigkeiten zueinander haben, sie gleichzeitig heruntergefahren oder gestartet werden. Beide Parameter werden durch durch Leerzeichen getrennte Listen von Einheiten gesetzt.

after:   # Einheiten, die nach dem Dienst gestartet werden müssen
before:  # Einheiten, die vor dem Dienst gestartet werden müssen

Optionen im Abschnitt Service

Dieser Abschnitt enthält Informationen über den Dienst und den Prozess, den er überwacht. Der Parameter type konfiguriert den Starttyp des Prozesses für diese Diensteinheit.

type:

Es kann folgende Werte annehmen:

• simple - dieser Typ geht davon aus, dass der Dienst sofort gestartet wird. Der Prozess darf sich nicht verzweigen. Verwende diesen Typ nicht, wenn andere Dienste Ordnungsabhängigkeiten beim Start des Dienstes haben. Wenn der Dienst anderen Prozessen im System Funktionen bietet, sollten die Kommunikationskanäle installiert sein, bevor der Daemon gestartet wird.
• forking - geht davon aus, dass der Dienst einmal gestartet wird und der Prozess sich mit dem Abschluss des Elterprozesses verzweigt. Dieser Typ wird verwendet, um klassische Daemons zu starten. Wenn dieser Modus verwendet wird, wird empfohlen, auch den Parameter pid_file zu verwenden (siehe unten), damit systemd den Hauptprozess des Daemons identifizieren kann.

Andere Werte verhalten sich ähnlich wie der einfache Wert. Sie haben jedoch einige Unterschiede:

• oneshot - der Dienst wird erwartet, vor dem Starten der nachfolgenden Einheiten zu beenden;
• dbus - es wird erwartet, dass der Daemon einen Namen im D-Bus-Bus erwirbt;
• notify - der Daemon sendet eine Benachrichtigungsnachricht über sd_notify(3) oder einen ähnlichen Aufruf, wenn er mit dem Startvorgang abgeschlossen ist;
• idle - die tatsächliche Ausführung der Dienst-Binärdatei wird verzögert, bis alle aktiven Jobs abgearbeitet sind. Beachte, dass dieser Typ nur nützlich ist, um die Konsolenausgabe zu verbessern, während er kein hilfreiches Werkzeug zur allgemeinen Ordnungssteuerung von Einheiten ist.

Setze einen Pfad zur PID-Datei, wenn du den forking-Starttyp verwenden möchtest.

pid_file:    # Nimmt einen absoluten Dateinamen, der auf die PID-Datei dieses Daemons zeigt

Du kannst den UNIX-Benutzer und die Gruppe angeben, unter der der Dienst ausgeführt werden soll. Die Parameter nehmen einen einzelnen Benutzer- oder Gruppennamen oder eine numerische ID als Wert. Für Systemdienste und Benutzerdienste des Root-Benutzers ist die Standardeinstellung root, die auf eine andere geändert werden kann. Für Benutzerdienste anderer Benutzer ist ein Wechsel der Benutzeridentität nicht erlaubt. Daher ist der einzige erlaubte Wert der Benutzer, unter dem der Service-Manager des Benutzers läuft. Wenn keine Gruppe festgelegt ist, wird die Standardbenutzergruppe verwendet.

user:
group:

Setzte eine Priorität für die Planung für die Einheit mit dem nächsten Parameter. Er nimmt eine ganze Zahl zwischen -20 (die höchste Priorität) und 19 (die niedrigste Priorität).

nice:    # Der Standard-Nice-Wert für den Dienst

Ein Anpassungswert für den Out-Of-Memory Killer für den Prozess wird mit der folgenden Option festgelegt. Er nimmt einen ganzzahligen Wert von -1000 (OOM-Killing deaktivieren) bis 1000 (OOM-Killing bevorzugt).

oom_score_adjust:

Die nächsten Parameter erlauben es dir, Befehle zu spezifizieren, die je nach Zustand deines Dienstes ausgeführt werden. Die Parameter können mehr als einmal verwendet werden oder ihre Werte können mehrere Befehle enthalten. Mehrere Befehlszeilen können in einer einzigen Direktive durch Semikolons getrennt verkettet werden. Der auszuführende Befehl muss ein absoluter Pfad sein. Er darf Leerzeichen enthalten, aber Steuerzeichen sind nicht erlaubt. Für jeden Befehl muss das erste Argument ein absoluter Pfad zu einer ausführbaren Datei sein. Ein leerer String setzt die zuvor für den Parameter angegebenen Befehle zurück.

# Befehle, die ausgeführt werden, wenn dieser Dienst gestartet wird
# Es muss genau ein Befehl angegeben werden, es sei denn, `type` ist `oneshot`
exec_start:

# Befehle, die vor den `exec_start`-Befehlen ausgeführt werden
exec_start_pre:

# Befehle, die nach den `exec_start`-Befehlen ausgeführt werden
exec_start_post:

# Befehle, die zum Stoppen des über `exec_start` gestarteten Dienstes ausgeführt werden
exec_stop:

# Befehle, die nach dem Stoppen des Dienstes ausgeführt werden
exec_stop_post:

# Befehle, die zum Auslösen eines Konfigurations-Reloads im Dienst ausgeführt werden
exec_reload:

Setze, ob der Dienst neu gestartet werden soll, wenn der Dienstprozess (der Hauptdienstprozess oder einer, der durch die Parameter exec_start_pre, exec_start_post, exec_stop, exec_stop_post oder exec_reload angegeben wird) endet, getötet wird oder ein Timeout erreicht wird. Der Parameter restart nimmt einen der folgenden Werte an:

• no (standardmäßig) - der Dienst wird nicht neu gestartet;
• on-success - der Dienst wird nur neu gestartet, wenn der Dienstprozess sauber endet (mit einem Rückgabewert von 0 oder einem der Signale SIGHUP, SIGINT, SIGTERM oder SIGPIPE);
• on-failure - der Dienst wird neu gestartet, wenn der Prozess mit einem nicht-null Rückgabewert endet, durch ein Signal beendet wird, wenn eine Operation ein Timeout hat und wenn das konfigurierte Watchdog-Timeout ausgelöst wird;
• on-abnormal - der Dienst wird neu gestartet, wenn der Prozess durch ein Signal beendet wird, wenn eine Operation ein Timeout hat oder wenn das Watchdog-Timeout ausgelöst wird;
• on-watchdog - der Dienst wird nur neu gestartet, wenn der Dienstprozess aufgrund eines nicht gefangenen Signals endet, das nicht als sauberer Rückgabewert angegeben wurde;
• on-abort - der Dienst wird nur neu gestartet, wenn das Watchdog-Timeout für den Dienst abläuft;
• always - der Dienst wird in jedem Fall neu gestartet.

# Wann der Dienst neu gestartet werden muss
restart:

Du kannst eine Zeitverzögerung für die oben genannten Befehle mit den nächsten Parametern festlegen. Sie nehmen einen Wert in Sekunden oder einen Zeitspannewert wie '5min 20s'. Der Parameter restart_sec konfiguriert die Zeit, die vor dem Neustart eines Dienstes (wie konfiguriert mit restart) gewartet wird. Die Option timeout_sec definiert die Zeit, die zum Warten auf die Verarbeitung von Start-/Stoppbefehlen benötigt wird.

restart_sec:
timeout_sec:

Verwende den Parameter environment, um eine Liste von Umgebungsvariablen für die ausgeführten Prozesse festzulegen. Er umfasst ein Dictionary von Variablen und ihren Werten. Wenn ein Wert ein Leerzeichen enthält, verwende doppelte Anführungszeichen für die Zuordnung.

Du kannst auch die Umgebungsvariablen aus einer Textdatei lesen. Setze dazu den Wert des Parameters environment_file auf den Dateipfad.

environment:       # Ein Dictionary mit ENV-Variablen
environment_file:  # Pfad zu einer Datei mit Umgebungsvariablen

Ein Arbeitsverzeichnis wird durch den nächsten Parameter festgelegt. Es wird vor dem Start der Befehle als aktuell gesetzt.

working_directory:

Die folgenden Parameter ermöglichen die Auswahl, wo die Dateideskriptoren (STDIN, STDOUT, STDERR) der ausgeführten Prozesse verbunden werden sollen. Der Parameter standard_input nimmt die Werte "null", "tty", "tty-force", "tty-fail", "socket" oder "fd". Der Parameter standard_output kann "inherit", "null", "tty", "journal", "syslog", "kmsg", "journal+console", "syslog+console", "kmsg+console", "socket" oder "fd" sein. Die verfügbaren Werte von standard_error sind identisch mit denen von standard_output.

standard_input:
standard_output:
standard_error:

Wenn "tty", "tty-force" oder "tty-fail" für einen der "standard_*"-Parameter angegeben ist, kannst du einen Pfad für das tty angeben.

tty_path:

Wenn der Dienst nach Erstellung oder Modifikation im Neustart-/Reload-/Start-/Stoppzustand sein soll.

state:

Er kann Werte annehmen: restarted (Standard), reloaded, started, stopped.

Optionen im Abschnitt Install

Die Variablen in diesem Abschnitt enthalten Installationsinformationen für die Einheit. Die folgenden beiden Parameter können mehr als einmal verwendet werden, oder es können durch Leerzeichen getrennte Listen von Einheitsnamen angegeben werden. Die Listen beinhalten Einheiten, die sich auf diesen Dienst aus ihren Feldern requires und wants beziehen.

wanted_by:
required_by:

Abhängigkeiten

Keine

Beispiel-Playbook

- hosts: app
  roles:
    - role: systemd_service
       systemd_service:
        # Standarddienstname
        railsapp:
          # Dienstname
          service_name: railsapp
          # Dienst beim Booten starten
          enabled: Yes
          # Befehl mit angegebenen Argumenten ausführen, wenn der Dienst gestartet wird
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Das angegebene Verzeichnis als aktuell verwenden
          working_directory: "/var/www/myapp"
          # Eine Umgebungsvariable angeben
          environment: {ENVVAR: value}
          # Prozesse unter diesem Benutzer und dieser Gruppe ausführen
          user: "deploy"
          group: "deploy"
          # Den Dienst nur neu starten, wenn kein sauberer Rückgabewert oder Signal erhalten wurde
          restart: "on-failure"
          # Wenn möglich, 'redis' aktivieren
          wants: "redis.service"
          # 'postgresql' aktivieren oder im Falle eines Fehlers die Arbeit einstellen
          requires: "postgresql.service"
          # multi-user.target Einheit bevorzugt, dass der Dienst ausgeführt wird
          wanted_by: "multi-user.target"

Lizenz

Lizenziert unter der MIT Lizenz.