Automatización de ServiceNow con Red Hat Ansible Automatización Platform

Se insta regularmente a los administradores de sistemas a responder rápidamente a las solicitudes de servicio para satisfacer mejor las necesidades de las empresas y los usuarios, y cada vez más administradores confían en Ansible para hacerlo. ¿Cómo podemos nosotros, como administradores de sistemas, responder más rápidamente cuando surgen estas solicitudes?

La gestión de servicios de TI (ITSM) es un conjunto de políticas y procesos para la gestión y el soporte de los servicios de TI. El objetivo principal de ITSM es aumentar el valor de la cadena de servicio al cliente. Pero sin el soporte de automatización adecuado, la prestación de servicios de TI puede convertirse rápidamente en una gran pérdida de tiempo para los administradores.

Aquí es donde entran en juego Red Hat Ansible Automatización Platform y Red Hat Ansible Certified Content Collection for ServiceNow. Ansible Automatización (con la ayuda del contenido de Ansible existente) puede automatizar casi cualquier tarea, mientras que los módulos de esta colección certificada permiten mantener actualizada la información de ServiceNow.

Esta colección fue diseñada y desarrollada por el XLAB Steampunk en estrecha colaboración con Red Hat Ansible, con especial atención a los usuarios finales. Los módulos de ServiceNow tienen una interfaz de usuario intuitiva respaldada por una implementación sólida, que brinda soporte para las cosas que los usuarios de Ansible esperan (por ejemplo, modo de verificación y detección de cambios).

En este artículo, muestro algunos ejemplos de playbooks de Ansible que admiten tareas administrativas esenciales como:

  1. Actualización de incidencias, problemas y solicitudes de cambio
  2. Actualización de la base de datos de administración de configuración de ServiceNow (CMDB)
  3. Utilice la CMDB como fuente de inventario
Índice

Instalación de la recopilación de contenido certificado para ServiceNow

Puedes descargar el servicenow.itsm Colección de centro de automatización o Ansible Galaxy. Antes de poder acceder al contenido de Automatización Hub, primero debe configurar sus credenciales en el archivo de configuración de Ansible. Para obtener más detalles, consulte "Práctico con las colecciones de Ansible"entrada en el blog.

Una vez que tenga sus credenciales, puede instalar la colección ServiceNow ejecutando el siguiente comando:

$ ansible-galaxy collection install servicenow.itsm

Si todo sale según lo planeado, ahora tiene acceso a los siguientes módulos:

  1. servicenow.itsm.incidente para la gestión de tickets de incidencias
  2. servicenow.itsm.problema interactuar con los problemas
  3. servicenow.itsm.cambio_solicitud para gestionar los cambios
  4. servicenow.itsm.configuration_item para la gestión de la CMDB

Cada uno de los módulos también tiene una contraparte que le brinda acceso de solo lectura a los registros de ServiceNow.

La colección de contenido certificado para ServiceNow también contiene un complemento de inventario llamado servicenow.itsm.ahora lo que le permite utilizar CMDB como fuente de inventario.

Para verificar que nada salió mal, vea la documentación de uno de los módulos ejecutando el siguiente comando:

$ ansible-doc servicenow.itsm.incident

Si Ansible no nos ha gritado, está listo para irse.

Gestione incidentes, de forma Ansible

Crear un nuevo ticket de problema con Ansible es relativamente sencillo, pero antes de que pueda hacerlo, debe decirle a Ansible dónde reside su instancia de ServiceNow y qué credenciales usar. Para hacer esto, establezca tres variables de entorno:

$ export SN_HOST='https://dev12345.service-now.com'
$ export SN_USERNAME='user'
$ export SN_PASSWORD='pass'

Ahora que sus credenciales están listas, puede crear un nuevo incidente. El libro de jugadas mínimo de Ansible se vería así:

---
- hosts: localhost
  gather_facts: false
  tasks:
    - name: Create new incident
      servicenow.itsm.incident:
        state: new
        short_description: Demo incident

Una vez que el libro de jugadas anterior haya terminado de ejecutarse, encontrará un nuevo problema en ServiceNow.

Figura 1: interfaz de usuario web de ServiceNow.

Puede actualizar un incidente existente proporcionando un número de ticket o ID del sistema del registro de incidentes. Ansible comparará los estados actual y deseado del incidente y realizará los cambios necesarios para mantenerlos sincronizados.

---
- hosts: localhost
  gather_facts: false
  tasks:
    - name: Update incident
      servicenow.itsm.incident:
        number: INC0010022
        state: in_progress

Si está ejecutando Ansible con el --diff switch, informará los cambios que ha implementado en el registro de incidentes:

TASK [Update incident with a problem information] ***************************
--- before
+++ after
@@ -50,7 +50,7 @@
     "parent": "",
     "parent_incident": "",
     "priority": "5",
-    "state": "new",
+    "state": "in_progress",
     "reassignment_count": "0",
     "reopen_count": "0",
     "reopened_by": "",
@@ -71,10 +71,10 @@
     "sys_domain": "global",
     "sys_domain_path": "/",
     "sys_id": "2396e496074f2010d4a1fa9e7c1ed01c",
-    "sys_mod_count": "0",
+    "sys_mod_count": "1",
     "sys_tags": "",
     "sys_updated_by": "admin",

También puede eliminar un incidente existente configurando el Expresar parámetro a absent.

---
- hosts: localhost
  gather_facts: false
  tasks:
    - name: Delete incident
      servicenow.itsm.incident:
        number: INC0010022
        state: absent

Puede interactuar con problemas y solicitudes de cambio de la misma manera. Sin embargo, el manejo de elementos de configuración es un poco diferente, así que centrémonos en esa área a continuación.

Actualización de la CMDB

Dado que ServiceNow CMDB tiene varios tipos de elementos de configuración, debe especificar el sys_class_name parámetro al agregar nuevos elementos. Por defecto, el servicenow.itsm.configuration_item El módulo utilizará el cmdb_ci nombre de clase del sistema, pero puede cambiarlo a cualquier otro derivado de cmdb_ci clasificar.

---
- name: Demonstrate CMDB management
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Simulate VM creation
      ansible.builtin.set_fact:
        instance:
          name: some-name
          id: vm1234567890
          public_ip_address: 1.2.3.4

    - name: Register the newly-created VM instance
      servicenow.itsm.configuration_item:
        name: "{{ instance.name }}"
        sys_class_name: cmdb_ci_vm_instance
        ip_address: "{{ instance.public_ip_address }}"
        other:
          vm_inst_id: "{{ instance.id }}"

Usaste el genérico otro parámetro que puede contener pares clave-valor arbitrarios en la última tarea. Debido a que las tablas de ServiceNow son extensibles, todos los módulos tienen este parámetro. Puedes usar el otro parámetro para definir valores de columna que los módulos no exponen como parámetros de nivel superior. Todos los módulos de ServiceNow Ansible tienen esta configuración.

Al actualizar o eliminar un elemento existente, no necesita especificar el nombre de la clase del sistema ya que el módulo recuperará automáticamente el nombre del registro actual. Pero, debe proporcionar una sys_id valor del parámetro.

---
- name: Demonstrate CMDB item update and deletion
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Update the VM state
      servicenow.itsm.configuration_item:
        sys_id: b0ccabf1c0a80009001f14fd151d8df0
        install_status: in_maintenance

    - name: Remove item from CMDB
      servicenow.itsm.configuration_item:
        sys_id: b0ccabf1c0a80009001f14fd151d8df0
        state: absent

Inventario dinámico

La CMDB también puede servir como fuente de inventario. Dado que los elementos de configuración que representan servidores y máquinas virtuales (VM) suelen contener direcciones IP, puede utilizarlos como fuente de inventario.

La configuración mínima del complemento de inventario se ve así:

---
plugin: servicenow.itsm.now

Cuando se usa como fuente de inventario, el complemento enumera todos los servidores en el cmdb_ci_servidor gráfico. Puede agrupar y filtrar automáticamente los hosts de inventario según las condiciones especificadas en el por grupo posibilidad de configuración:

---
plugin: servicenow.itsm.now
group_by:
  os:
    includes:
      - Linux Red Hat
      - Windows XP

En el ejemplo anterior, Ansible creó dos grupos: uno para Windows XP y otro para equipos con Linux. El complemento de inventario filtra tanto como sea posible en el backend, minimizando la cantidad de datos cargados.

También puede configurar los valores de columna que agrega el complemento de inventario como variables de host:

---
plugin: servicenow.itsm.now

columns:
  - name
  - classification
  - cpu_type

group_by:
  os:
    includes:
      - Linux Red Hat
      - Windows XP

Para probar la configuración, ejecute el siguiente comando:

$ ansible-inventory -i inventory.now.yaml --graph --vars

Suponiendo que ha almacenado la configuración de inventario en el inventory.now.yaml archivar. La salida debería verse así:

@all:
 |[email protected]_Red_Hat:
 |  |--P1000019
 |  |  |--{ansible_host = my1.server.com}
 |  |  |--{classification = Production}
 |  |  |--{cpu_type = Intel}
 |  |  |--{name = SAP-SD-01}
 |[email protected]_XP:
 |  |--P1000020
 |  |  |--{ansible_host = my2.server.com}
 |  |  |--{classification = Production}
 |  |  |--{cpu_type = Intel}
 |  |  |--{name = SAP-SD-02}
 |[email protected]:

Y ahora que sabe cómo usar los módulos individuales y el complemento de inventario, es hora de la gran final.

Resolución automática de una solicitud de cambio estándar

Las solicitudes de cambio estándar son procedimientos preaprobados con un riesgo mínimo y estas propiedades los convierten en los principales candidatos para la automatización.

Entonces, sin más preámbulos, aquí está el libro de jugadas que:

  1. Buscar la solicitud de modificación por su número
  2. Marcar la solicitud de cambio como procesada
  3. Recuperar el elemento de configuración afectado de la solicitud de cambio
  4. Realizar las operaciones solicitadas sobre dicho elemento de configuración, y finalmente
  5. Cerrar la solicitud de cambio
---
- hosts: localhost
  gather_facts: false
  tasks:
    - name: Mark change request as in progress
      servicenow.itsm.change_request:
        number: "{{ change_number }}"
        state: implement
      register: change

    - name: Fetch configuration item we will update
      servicenow.itsm.configuration_item_info:
        sys_id: "{{ change.record.cmdb_ci }}"
      register: citem

    - name: Create an in-memory inventory with the item
      ansible.builtin.add_host:
        name: host_to_update
        ansible_host: "{{ citem.record.ip_address }}"

- hosts: host_to_update
  tasks:
    - name: Simulate some work
      ansible.builtin.debug:
        msg: Doing real work here

- hosts: localhost
  gather_facts: false
  tasks:
    - name: Mark change request as done
      servicenow.itsm.change_request:
        number: "{{ change_number }}"
        state: closed

¿Quién hubiera pensado que podrías poner tanta genialidad en un libro de jugadas?

El futuro es automático

He cubierto bastante, pero solo he logrado arañar la superficie de lo que es posible. Así que dirígete a centro de automatización Donde galaxia ansible, descargue la colección ServiceNow ITSM Ansible y comience a explorar. También puede ver esta nueva solución en acción en este seminario en línea.

Si necesita ayuda para automatizar e integrar sus procesos de ServiceNow con Red Hat Ansible Automatización Platform, comuníquese con nuestro equipo en XLAB Steampunk que puede ponerlo en funcionamiento en poco tiempo.

Artículos de interés

Subir