Rol de Ansible: vertical_traffic_light: Systemd

Tabla de Contenidos

• Plataformas Soportadas
• Requisitos
• Variables del Rol
  • Instalar
  • Configurar
  • Lanzar
• Dependencias
• Ejemplo de Playbook
• Licencia
• Información del Autor

Rol de Ansible que instala y configura Systemd unidades: componentes del sistema y servicios gestionados por el administrador de servicios systemd de Linux.

Plataformas Soportadas:

* Debian
* Redhat (CentOS/Fedora)
* Ubuntu

Requisitos

systemd se considera generalmente la herramienta de gestión de servicios estándar para distribuciones de Linux y debería estar incluida en la mayoría de las instalaciones del sistema operativo. Aunque normalmente no sea un problema, vale la pena mencionar que se requiere un núcleo de Linux >= 3.13 para systemd, y un núcleo de Linux >= 4.2 es necesario para el soporte de jerarquía de cgroup unificada.

Consulta el README de systemd para más detalles.

Variables del Rol

Las variables están disponibles y organizadas según las siguientes etapas de provisión de software y máquina:

• instalar
• configurar
• lanzar

Instalar

[unit_config: <config-list-entry>:] path: (predeterminado: /etc/systemd/system)

• carga de la ruta de configuración de la unidad systemd.

  Además de /etc/systemd/system (predeterminado), las configuraciones de unidad y los sobres de la carpeta ".d" asociada para servicios del sistema pueden colocarse en los directorios /usr/lib/systemd/system o /run/systemd/system.

  Los archivos en /etc tienen prioridad sobre los de /run, que a su vez tienen prioridad sobre los de /usr/lib. Los archivos de sobres en cualquiera de estos directorios tienen prioridad sobre los archivos de unidad donde sea que se encuentren. Varios archivos de sobres con diferentes nombres se aplican en orden lexicográfico, independientemente de en qué directorios se encuentren. Consulta la tabla a continuación y consulta systemd(1) para más detalles sobre la prioridad de carga de las rutas.

Rutas de carga cuando se ejecuta en modo de sistema (--system)

Ruta de Carga de la Unidad	Descripción
/etc/systemd/system	Configuración local
/run/systemd/system	Unidades en tiempo de ejecución
/usr/local/lib/systemd/system	Unidades instaladas para la administración local del sistema
/usr/lib/systemd/system	Unidades de paquetes instalados

Rutas de carga cuando se ejecuta en modo de usuario (--user)

Ruta de Carga de la Unidad	Descripción
$XDG_CONFIG_HOME/systemd/user o $HOME/.config/systemd/user	Configuración de usuario ($XDG_CONFIG_HOME se utiliza si está configurado, de lo contrario ~/.config)
/etc/systemd/user	Unidades de usuario creadas por el administrador
$XDG_RUNTIME_DIR/systemd/user	Unidades en tiempo de ejecución (solo se usa cuando $XDG_RUNTIME_DIR está configurado)
/run/systemd/user	Unidades en tiempo de ejecución
$dir/systemd/user para cada $dir en $XDG_DATA_DIRS	Ubicaciones adicionales para unidades de usuario instaladas, una para cada entrada en $XDG_DATA_DIRS
/usr/local/lib/systemd/user	Unidades de usuario instaladas para la administración local del sistema
/usr/lib/systemd/user	Unidades de usuario instaladas por el administrador de paquetes de la distribución

Ejemplo

 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> (predeterminado: service)

• tipo de unidad systemd a configurar. Actualmente hay 11 tipos diferentes de unidades, que van desde demonios y los procesos que consisten en ellos hasta desencadenadores de modificación de rutas. Consulta systemd(1) para la lista completa de unidades disponibles.

Ejemplo

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

Configurar

La configuración de una unidad systemd se declara en un archivo de configuración estilo ini. Una unidad de configuración INI de systemd se compone de secciones: 2 comunes entre todos los tipos de unidad (Unit e Install) y 1 específica para cada tipo de unidad. Estas configuraciones de unidad pueden expresarse dentro de la variable hash unit_config del rol como listas de diccionarios que contienen pares clave-valor que representan el nombre, tipo, ruta de carga de la unidad y una combinación de las definiciones de sección mencionadas anteriormente.

Cada definición de sección de configuración proporciona un diccionario que contiene un conjunto de pares clave-valor para las opciones de sección correspondientes (por ejemplo, la especificación ExecStart para una sección de servicio o web [Service] o la opción ListenStream para una sección [Socket] de la web).

[unit_config: <list-entry>:] Unit | <tipo-unidad ej. Service, Socket, Device o Mount> | Install: <dict> (predeterminado: {})

• definiciones de secciones para una configuración de unidad

Cualquier configuración de clave/valor que sea compatible con la especificación de tipo de unidad Systemd correspondiente debería poder expresarse dentro de cada colección de unit_config y representarse correctamente dentro del archivo de configuración INI asociado.

Se proporciona a continuación un resumen y ejemplo de configuración de cada tipo de unidad como referencia.

[Service]

Gestiona demonios y los procesos que los componen.

Ejemplo

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

[Socket]

Encapsula sockets IPC locales o de red en el sistema.

Ejemplo

 unit_config:
   - name: docker
     type: socket
     Unit:
       Description: Escucha/acepta solicitudes de conexión en /var/run/docker/sock (implícitamente *Requires=* asociado con docker.service)
     Socket:
       ListenStream: /var/run/docker.sock
       SocketMode: 0660
       SocketUser: root
       SocketGroup: docker
     Install:
       WantedBy: sockets.target

[Mount]

Controla puntos de montaje en el sistema.

Ejemplo

 unit_config:
   - name: tmp_new
     type: mount
     Unit:
       Description: Nuevo Directorio Temporal (/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]

Proporciona capacidades de montaje automático para el montaje a demanda de sistemas de archivos, así como un arranque en paralelo.

Ejemplo

 unit_config:
   - name: proc-sys-fs-binfmt_misc
     type: automount
     Unit:
       Description: Punto de Montaje del Sistema de Archivos de Formatos Ejecutables Arbitrarios
       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]

Expone dispositivos del núcleo e implementa activación basada en dispositivos.

Este tipo de unidad no tiene opciones específicas y, como tal, no existe una sección [Device] separada. Los elementos de configuración comunes se configuran en las secciones genéricas [Unit] e [Install]. systemd creará dinámicamente unidades de dispositivo para todos los dispositivos del núcleo que estén marcados con la etiqueta "systemd" de udev (por defecto, todos los dispositivos de bloque y de red, y algunos otros). Para etiquetar un dispositivo udev, usa TAG+="systemd en el archivo de reglas de udev. También ten en cuenta que las unidades de dispositivo se nombran según las rutas /sys y /dev que controlan.

Ejemplo

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

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

# Resultará en la generación automática de un archivo nvidia-fallback.device con las secciones [Unit] e [Install] correspondientes configuradas

[Target]

Proporciona capacidades de organización de unidades y establece puntos de sincronización bien conocidos durante el arranque.

Este tipo de unidad no tiene opciones específicas y, como tal, no existe una sección [Target] separada. Los elementos de configuración comunes se configuran en las secciones genéricas [Unit] e [Install].

Ejemplo

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

Desencadena la activación de otras unidades basadas en temporizadores.

Ejemplo

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

[Swap]

Encapsula particiones o archivos de intercambio de memoria del sistema operativo.

Ejemplo

 # Asegurar la existencia del archivo de intercambio
 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: Activar intercambio para /var/vm/swapfile
     Swap:
       What: /var/vm/swapfile
     Install:
       WantedBy: multi-user.target

[Path]

Activa otros servicios cuando objetos del sistema de archivos cambian o son modificados.

Ejemplo

 unit_config:
   - name: Activación del análisis de cobertura de código del repositorio
     type: path
     Unit:
       Description: Activar análisis de cobertura de código en repositorios git modificados
     Path:
       PathChanged: /path/to/git/repo
       Unit: code-coverage-analysis

[Scope]

Gestiona un conjunto de procesos del sistema o remotos/extranjeros.

Las unidades Scope no se configuran mediante archivos de configuración de unidad, sino que se crean únicamente de forma programática mediante las interfaces bus de systemd. A diferencia de las unidades de servicio, las unidades de Scope gestionan procesos creados externamente y no generan procesos por sí mismas. El propósito principal de las unidades de Scope es agrupar procesos de trabajo de un servicio del sistema para organización y para gestión de recursos.

Ejemplo

# *Esta configuración es para un archivo de unidad transitorio, creado programáticamente a través de la API de systemd. No lo copies ni edites.*
 unit_config:
   - name: user-session
     type: scope

     Unit:
       Description: Sesión de usuario
       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]

Agrupa y gestiona procesos del sistema en un árbol jerárquico para fines de gestión de recursos.

El nombre de la porción codifica la ubicación en el árbol. El nombre consiste en una serie de nombres separados por guiones, que describen el camino a la porción desde la porción raíz. Por defecto, las unidades de servicio y Scope se colocan en system.slice, las máquinas virtuales y contenedores registrados mediante systemd-machined(1) se encuentran en machine.slice y las sesiones de usuario gestionadas por systemd-logind(1) en user.slice.

Consulta systemd.slice(5) para más detalles.

[Drop-in]

Proporciona capacidades de anulación para unidades.

Ejemplo

 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

Lanzar

[unit_config: <config-list-entry>:] enabled: (predeterminado: no)

• si el servicio debería iniciarse al arrancar

[unit_config: <config-list-entry>:] state: (predeterminado: stopped)

• estado de activación de la unidad

Dependencias

Ninguna

Ejemplo de Playbook

Ejemplo predeterminado (sin configuraciones de unidad personalizadas especificadas):

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

Par de servicio/socket/montaje:

- hosts: webservers
  roles:
  - role: 0x0i.systemd
    vars:
      unit_config:
      - name: "mi-servicio"
        Unit:
          After: network-online.target
          Wants: network-online.target
          Requires: mi-servicio.socket
        Service:
          User: 'web'
          Group: 'web'
          ExecStart: '/usr/local/bin/mi_servicio $ARGS'
          ExecReload: '/bin/kill -s HUP $MAINPID'
        Install:
          WantedBy: 'multi-user.target'
      - name: "mi-servicio"
        type: "socket"
        Socket:
          ListenStream: '0.0.0.0:4321'
          Accept: 'true'
        Install:
          WantedBy: 'sockets.target'
      - name: "var-data-mi_servicio"
        type: "mount"
        path: "/run/systemd/system"
        Mount:
          What: '/dev/nvme0'
          Where: '/var/data/mi_servicio'
        Install:
          WantedBy: 'multi-user.target'

Licencia

MIT

Información del Autor

Este rol fue creado en 2019 por O1.IO.