Ansible systemd-Dienstrolle

Eine Ansible-Rolle, die systemd-Diensteinheit-Dateien erstellt und konfiguriert. Sie ermöglicht es, bestimmte Dienste automatisch im Hintergrund auszuführen, sie für spezifische Ereignisse zu aktivieren und zu deaktivieren, Gruppen von Prozessen zu verwalten und Abhängigkeiten zu anderen Einheiten zu konfigurieren.

Die Rolle umfasst folgende Aufgaben:

1. Erstellen einer systemd-Dienstdatei unter /etc/systemd/system/ mit einem angegebenen Namen service_name.service für jedes systemd_service-Element.
2. Konfigurieren wichtiger Optionen in den Abschnitten Einheit, Dienst und Installation.
3. Systemd benachrichtigen, dass neue Dienstdateien existieren. Den Dienst neu starten.
4. Den Dienst so einstellen, dass er bei Bedarf beim Booten automatisch gestartet wird.

Diese Rolle kann unter allen Ubuntu-Versionen ausgeführt werden.

Anforderungen

Diese Rolle erfordert Root-Zugriff, daher entweder in einem Playbook mit dem globalen Parameter become: yes ausführen oder die Rolle in Ihrem Playbook wie folgt aufrufen:

- hosts: apps
  roles:
    - role: systemd-service
      become: yes

Rollenvariablen

Alle notwendigen Dienste können durch die Dictionary-Variable systemd_service angegeben werden (siehe defaults/main.yml):

systemd_service: {}

Für jeden Dienst müssen Sie service_name und die notwendigen Parameterwerte festlegen. Zum Beispiel, um anzugeben, ob der Dienst beim Booten gestartet werden soll, verwenden Sie den Parameter enabled.

systemd_service:
  service_name:
    enabled:

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

Optionen im Abschnitt Einheit

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

description:   # Ein freier Text, der die Einheit beschreibt

Die nächsten beiden Parameter konfigurieren Abhängigkeiten zu anderen Einheiten. Wenn der Dienst aktiviert wird, werden auch die dort aufgelisteten Einheiten aktiviert. Wenn eine der requires-Einheiten nicht gestartet werden kann oder plötzlich fehlschlägt, wird der Dienst ebenfalls gestoppt. Im Fall der wants-Liste wird der Dienst nicht gestoppt, wenn eine Einheit daraus deaktiviert wird. Die Parameter können aus mehreren durch Leerzeichen getrennten Einheitenamen 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 festzulegen, in der Dienste gestartet oder gestoppt werden, verwenden Sie die folgenden Parameter. Beachten Sie, dass, wenn Einheiten keine Anforderungsabhängigkeiten zueinander haben, sie gleichzeitig heruntergefahren oder gestartet werden. Beide Parameter werden durch durch Leerzeichen getrennte Listen von Einheiten festgelegt.

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

Optionen im Abschnitt Dienst

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

type:

Er kann die Werte annehmen:

• simple - dieser Typ geht davon aus, dass der Dienst sofort gestartet wird. Der Prozess darf sich nicht verzweigen. Verwenden Sie diesen Typ nicht, wenn andere Dienste Abhängigkeiten in der Reihenfolge auf das Starten des Dienstes haben.
• forking - geht davon aus, dass der Dienst einmal gestartet wird und der Prozess sich mit Abschluss des übergeordneten Prozesses verzweigt. Dieser Typ wird verwendet, um klassische Daemons zu starten. Wenn dieser Modus verwendet wird, wird empfohlen, den Parameter pid_file ebenfalls 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 - es wird erwartet, dass der Dienst vor dem Start der nachfolgenden Einheiten endet;
• dbus - es wird erwartet, dass der Daemon einen Namen im D-Bus-Bus erhält;
• notify - der Daemon sendet eine Benachrichtigungsnachricht über sd_notify(3) oder einen ähnlichen Aufruf, wenn er mit dem Starten abgeschlossen hat;
• idle - die tatsächliche Ausführung der Dienstbinary wird verschoben, bis alle aktiven Jobs abgearbeitet sind. Beachten Sie, dass dieser Typ nur nützlich ist, um die Konsolenausgabe zu verbessern, aber nicht als allgemeines Werkzeug zur Reihenfolge von Einheiten.

Legen Sie einen Pfad zur PID-Datei fest, um den Starttyp forking zu verwenden.

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

Sie können den UNIX-Benutzer und die Gruppe festlegen, unter denen der Dienst ausgeführt werden soll. Die Parameter nehmen einen einzelnen Benutzer- oder Gruppennamen oder eine numerische ID als Wert. Für Systemdienste und für Benutzerdienste des Root-Benutzers ist der Standard root, der auf einen anderen geändert werden kann. Für Benutzerdienste anderer Benutzer ist das Wechseln der Benutzeridentität nicht zulässig. Daher ist der einzige zulässige Wert der gleiche Benutzer, unter dem der Dienstmanager des Benutzers ausgeführt wird. Wenn keine Gruppe festgelegt ist, wird die Standardbenutzergruppe verwendet.

user:
group:

Legen Sie eine Zeitpriorität für die Einheit mit dem nächsten Parameter fest. Es nimmt eine Ganzzahl zwischen -20 (die höchste Priorität) und 19 (die niedrigste Priorität) an.

nice:    # Das Standard-Nice-Level für den Dienst

Ein Anpassungslevel für den Out-Of-Memory-Killer für den Prozess wird mit der folgenden Option angegeben. Es nimmt einen ganzzahligen Wert von -1000 (OOM-Killing deaktivieren) bis 1000 (OOM-Killing ist wünschenswert) an.

oom_score_adjust:

Die nächsten Parameter erlauben es Ihnen, Befehle anzugeben, die in Abhängigkeit vom Zustand Ihres 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 voneinander getrennt werden. Der auszuführende Befehl muss ein absoluter Pfadname sein. Er kann Leerzeichen enthalten, aber Steuerzeichen sind nicht zulässig. 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 hier 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 zur Auslösung eines Konfigurations-Reloads im Dienst ausgeführt werden
exec_reload:

Legen Sie fest, ob der Dienst neu gestartet werden soll, wenn der Dienstprozess (der Hauptdienstprozess oder der durch die Parameter 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' oder 'exec_reload' angegebene Prozess) beendet, getötet wird oder ein Timeout erreicht wird. Der Parameter restart nimmt einen der folgenden Werte an:

• no (Standard) - der Dienst wird nicht neu gestartet;
• on-success - der Dienst wird nur neu gestartet, wenn der Dienstprozess sauber beendet wird (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 von Null verschiedenen Rückgabewert endet, durch ein Signal beendet wird, wenn eine Operation zeitlich begrenzt ist und wenn der konfigurierte Wächter-Timeout ausgelöst wird;
• on-abnormal - der Dienst wird neu gestartet, wenn der Prozess durch ein Signal beendet wird, wenn eine Operation zeitlich begrenzt ist oder wenn der Wächter-Timeout ausgelöst wird;
• on-watchdog - der Dienst wird nur neu gestartet, wenn der Dienstprozess aufgrund eines nicht gefangenen Signals, das nicht als sauberer Beendigungsstatus angegeben ist, endet;
• on-abort - der Dienst wird nur neu gestartet, wenn der Wächter-Timeout für den Dienst abläuft;
• always - der Dienst wird in jedem Fall neu gestartet.

# Wann der Dienst neu gestartet werden muss
restart:

Sie können 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' an. Der Parameter restart_sec konfiguriert die Zeit, die gewartet werden soll, bevor ein Dienst neu gestartet wird (wie mit restart konfiguriert). Die timeout_sec-Option definiert die Zeit, die gewartet werden soll, um Start-/Stoppbefehle zu verarbeiten.

restart_sec:
timeout_sec:

Verwenden Sie den Parameter environment, um eine Liste von Umgebungsvariablen für ausgeführte Prozesse festzulegen. Es enthält eine durch Leerzeichen getrennte Liste von Variablen und ihren Werten. Der Parameter kann mehr als einmal verwendet werden. Wenn der leere String dieser Option zugewiesen wird, wird die Liste der Umgebungsvariablen zurückgesetzt. Wenn ein Wert ein Leerzeichen enthält, verwenden Sie für die Zuweisung doppelte Anführungszeichen.

Sie können auch die Umgebungsvariablen aus einer Textdatei lesen. Setzen Sie dazu den Wert des Parameters environment_file auf den Dateipfad.

environment:       # Eine durch Leerzeichen getrennte Liste von Variablenzuweisungen
environment_file:  # Pfad zu einer Datei mit Umgebungsvariablen

Ein Arbeitsverzeichnis wird durch den nächsten Parameter festgelegt. Es wird als aktuell festgelegt, bevor die Startbefehle ausgeführt werden.

working_directory:

Die folgenden Parameter ermöglichen es, zu wählen, wohin die Datei-Deskriptoren (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" an. Der Parameter standard_output kann gleich "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 standard_output.

standard_input:
standard_output:
standard_error:

Optionen im Installationsabschnitt

Diese Abschnittsvariablen enthalten Installationsinformationen für die Einheit. Die folgenden beiden Parameter können mehr als einmal verwendet werden oder durch Leerzeichen getrennte Listen von Einheitenamen können angegeben werden. Die Listen enthalten Einheiten, die von ihren requires- und wants-Feldern auf diesen Dienst verweisen.

wanted_by:
required_by:

Abhängigkeiten

Keine

Beispiel-Playbook

- hosts: app
  roles:
    - role: systemd-service
      systemd_service:
        # Dienstname
        railsapp:
          # Dienst beim Booten starten
          enabled: Yes
          # Führen Sie den Befehl mit angegebenen Argumenten aus, wenn der Dienst gestartet wird
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Verwenden Sie das angegebene Verzeichnis als aktuell
          working_directory: "/var/www/myapp"
          # Führen Sie die Prozesse unter diesem Benutzer und dieser Gruppe aus
          user: "deploy"
          group: "deploy"
          # Dienst nur neu starten, wenn kein sauberer Rückgabewert oder Signal erhalten wurde
          restart: "on-failure"
          # Versuchen, 'redis' zu aktivieren, wenn möglich
          wants: "redis.service"
          # 'postgresql' aktivieren oder bei Fehler aufhören
          requires: "postgresql.service"
          # die Einheit 'multi-user.target' bevorzugt, dass der Dienst ausgeführt wird
          wanted_by: "multi-user.target"

Lizenz

Lizenziert unter der MIT-Lizenz.