Rôle Ansible pour le service systemd

Un rôle Ansible qui crée et configure des fichiers d'unités de service systemd. Il vous permet de faire fonctionner certains services automatiquement en arrière-plan, de les activer et de les désactiver pour des événements spécifiques, de gérer des groupes de processus et de configurer des dépendances sur d'autres unités.

Le rôle comprend les tâches suivantes :

1. Créer un fichier de service systemd dans /etc/systemd/system/ avec un nom spécifié service_name.service pour chaque élément systemd_service.
2. Configurer les options importantes des sections Unit, Service et Install.
3. Notifier systemd de l'existence de nouveaux fichiers de service. Redémarrer le service.
4. Activer le démarrage automatique du service au démarrage si nécessaire.

Ce rôle peut être exécuté sous toutes les versions d'Ubuntu.

Exigences

Ce rôle nécessite un accès root, donc exécutez-le dans un playbook avec le paramètre global become: yes, ou invoquez le rôle dans votre playbook comme suit :

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

Variables du rôle

Tous les services nécessaires peuvent être spécifiés par la variable de dictionnaire systemd_service (voir defaults/main.yml) :

systemd_service: {}

Pour chaque service, vous devez définir service_name et les valeurs de paramètres nécessaires. Par exemple, pour spécifier si le service doit démarrer au démarrage, utilisez le paramètre enabled.

systemd_service:
  service_name:
    enabled:

Tous les autres paramètres disponibles qui doivent être spécifiés pour une clé service_name spécifique (comme des paramètres imbriqués) sont listés ci-dessous.

Options de la section Unit

Ce groupe de paramètres comprend des informations génériques sur l'unité.

description:   # Une chaîne de caractères décrivant librement l'unité

Les deux paramètres suivants configurent les dépendances sur d'autres unités. Si le service est activé, les unités listées seront également activées. Si une des unités requires ne peut pas être exécutée ou échoue soudainement, le service sera également arrêté. En ce qui concerne la liste wants, le service ne sera pas arrêté si une unité de cette liste est désactivée. Les paramètres peuvent consister en plusieurs noms d'unités séparés par des espaces. Ils peuvent également être spécifiés plusieurs fois.

requires:   # Unités qui doivent être démarrées avec le service
wants:      # Unités qui devraient être démarrées avec le service

Pour configurer l'ordre dans lequel les services sont démarrés ou arrêtés, utilisez les paramètres suivants. Notez que si les unités n'ont pas de dépendances d'ordre entre elles, elles sont arrêtées ou démarrées simultanément. Les deux paramètres sont définis par des listes d'unités séparées par des espaces.

after:   # Unités qui doivent être démarrées après le service
before:  # Unités qui doivent être démarrées avant le service

Options de la section Service

Cette section inclut des informations sur le service et le processus qu'il supervise. Le paramètre type configure le type de démarrage du processus pour cette unité de service.

type:

Il peut prendre les valeurs :

• simple - ce type suppose que le service sera lancé immédiatement. Le processus ne doit pas se ramifier. Ne pas utiliser ce type si d'autres services ont des dépendances d'ordre sur le lancement du service. Si le service offre des fonctionnalités à d'autres processus sur le système, ses canaux de communication doivent être installés avant que le démon ne soit démarré.
• forking - suppose que le service est démarré une fois et que le processus se ramifie avec l'achèvement du processus parent. Ce type est utilisé pour lancer des démons classiques. Si ce mode est utilisé, il est recommandé d'utiliser également le paramètre pid_file (voir ci-dessous), afin que systemd puisse identifier le processus principal du démon.

Les autres valeurs se comportent de manière similaire à la valeur simple. Cependant, elles ont quelques différences :

• oneshot - le service est censé se terminer avant que systemd ne commence à démarrer d'autres unités ;
• dbus - on s'attend à ce que le démon acquière un nom sur le bus D-Bus ;
• notify - le démon envoie un message de notification via sd_notify(3) ou un appel similaire lorsqu'il a terminé de se lancer ;
• idle - l'exécution effective du binaire de service est retardée jusqu'à ce que tous les travaux actifs soient dispatchés. Notez que ce type n'est utile que pour améliorer la sortie de la console, il n'est pas utile en tant qu'outil général de gestion des unités.

Définissez un chemin vers le fichier PID pour utiliser le type de démarrage forking.

pid_file:    # Prend un nom de fichier absolu pointant vers le fichier PID de ce démon

Vous pouvez spécifier l'utilisateur UNIX et un groupe sous lequel le service doit être exécuté. Les paramètres prennent un seul nom d'utilisateur ou de groupe, ou un ID numérique comme valeur. Pour les services système et pour les services utilisateur de l'utilisateur root, la valeur par défaut est root, qui peut être changée. Pour les services utilisateur de tout autre utilisateur, le changement d'identité d'utilisateur n'est pas autorisé. Donc, la seule valeur autorisée est le même utilisateur que l'utilisateur qui exécute le gestionnaire de services. Si aucun groupe n'est défini, le groupe d'utilisateur par défaut est utilisé.

user:
group:

Définissez une priorité de planification pour l'unité avec le paramètre suivant. Il prend un entier entre -20 (la priorité la plus élevée) et 19 (la plus basse priorité).

nice:    # Le niveau agréable par défaut pour le service

Un niveau d'ajustement pour le tueur Out-Of-Memory pour le processus est spécifié avec l'option suivante. Il prend une valeur entière de -1000 (désactiver le tueur OOM) à 1000 (le tueur OOM est préférable).

oom_score_adjust:

Les paramètres suivants vous permettent de spécifier des commandes qui seront exécutées en fonction de l'état de votre service. Les paramètres peuvent être utilisés plusieurs fois ou leurs valeurs peuvent inclure plusieurs commandes. Plusieurs lignes de commande peuvent être concaténées dans une seule directive en les séparant par des points-virgules. La commande à exécuter doit être un nom de chemin absolu. Elle peut contenir des espaces, mais les caractères de contrôle ne sont pas autorisés. Pour chaque commande, le premier argument doit être un chemin absolu vers un exécutable. Une chaîne vide réinitialisera la liste des commandes spécifiées auparavant pour le paramètre.

# Commandes exécutées lorsque ce service est démarré
# À moins que le `type` soit `oneshot`, exactement une commande doit être donnée ici
exec_start:

# Commandes exécutées avant les commandes `exec_start`
exec_start_pre:

# Commandes exécutées après les commandes `exec_start`
exec_start_post:

# Commandes à exécuter pour arrêter le service démarré via `exec_start`
exec_stop:

# Commandes exécutées après que le service soit arrêté
exec_stop_post:

# Commandes à exécuter pour déclencher un rechargement de configuration dans le service
exec_reload:

Définissez si le service doit être redémarré lorsque le processus de service (le processus principal du service ou celui spécifié par les paramètres 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' ou 'exec_reload') se termine, est tué, ou qu'un délai d'attente est atteint. Le paramètre restart prend l'une des valeurs suivantes :

• no (par défaut) - le service ne sera pas redémarré ;
• on-success - le service sera redémarré uniquement lorsque le processus de service se termine proprement (avec un code de sortie 0, ou avec l'un des signaux SIGHUP, SIGINT, SIGTERM ou SIGPIPE) ;
• on-failure - le service sera redémarré lorsque le processus se termine avec un code de sortie non nul, est terminé par un signal, lorsqu'une opération expire, et lorsque le délai d'attente du gardien configuré est déclenché ;
• on-abnormal - le service sera redémarré lorsque le processus est terminé par un signal, lorsqu'une opération expire, ou lorsque le délai d'attente du gardien est déclenché ;
• on-watchdog - le service sera redémarré uniquement si le processus de service se termine en raison d'un signal non capturé qui n'est pas spécifié comme un statut de sortie propre ;
• on-abort - le service sera redémarré uniquement si le délai d'attente du gardien pour le service expire ;
• always - le service sera redémarré de toute façon.

# Quand le service doit être redémarré
restart:

Vous pouvez spécifier un délai pour les commandes mentionnées ci-dessus avec les paramètres suivants. Ils prennent une valeur en secondes ou une valeur de durée comme '5min 20s'. Le paramètre restart_sec configure le temps d'attente avant de redémarrer un service (comme configuré avec restart). L'option timeout_sec définit le temps d'attente pour le traitement des commandes de démarrage/arrêt.

restart_sec:
timeout_sec:

Utilisez le paramètre environment pour définir une liste de variables d'environnement pour les processus exécutés. Il comprend une liste séparée par des espaces de variables et de leurs valeurs. Le paramètre peut être utilisé plusieurs fois. Si une chaîne vide est assignée à cette option, la liste des variables d'environnement sera réinitialisée. Si une valeur contient un espace, utilisez des guillemets doubles pour l'assignation.

Vous pouvez également lire les variables d'environnement à partir d'un fichier texte. Pour cela, définissez la valeur du paramètre environment_file comme le chemin du fichier.

environment:       # Une liste de variables assignées séparées par des espaces
environment_file:  # Chemin vers un fichier avec des variables d'environnement

Un répertoire de travail est spécifié par le paramètre suivant. Il est défini comme actuel avant le lancement des commandes de démarrage.

working_directory:

Les paramètres suivants permettent de choisir où les descripteurs de fichiers (STDIN, STDOUT, STDERR) des processus exécutés doivent être connectés. Le paramètre standard_input prend les valeurs "null", "tty", "tty-force", "tty-fail", "socket" ou "fd". Le paramètre standard_output peut être égal à "inherit", "null", "tty", "journal", "syslog", "kmsg", "journal+console", "syslog+console", "kmsg+console", "socket" ou "fd". Les valeurs disponibles pour standard_error sont identiques à celles de standard_output.

standard_input:
standard_output:
standard_error:

Options de la section Install

Les variables de cette section portent des informations d'installation pour l'unité. Les deux paramètres suivants peuvent être utilisés plusieurs fois, ou des listes d'unités séparées par des espaces peuvent être spécifiées. Les listes incluent des unités qui se réfèrent à ce service depuis leurs champs requires et wants.

wanted_by:
required_by:

Dépendances

Aucune

Exemple de playbook

- hosts: app
  roles:
    - role: systemd-service
      systemd_service:
        # Nom du service
        railsapp:
          # Démarrer le service au démarrage
          enabled: Oui
          # Exécuter la commande avec les arguments spécifiés lorsque le service est démarré
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Utiliser le répertoire spécifié comme courant
          working_directory: "/var/www/myapp"
          # Exécuter les processus sous cet utilisateur et ce groupe
          user: "deploy"
          group: "deploy"
          # Redémarrer le service uniquement lorsque le code de sortie ou le signal est propre
          restart: "on-failure"
          # Essayer d'activer 'redis' si possible
          wants: "redis.service"
          # Activer 'postgresql' ou arrêter de fonctionner en cas d'échec
          requires: "postgresql.service"
          # l'unité multi-user.target préfère que le service soit exécuté
          wanted_by: "multi-user.target"

Licence

Sous licence MIT License.