Rol de servicio systemd de Ansible

Un rol de Ansible que crea y configura archivos de unidad de servicio systemd. Permite ejecutar ciertos servicios automáticamente en segundo plano, habilitarlos y deshabilitarlos para eventos específicos, gestionar grupos de procesos y configurar dependencias con otras unidades.

El rol incluye las siguientes tareas:

1. Crear un archivo de servicio systemd en /etc/systemd/system/ con un nombre especificado service_name.service para cada elemento systemd_service.
2. Configurar opciones importantes en las secciones Unit, Service e Install.
3. Notificar a systemd que existen nuevos archivos de servicio. Reiniciar el servicio.
4. Habilitar que el servicio se inicie automáticamente al arrancar, si es necesario.

Este rol se puede ejecutar en todas las versiones de Ubuntu.

Requisitos

Este rol requiere acceso de root, por lo que debes ejecutarlo en un playbook con el parámetro global become: yes, o invocar el rol en tu playbook de la siguiente manera:

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

Variables del rol

Todos los servicios necesarios se pueden especificar mediante la variable de diccionario systemd_service (ver defaults/main.yml):

systemd_service: {}

Para cada servicio necesitas establecer service_name y los valores de parámetros necesarios. Por ejemplo, para indicar si el servicio debe iniciarse al arrancar, usa el parámetro enabled.

systemd_service:
  service_name:
    enabled:

Todos los demás parámetros disponibles que deben especificarse para una clave service_name (como parámetros anidados) se indican a continuación.

Opciones de la sección Unit

Este grupo de parámetros incluye información genérica sobre la unidad.

description:   # Una cadena descriptiva sobre la unidad

Los siguientes dos parámetros configuran dependencias en otras unidades. Si se activa el servicio, las unidades listadas allí también se activarán. Si alguna de las unidades en requires no puede ejecutarse o falla repentinamente, el servicio también se detendrá. En cuanto a la lista wants, el servicio no se detendrá si alguna unidad de esta se desactiva. Los parámetros pueden consistir en varios nombres de unidad separados por espacios. También pueden especificarse más de una vez.

requires:   # Unidades que deben iniciarse junto con el servicio
wants:      # Unidades que deberían iniciarse junto con el servicio

Para configurar el orden en el que se inician o detienen los servicios, utiliza los siguientes parámetros. Nota que si las unidades no tienen dependencias de orden entre ellas, se apagan o se inician simultáneamente. Ambos parámetros se establecen mediante listas de unidades separadas por espacios.

after:   # Unidades que deben iniciarse después del servicio
before:  # Unidades que deben iniciarse antes del servicio

Opciones de la sección Service

Esta sección incluye información sobre el servicio y el proceso que supervisa. El parámetro type configura el tipo de inicio del proceso para esta unidad de servicio.

type:

Puede tener los siguientes valores:

• simple - este tipo asume que el servicio se lanzará inmediatamente. El proceso no debe bifurcarse. No use este tipo si otros servicios tienen dependencias de orden sobre el inicio del servicio. Si el servicio ofrece funcionalidad a otros procesos en el sistema, sus canales de comunicación deben estar instalados antes de que se inicie el demonio.
• forking - asume que el servicio se inicia una vez y el proceso se bifurca con la finalización del proceso padre. Este tipo se utiliza para lanzar demonios clásicos. Si se utiliza este modo, se recomienda usar el parámetro pid_file también (ver más abajo), para que systemd pueda identificar el proceso principal del demonio.

Otros valores tienen un comportamiento similar al valor simple. Sin embargo, tienen algunas diferencias:

• oneshot - se espera que el servicio salga antes de que systemd inicie unidades posteriores;
• dbus - se espera que el demonio adquiera un nombre en el bus de D-Bus;
• notify - el demonio envía un mensaje de notificación a través de sd_notify(3) o una llamada similar cuando ha terminado de iniciarse;
• idle - la ejecución real del binario del servicio se retrasa hasta que se despachan todos los trabajos activos. Nota que este tipo es útil solo para mejorar la salida de la consola, no se utiliza como una herramienta general de orden de las unidades.

Establezca una ruta al archivo PID para utilizar el tipo de inicio forking.

pid_file:    # Toma un nombre de archivo absoluto apuntando al archivo PID de este demonio

Puedes especificar el usuario y el grupo UNIX bajo los cuales debe ejecutarse el servicio. Los parámetros toman un solo nombre de usuario o grupo, o un ID numérico como valor. Para servicios del sistema y para servicios de usuario del usuario root, el valor predeterminado es root, que se puede cambiar a otro. Para los servicios de usuario de cualquier otro usuario, no se permite cambiar la identidad del usuario. Por lo tanto, el único valor permitido es el mismo usuario bajo el cual se está ejecutando el administrador de servicios del usuario. Si no se establece ningún grupo, se usa el grupo predeterminado del usuario.

user:
group:

Establezca una prioridad de programación para la unidad con el siguiente parámetro. Toma un entero entre -20 (la mayor prioridad) y 19 (la menor prioridad).

nice:    # El nivel de prioridad predeterminado para el servicio

Un nivel de ajuste para el killer de Fuera de Memoria (OOM) para el proceso se especifica con la siguiente opción. Toma un valor entero de -1000 (desactivar OOM killing) a 1000 (OOM killing es preferible).

oom_score_adjust:

Los siguientes parámetros te permiten especificar comandos que se ejecutarán dependiendo del estado de tu servicio. Los parámetros pueden usarse más de una vez o sus valores pueden incluir varios comandos. Múltiples líneas de comando pueden concatenarse en una sola directiva separándolas con punto y coma. El comando que se ejecuta debe ser un nombre de ruta absoluto. Puede contener espacios, pero no se permiten caracteres de control. Para cada comando, el primer argumento debe ser una ruta absoluta a un ejecutable. Una cadena vacía restablecerá la lista de comandos especificados anteriormente para el parámetro.

# Comandos que se ejecutan cuando se inicia este servicio
# A menos que `type` sea `oneshot`, aquí debe darse exactamente un comando
exec_start:

# Comandos que se ejecutan antes de los comandos `exec_start`
exec_start_pre:

# Comandos que se ejecutan después de los comandos `exec_start`
exec_start_post:

# Comandos a ejecutar para detener el servicio iniciado a través de `exec_start`
exec_stop:

# Comandos que se ejecutan después de que se detiene el servicio
exec_stop_post:

# Comandos a ejecutar para desencadenar una recarga de configuración en el servicio
exec_reload:

Establezca si el servicio debe reiniciarse cuando el proceso del servicio (el principal o uno especificado por los parámetros 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' o 'exec_reload') sale, es killado, o se alcanza un tiempo de espera. El parámetro restart toma uno de los siguientes valores:

• no (por defecto) - el servicio no se reiniciará;
• on-success - el servicio se reiniciará solo cuando el proceso del servicio salga correctamente (con un código de salida de 0, o una de las señales SIGHUP, SIGINT, SIGTERM o SIGPIPE);
• on-failure - el servicio se reiniciará cuando el proceso salga con un código de salida diferente de cero, sea terminado por una señal, cuando un operación se agote, y cuando se active el tiempo de espera configurado para el watchdog;
• on-abnormal - el servicio se reiniciará cuando el proceso sea terminado por una señal, cuando una operación se agote, o cuando se active el tiempo de espera del watchdog;
• on-watchdog - el servicio se reiniciará solo si el proceso del servicio sale debido a una señal no interceptada que no se especificó como un estado de salida limpio;
• on-abort - el servicio se reiniciará solo si expira el tiempo de espera del watchdog para el servicio;
• always - el servicio se reiniciará de todos modos.

# Cuándo debe reiniciarse el servicio
restart:

Puedes especificar un tiempo de espera para los comandos antes mencionados con los siguientes parámetros. Toman un valor en segundos o un valor de intervalo de tiempo como '5min 20s'. El parámetro restart_sec configura el tiempo a esperar antes de reiniciar un servicio (como se configura con restart). La opción timeout_sec define el tiempo a esperar para el procesamiento de comandos de inicio/parada.

restart_sec:
timeout_sec:

Usa el parámetro environment para establecer una lista de variables de entorno para los procesos ejecutados. Incluye una lista de variables separadas por espacios y sus valores. El parámetro puede usarse más de una vez. Si se asigna una cadena vacía a esta opción, se restablecerá la lista de variables de entorno. Si algún valor contiene un espacio, usa comillas dobles para la asignación.

También puedes leer las variables de entorno desde un archivo de texto. Para ello, establece el valor del parámetro environment_file como la ruta del archivo.

environment:       # Una lista de asignaciones de variables separadas por espacios
environment_file:  # Ruta a un archivo con variables de entorno

Un directorio de trabajo se especifica mediante el siguiente parámetro. Se establece como el actual antes de que se lancen los comandos de inicio.

working_directory:

Los siguientes parámetros permiten elegir a dónde deben conectarse los descriptores de archivos (STDIN, STDOUT, STDERR) de los procesos ejecutados. El parámetro standard_input toma valores "null", "tty", "tty-force", "tty-fail", "socket" o "fd". El parámetro standard_output puede ser "inherit", "null", "tty", "journal", "syslog", "kmsg", "journal+console", "syslog+console", "kmsg+console", "socket" o "fd". Los valores disponibles para standard_error son idénticos a standard_output.

standard_input:
standard_output:
standard_error:

Opciones de la sección Install

Estas variables de sección llevan información de instalación para la unidad. Los siguientes dos parámetros pueden usarse más de una vez, o pueden especificarse listas de nombres de unidad separadas por espacios. Las listas incluyen unidades que hacen referencia a este servicio desde sus campos requires y wants.

wanted_by:
required_by:

Dependencias

Ninguna

Ejemplo de playbook

- hosts: app
  roles:
    - role: systemd-service
      systemd_service:
        # Nombre del servicio
        railsapp:
          # Iniciar el servicio al arrancar
          enabled: Yes
          # Ejecutar el comando con los argumentos especificados cuando se inicie el servicio
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Usar el directorio especificado como el actual
          working_directory: "/var/www/myapp"
          # Ejecutar los procesos bajo este usuario y grupo
          user: "deploy"
          group: "deploy"
          # Reiniciar el servicio solo cuando no se obtuvo un código de salida limpio o una señal
          restart: "on-failure"
          # Intentar activar 'redis' si es posible
          wants: "redis.service"
          # Activar 'postgresql' o dejar de trabajar en caso de fallo
          requires: "postgresql.service"
          # La unidad multi-user.target prefiere que se ejecute el servicio
          wanted_by: "multi-user.target"

Licencia

Con licencia bajo la Licencia MIT.