Rôle Ansible :vertical_traffic_light: Systemd

Table des Matières

• Plateformes Supportées
• Exigences
• Variables de Rôle
  • Installation
  • Configuration
  • Lancement
• Dépendances
• Exemple de Playbook
• Licence
• Informations sur l'Auteur

Le rôle Ansible qui installe et configure les unités Systemd unités : composants système et services gérés par le gestionnaire de système/service Linux systemd.

Plateformes Supportées :

* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Exigences

systemd est généralement considéré comme l'outil de gestion de services par défaut pour les distributions Linux et devrait être inclus avec la plupart des installations de systèmes d'exploitation. Bien que cela ne soit généralement pas une préoccupation, il convient de noter que le noyau Linux >= 3.13 est requis par systemd et le noyau Linux >= 4.2 est nécessaire pour le support de l'hierarchy unifiée des cgroupes.

Consultez le README de systemd pour plus de détails.

Variables de Rôle

Les variables sont disponibles et organisées selon les étapes suivantes de provisioning logiciel et matériel :

• installation
• configuration
• lancement

Installation

[unit_config: <config-list-entry>:] path: (par défaut: /etc/systemd/system)

• chemin de configuration des unités systemd à charger.

En plus de /etc/systemd/system (par défaut), les configs d'unités et les répertoires ".d" associés pour les services système peuvent être placés dans /usr/lib/systemd/system ou /run/systemd/system.

Les fichiers dans /etc ont la préséance sur ceux dans /run, qui ont eux-mêmes la préséance sur ceux dans /usr/lib. Les fichiers drop-in sous l'un de ces répertoires prévalent sur les fichiers d'unités où qu'ils soient situés. Plusieurs fichiers drop-in portant des noms différents sont appliqués dans l'ordre lexicographique, quel que soit le répertoire où ils résident. Consultez le tableau ci-dessous et le systemd(1) pour des détails supplémentaires sur la priorité de chargement.

Chemins de chargement lors de l'exécution en mode système (--system)

Chemin de Fichier de Chargement de l'Unité	Description
/etc/systemd/system	Configuration locale
/run/systemd/system	Unités à l'exécution
/usr/local/lib/systemd/system	Unités installées pour l'administration locale
/usr/lib/systemd/system	Unités des paquets installés

Chemins de chargement lors de l'exécution en mode utilisateur (--user)

Chemin de Fichier de Chargement de l'Unité	Description
$XDG_CONFIG_HOME/systemd/user ou $HOME/.config/systemd/user	Configuration de l'utilisateur ($XDG_CONFIG_HOME est utilisé si défini, ~/.config sinon)
/etc/systemd/user	Unités utilisateur créées par l'administrateur
$XDG_RUNTIME_DIR/systemd/user	Unités à l'exécution (utilisées uniquement quand $XDG_RUNTIME_DIR est défini)
/run/systemd/user	Unités à l'exécution
$dir/systemd/user pour chaque $dir dans $XDG_DATA_DIRS	Emplacements supplémentaires pour les unités utilisateur installées, un pour chaque entrée dans $XDG_DATA_DIRS
/usr/local/lib/systemd/user	Unités utilisateur installées pour l'administration locale
/usr/lib/systemd/user	Unités utilisateur installées par le gestionnaire de paquets de distribution

Exemple

 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> (par défaut: service)

• type d'unité systemd à configurer. Il existe actuellement 11 types différents d'unités, allant des démons aux processus dont ils se composent, jusqu'aux déclencheurs de modification de chemin. Consultez systemd(1) pour la liste complète des unités disponibles.

Exemple

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

Configuration

La configuration d'une unité systemd est déclarée dans un fichier de configuration au format ini. Une unité INI systemd est composée de sections : 2 communes à tous les types d'unités (Unit et Install) et 1 spécifique à chaque type d'unité. Ces configurations d'unités peuvent être exprimées dans la variable unit_config de ce rôle sous forme de listes de dictionnaires contenant des paires clé-valeur représentant le nom, le type, le chemin de chargement de l'unité et une combinaison des définitions de sections mentionnées précédemment.

Chaque définition de section de configuration fournit un dictionnaire contenant un ensemble de paires clé-valeur pour les options de section correspondantes (par exemple, la spécification ExecStart pour une section [Service] de système ou de service web).

[unit_config: <list-entry>:] Unit | <type-d'unité par exemple Service, Socket, Device ou Mount> | Install: <dict> (par défaut: {})

• définitions de sections pour une configuration d'unité

Tout paramètre / valeur de configuration pris en charge par la spécification de type d'unité Systemd correspondant devrait pouvoir être exprimé dans chaque collection unit_config et correctement rendu dans la configuration associée INI.

Voici un aperçu et un exemple de configuration de chaque type d'unité pour référence.

[Service]

Gère les démons et les processus dont ils sont composés.

Exemple

 unit_config:
   # path: /etc/systemd/system/example-service.service
   - name: example-service
     Unit:
       Description: Service endormi
     Service:
       ExecStart: /usr/bin/sleep infinity
     Install:
       WantedBy: multi-user.target

[Socket]

Encapsule les sockets IPC locaux ou réseau dans le système.

Exemple

 unit_config:
   - name: docker
     type: socket
     Unit:
       Description: Écoute/accepte les demandes de connexion à /var/run/docker/sock (implémentant implicitement *Requires=* le service docker.)
     Socket:
       ListenStream: /var/run/docker.sock
       SocketMode: 0660
       SockerUser: root
       SocketGroup: docker
     Install:
       WantedBy: sockets.target

[Mount]

Contrôle les points de montage dans le système.

Exemple

 unit_config:
   - name: tmp_new
     type: mount
     Unit:
       Description: Nouveau Répertoire temporaire (/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]

Fournit des capacités d'automontage pour le montage à la demande des systèmes de fichiers ainsi que pour un démarrage parallèle.

Exemple

 unit_config:
   - name: proc-sys-fs-binfmt_misc
     type: automount
     Unit:
       Description: Point d'automontage du système de fichiers de formats de fichiers exécutables arbitraires
       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]

Expose des périphériques du noyau et implémente l'activation basée sur les périphériques.

Ce type d'unité n'a pas d'options spécifiques et ainsi, une section [Device] distincte n'existe pas. Les éléments de configuration communs sont configurés dans les sections génériques [Unit] et [Install]. systemd créera dynamiquement des unités de périphériques pour tous les périphériques du noyau qui sont marqués avec le tag "systemd" d'udev (par défaut, tous les périphériques de bloc et réseau, et quelques autres). Pour taguer un périphérique udev, utilisez TAG+="systemd dans le fichier de règles udev. Notez également que les unités de périphériques sont nommées d'après les chemins /sys et /dev qu'elles contrôlent.

Exemple

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

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

# Cela entraînera la génération automatique d'un fichier nvidia-fallback.device avec les sections [Unit] et [Install] appropriées définies

[Target]

Fournit des capacités d'organisation des unités et définit des points de synchronisation bien connus lors du démarrage.

Ce type d'unité n'a pas d'options spécifiques et ainsi, une section [Target] distincte n'existe pas. Les éléments de configuration communs sont configurés dans les sections génériques [Unit] et [Install].

Exemple

 unit_config:
   - name: graphical
     path: /usr/lib/systemd/system/graphical.target
     type: target
     Unit:
       Description: Interface Graphique
       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]

Déclenche l'activation d'autres unités basées sur des temporisateurs.

Exemple

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

[Swap]

Encapsule les partitions ou fichiers de swap mémoire du système d'exploitation.

Exemple

 # Assurez-vous de l'existence d'un fichier swap
 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=Activer le swap pour /var/vm/swapfile
     Swap:
       What: /var/vm/swapfile
     Install:
       WantedBy: multi-user.target

[Path]

Active d'autres services lorsque des objets du système de fichiers changent ou sont modifiés.

Exemple

 unit_config:
   - name: Déclencheur d'analyse de couverture du code de dépôt
     type: path
     Unit:
       Description: Activer l'analyse de couverture de code sur les dépôts git modifiés
     Path:
       PathChanged: /path/to/git/repo
       Unit: code-coverage-analysis

[Scope]

Gère un ensemble de processus système ou étrangers/à distance.

Les unités de portée ne sont pas configurées via des fichiers de configuration d'unités, mais ne sont créées que de manière programmatique en utilisant les interfaces bus de systemd. Contrairement aux unités de service, les unités de portée gèrent des processus créés externement et ne forkent pas leurs propres processus. Le but principal des unités de portée est de regrouper les processus de travail d'un service système pour l'organisation et la gestion des ressources.

Exemple

# *Cette configuration est pour un fichier d'unité transitoire, créé de manière programmatique via l'API systemd. Ne copiez pas et ne modifiez pas.*
 unit_config:
   - name: user-session
     type: scope

     Unit:
       Description: Session de l'utilisateur
       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]

Regroupe et gère les processus système dans un arbre hiérarchique pour des questions de gestion des ressources.

Le nom de la tranche encode l'emplacement dans l'arbre. Le nom se compose d'une série de noms séparés par des tirets, décrivant le chemin vers la tranche à partir de la tranche racine. Par défaut, les unités de service et de portée sont placées dans system.slice, les machines virtuelles et les conteneurs enregistrés avec systemd-machined(1) sont trouvés dans machine.slice et les sessions utilisateur gérées par systemd-logind(1) dans user.slice.

Voir systemd.slice(5) pour plus de détails.

[Drop-in]

Fournit des capacités de substitution pour les unités.

Exemple

 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

Lancement

[unit_config: <config-list-entry>:] enabled: (par défaut: no)

• si le service doit démarrer au boot.

[unit_config: <config-list-entry>:] state: (par défaut: stopped)

• état d'activation de l'unité.

Dépendances

Aucune

Exemple de Playbook

exemple par défaut (aucune configuration d'unité personnalisée spécifiée) :

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

service/socket/montage:

- 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'

Licence

MIT

Informations sur l'Auteur

Ce rôle a été créé en 2019 par O1.IO.