Rôle Ansible pour le service systemd

Un rôle Ansible qui crée et configure des fichiers unit de service systemd. Cela vous permet d'exécuter 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 avec d'autres unités.

Le rôle comprend les tâches suivantes :

1. Créer un fichier de service systemd à /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 que de nouveaux fichiers de service existent. Redémarrer le service.
4. Activer l'exécution automatique du service au démarrage si nécessaire.

Exigences

Ce rôle nécessite un accès root, donc soit exécutez-le dans un playbook avec un paramètre global become: yes, soit 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:
    service_name:
    enabled:

Tous les autres paramètres disponibles qui doivent être spécifiés pour une clé service_name (en tant que paramètres imbriqués) sont donnés ci-dessous.

Options de la section Unit

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

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

Les deux paramètres suivants configurent les dépendances avec 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 celle-ci 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 doivent ê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 suivantes :

• simple - ce type suppose que le service sera lancé immédiatement. Le processus ne doit pas se diviser. N'utilisez pas ce type si d'autres services ont des dépendances d'ordre sur le démarrage du service. Si le service offre une fonctionnalité à 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 divise à 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 présentent certaines différences :

• oneshot - le service doit quitter avant que systemd démarre les unités suivantes ;
• dbus - il est prévu 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é son démarrage ;
• idle - l'exécution réelle du binaire de service est retardée jusqu'à ce que tous les emplois actifs soient traités. Notez que ce type est utile uniquement pour améliorer la sortie de la console, il n'est pas utile en tant qu'outil général d'ordre d'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 nom d'utilisateur ou de groupe unique, ou un ID numérique comme valeur. Pour les services système et pour les services d'utilisateur de l'utilisateur root, la valeur par défaut est root, qui peut être changée. Pour les services d'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 sous lequel le gestionnaire de services de l'utilisateur s'exécute. 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 plus haute priorité) et 19 (la plus basse priorité).

nice:    # Le niveau de priorité par défaut pour le service

Un niveau d'ajustement pour le tueur d'Out-Of-Memory pour le processus est spécifié avec l'option suivante. Il prend une valeur entière de -1000 (désactiver l'OOM killing) à 1000 (l'OOM killing 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 `type` ne 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 la configuration dans le service
exec_reload:

Définissez si le service doit être redémarré lorsque le processus de service (le processus principal de 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 lorsqu'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 de 0, ou 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 dépasse le délai, et lorsque le délai d'attente du watchdog configuré est déclenché ;
• on-abnormal - le service sera redémarré lorsque le processus est terminé par un signal, lorsqu'une opération dépasse le délai, ou lorsque le délai d'attente du watchdog est déclenché ;
• on-watchdog - le service sera redémarré uniquement si le processus de service se termine à cause d'un signal non capturé non spécifié comme un état de sortie propre ;
• on-abort - le service sera redémarré uniquement si le délai d'attente du watchdog pour le service expire ;
• always - le service sera redémarré dans tous les cas.

# Quand le service doit-il ê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 période de temps telle que '5min 20s'. Le paramètre restart_sec configure le temps d'attente avant de redémarrer un service (tels que configurés 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 inclut un dictionnaire de variables et de leurs valeurs. 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:       # Un dictionnaire avec des variables ENV
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 courant avant que les commandes de démarrage ne soient lancées.

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:

Si "tty", "tty-force" ou "tty-fail" est spécifié pour l'un des paramètres "standard_*", alors vous pouvez spécifier un chemin pour le tty.

tty_path:

Si le service doit être dans l'état redémarré/rechargé/démarré/arrêté après sa création ou sa modification.

state:

Il peut prendre les valeurs : restarted (par défaut), reloaded, started, stopped.

Options de la section Install

Cette section porte 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 de service par défaut
        railsapp:
          # Nom du service
          service_name: railsapp
          # Démarrer le service au démarrage
          enabled: Yes
          # 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"
          # spécifier une variable d'environnement
          environment: {ENVVAR: value}
          # Exécuter les processus sous cet utilisateur et ce groupe
          user: "deploy"
          group: "deploy"
          # Redémarrer le service uniquement lorsqu'un code de sortie ou un signal propre n'est pas reçu
          restart: "on-failure"
          # Essayer d'activer 'redis' si possible
          wants: "redis.service"
          # Activer 'postgresql' ou arrêter le service 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

Licencié sous la Licence MIT.