Rol de servicio systemd de Ansible

Un rol de Ansible que crea y configura archivos de unidad de servicio systemd. Esto permite que ciertos servicios se ejecuten automáticamente en segundo plano, habilitarlos y deshabilitarlos para eventos específicos, gestionar grupos de procesos y configurar dependencias en 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 de las secciones Unit, Service e Install.
3. Notificar a systemd que existen nuevos archivos de servicio. Reiniciar el servicio.
4. Habilitar la autorun del servicio al iniciar si es necesario.

Requisitos

Este rol requiere acceso como root, así que ejecútalo en un playbook con el parámetro global become: yes, o invoca el rol en tu playbook de la siguiente manera:

- hosts: apps
  roles:
    - role: systemd_service
      become: yes

Variables del Rol

Todos los servicios necesarios pueden ser especificados por la variable 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 especificar si el servicio debería iniciarse al arrancar, usa el parámetro enabled.

systemd_service:
  service:
    service_name:
    enabled:

Todos los demás parámetros disponibles que deben ser especificados para una clave service_name específica (como parámetros anidados) se enumeran 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 de texto que describe la unidad

Los siguientes dos parámetros configuran dependencias en otras unidades. Si se activa el servicio, también se activarán las unidades listadas allí. Si una de las unidades 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 una unidad de esta se desactiva. Los parámetros pueden consistir en varios nombres de unidades separados por espacios. También pueden especificarse más de una vez.

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

Para configurar el orden en el que se inician o se detienen los servicios, usa los siguientes parámetros. Nota que si no hay dependencias de orden entre las unidades, se apagan o encienden 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 tomar los siguientes valores:

• simple - este tipo supone que el servicio se lanzará de inmediato. El proceso no debe bifurcarse. No uses este tipo si otros servicios tienen dependencias de orden sobre el lanzamiento 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 daemon.
• forking - supone que el servicio se inicia una vez y el proceso se bifurca con la finalización del proceso padre. Este tipo se usa para lanzar daemons clásicos. Si se utiliza este modo, se recomienda usar también el parámetro pid_file (ver más abajo), para que systemd pueda identificar el proceso principal del daemon.

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 comience con las unidades siguientes;
• dbus - se espera que el daemon adquiera un nombre en el bus D-Bus;
• notify - el daemon 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 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 en consola, no es útil como una herramienta de ordenación general de unidades.

Establece una ruta al archivo PID para usar el tipo de inicio forking.

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

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

user:
group:

Establece una prioridad de programación para la unidad con el siguiente parámetro. Toma un entero entre -20 (la más alta prioridad) y 19 (la más baja prioridad).

nice:    # El nivel de prioridad predeterminado para el servicio

Un nivel de ajuste para el killer de Out-Of-Memory para el proceso se especifica con la siguiente opción. Toma un valor entero de -1000 (deshabilitar OOM) a 1000 (preferir OOM).

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 a ejecutar 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 previamente para el parámetro.

# Comandos que se ejecutan cuando este servicio se inicia
# A menos que `type` sea `oneshot`, debe darse exactamente un comando aquí
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 que se ejecutan para detener el servicio iniciado a través de `exec_start`
exec_stop:

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

# Comandos que se ejecutan para activar una recarga de configuración en el servicio
exec_reload:

Establece si el servicio debe reiniciarse cuando el proceso del servicio (el proceso principal del servicio o uno especificado por los parámetros 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' o 'exec_reload') sale, es eliminado 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 limpiamente (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 no cero, sea terminado por una señal, cuando una operación se agote, y cuando se active el tiempo de espera del watchdog configurado;
• 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 capturada que no se especificó como un estado de salida limpio;
• on-abort - el servicio se reiniciará solo si se agota el tiempo de espera del watchdog para el servicio;
• always - el servicio se reiniciará de todos modos.

# Cuando el servicio debe ser reiniciado
restart:

Puedes especificar un retraso de tiempo para los comandos mencionados anteriormente con los siguientes parámetros. Toman un valor en segundos o un valor de tiempo como '5min 20s'. El parámetro restart_sec configura el tiempo de espera antes de reiniciar un servicio (como se configura con restart). La opción timeout_sec define el tiempo de espera 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 un diccionario de variables y sus valores. 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 esto, establece el valor del parámetro environment_file como la ruta del archivo.

environment:       # Un diccionario con variables de entorno
environment_file:  # Ruta a un archivo con variables de entorno

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

working_directory:

Los siguientes parámetros permiten elegir dónde se deben conectar los descriptores de archivo (STDIN, STDOUT, STDERR) de los procesos ejecutados. El parámetro standard_input toma los valores "null", "tty", "tty-force", "tty-fail", "socket" o "fd". El parámetro standard_output puede ser igual a "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 los de standard_output.

standard_input:
standard_output:
standard_error:

Si se especifica "tty", "tty-force" o "tty-fail" para alguno de los parámetros "standard_*", entonces puedes especificar una ruta para el tty.

tty_path:

Si el servicio debe estar en estado reiniciado/recargado/iniciado/detenido después de que se crea o modifica el servicio.

state:

Puede tomar los valores: restarted (predeterminado), reloaded, started, stopped.

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 ser utilizados más de una vez o pueden especificarse listas de nombres de unidad separados por espacios. Las listas incluyen unidades que refieren 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 de servicio por defecto
        railsapp:
          # Nombre del servicio
          service_name: 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 actual
          working_directory: "/var/www/myapp"
          # Especificar una variable de entorno
          environment: {ENVVAR: value}
          # Ejecutar los procesos bajo este usuario y grupo
          user: "deploy"
          group: "deploy"
          # Reiniciar el servicio solo cuando no se haya obtenido un código de salida limpio o señal
          restart: "on-failure"
          # Intentar activar 'redis' si es posible
          wants: "redis.service"
          # Activar 'postgresql' o dejar de funcionar en caso de fallo
          requires: "postgresql.service"
          # la unidad multi-user.target prefiere que se ejecute el servicio
          wanted_by: "multi-user.target"

Licencia

Licenciado bajo la Licencia MIT.