A los administradores de sistemas se les pide regularmente que completen rápidamente las solicitudes de servicio para satisfacer mejor las necesidades comerciales y de 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ápido 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 enfoque principal de ITSM es aumentar el valor de la cadena de servicio de los clientes. 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.
[ También te puede interesar: Guía de inicio rápido de Ansible para administradores de sistemas de Linux]
Aquí es donde entran en juego Red Hat Ansible Automation Platform y Red Hat Ansible Certified Content Collection para ServiceNow. Ansible Automation (con algo de ayuda del contenido de Ansible existente) puede automatizar casi cualquier tarea, mientras que los módulos de esta colección certificada le permiten mantener la información de ServiceNow actualizada.
Esta colección fue diseñada y desarrollada por el equipo XLAB Steampunk en estrecha colaboración con Red Hat Ansible, teniendo en cuenta específicamente a los usuarios finales. Los módulos de ServiceNow tienen una interfaz de usuario intuitiva respaldada por una implementación robusta, que ofrece soporte para las cosas que los usuarios de Ansible esperan (por ejemplo, modo de verificación y detección de cambios).
En esta publicación, muestro algunos ejemplos de Playbooks de Ansible que se encargan de tareas administrativas esenciales como:
- Actualización de incidentes, problemas y solicitudes de cambio
- Actualización de la base de datos de administración de configuración de ServiceNow (CMDB)
- Uso de la CMDB como fuente de inventario
Instalación de la recopilación de contenido certificado para ServiceNow
Puede descargar el servicenow.itsm Recopilación desde el centro de automatización o Ansible Galaxy. Antes de poder acceder al contenido en el centro de automatización, primero debe configurar sus credenciales en el archivo de configuración de Ansible. Para obtener más información, consulte la publicación de blog "Manos a la obra con las colecciones de Ansible".
Una vez que tenga sus credenciales, puede instalar ServiceNow Collection 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:
- servicenow.itsm.incident para gestionar tickets de incidentes
- servicenow.itsm.problema para interactuar con problemas
- servicenow.itsm.change_request para manejar cambios
- servicenow.itsm.configuration_item para gestionar 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.now que le permite utilizar CMDB como fuente de inventario.
Para verificar que nada salió mal, muestre la documentación de uno de los módulos ejecutando el siguiente comando:
$ ansible-doc servicenow.itsm.incident Si Ansible no nos gritó, ya está todo listo.
Gestionar incidentes, al estilo Ansible
Crear un nuevo ticket de incidente con Ansible es razonablemente sencillo, pero antes de que pueda hacerlo, debe indicarle a Ansible dónde se encuentra su instancia de ServiceNow y qué credenciales usar. Hágalo configurando tres variables de entorno:
$ export SN_HOST='https://dev12345.service-now.com'
$ export SN_USERNAME='user'
$ export SN_PASSWORD='pass' Ahora que tiene sus credenciales 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 termine de ejecutarse, encontrará un nuevo incidente en ServiceNow.
Puede actualizar un incidente existente proporcionando un número de ticket o una identificación del sistema del registro del incidente. Ansible comparará los estados actual y deseado del incidente y realizará los cambios necesarios para sincronizarlos.
---
- hosts: localhost
gather_facts: false
tasks:
- name: Update incident
servicenow.itsm.incident:
number: INC0010022
state: in_progress
Si ejecuta Ansible con --diff switch, informará qué cambios implementó 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 estado parámetro a absent .
---
- hosts: localhost
gather_facts: false
tasks:
- name: Delete incident
servicenow.itsm.incident:
number: INC0010022
state: absent Puede interactuar con los problemas y las solicitudes de cambio de la misma manera. Sin embargo, administrar elementos de configuración es un poco diferente, así que centrémonos en esta área a continuación.
Actualización de la CMDB
Debido a que ServiceNow CMDB tiene más de un tipo de elemento de configuración, debe especificar el sys_class_name parámetro al agregar nuevos elementos. De forma predeterminada, servicenow.itsm.configuration_item módulo utilizará el cmdb_ci nombre de clase del sistema, pero puede cambiarlo a cualquier otro derivado de cmdb_ci clase.
---
- 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 para establecer valores de columna que los módulos no exponen como parámetros de nivel superior. Todos los módulos de ServiceNow Ansible tienen este parámetro.
Al actualizar o eliminar un elemento existente, no es necesario que especifique el nombre de la clase del sistema porque el módulo recuperará automáticamente el nombre del registro actual. Sin embargo, debe proporcionar un 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 para el complemento de inventario se ve así:
---
plugin: servicenow.itsm.now Cuando se utiliza como fuente de inventario, el complemento mostrará una lista de todos los servidores del cmdb_ci_server mesa. Puede agrupar y filtrar automáticamente los hosts de inventario en función de las condiciones especificadas en group_by opción 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 realiza el mayor filtrado posible en el backend, lo que minimiza la cantidad de datos descargados.
También puede configurar qué valores de columna 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, ejecuta el siguiente comando:
$ ansible-inventory -i inventory.now.yaml --graph --vars
Suponiendo que almacenó la configuración del inventario en el inventory.now.yaml expediente. La salida debería verse así:
@all:
|--@Linux_Red_Hat:
| |--P1000019
| | |--{ansible_host = my1.server.com}
| | |--{classification = Production}
| | |--{cpu_type = Intel}
| | |--{name = SAP-SD-01}
|--@Windows_XP:
| |--P1000020
| | |--{ansible_host = my2.server.com}
| | |--{classification = Production}
| | |--{cpu_type = Intel}
| | |--{name = SAP-SD-02}
|--@ungrouped: Y ahora que sabe cómo usar 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 aprobados previamente con riesgos mínimos, 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:
- Busque la solicitud de cambio por su número
- Marcar la solicitud de cambio como en la que se está trabajando
- Recuperar el elemento de configuración afectado de la solicitud de cambio
- Realizar las operaciones solicitadas en dicho elemento de configuración y finalmente
- 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 podría haber pensado que uno puede meter tanta genialidad en un solo libro de jugadas?
[ ¿Busca más información sobre la automatización de sistemas? Comience con The Automated Enterprise, un libro gratuito de Red Hat. ]
El futuro es automático
Cubrí bastante, pero solo logré arañar la superficie de lo que es posible. Así que diríjase al centro de automatización o Ansible Galaxy, descargue ServiceNow ITSM Ansible Collection y comience a explorar. También puede ver esta nueva solución en acción en este seminario web.
Si necesita ayuda con la automatización de sus procesos de ServiceNow y la integración con Red Hat Ansible Automation Platform, comuníquese con nuestro equipo en XLAB Steampunk, quienes pueden ayudarlo a ponerse en marcha de inmediato.