Les administrateurs système sont régulièrement invités à répondre rapidement aux demandes de service afin de mieux répondre aux besoins des entreprises et des utilisateurs, de plus en plus d'administrateurs s'appuyant sur Ansible pour le faire. Comment pouvons-nous, en tant qu'administrateurs système, répondre plus rapidement lorsque ces demandes surviennent ?
La gestion des services informatiques (ITSM) est un ensemble de politiques et de processus pour la gestion et le support des services informatiques. L'ITSM se concentre principalement sur l'augmentation de la valeur de la chaîne de service des clients. Mais sans une prise en charge appropriée de l'automatisation, la fourniture de services informatiques peut rapidement devenir une perte de temps majeure pour les administrateurs.
[ Vous pourriez également aimer : Guide de démarrage rapide d'Ansible pour les administrateurs système Linux ]
C'est là qu'interviennent Red Hat Ansible Automation Platform et Red Hat Ansible Certified Content Collection for ServiceNow. Ansible Automation (avec l'aide du contenu Ansible existant) peut automatiser à peu près n'importe quelle tâche, tandis que les modules de cette collection certifiée vous permettent de maintenir à jour les informations de ServiceNow.
Cette collection a été conçue et développée par l'équipe XLAB Steampunk en étroite collaboration avec Red Hat Ansible, en gardant spécifiquement à l'esprit les utilisateurs finaux. Les modules ServiceNow ont une interface utilisateur intuitive soutenue par une implémentation robuste, offrant une prise en charge des éléments attendus par les utilisateurs d'Ansible (par exemple, le mode de vérification et la détection des modifications).
Dans cet article, je présente quelques exemples de Playbooks Ansible qui s'occupent des tâches administratives essentielles telles que :
- Mettre à jour les incidents, les problèmes et les demandes de modification
- Mettre à jour la base de données de gestion de configuration ServiceNow (CMDB)
- Utilisation de CMDB comme source d'inventaire
Installation de la collection de contenu certifié pour ServiceNow
Vous pouvez télécharger le servicenow.itsm Collecte depuis le hub d'automatisation ou Ansible Galaxy. Avant de pouvoir accéder au contenu du hub d'automatisation, vous devez d'abord configurer vos informations d'identification dans le fichier de configuration Ansible. Pour plus de détails, veuillez vous référer à l'article de blog "Hands On With Ansible Collections".
Une fois que vous disposez de vos identifiants, vous pouvez installer la collection ServiceNow en exécutant la commande suivante :
$ ansible-galaxy collection install servicenow.itsm Si tout se passe comme prévu, vous avez désormais accès aux modules suivants :
- servicenow.itsm.incident pour la gestion des tickets d'incident
- servicenow.itsm.problem pour interagir avec les problèmes
- servicenow.itsm.change_request pour gérer les modifications
- servicenow.itsm.configuration_item pour la gestion de la CMDB
Chacun des modules a également un équivalent qui vous donne un accès en lecture seule aux enregistrements ServiceNow.
La collection de contenu certifié pour ServiceNow contient également un plug-in d'inventaire appelé servicenow.itsm.now qui vous permet d'utiliser CMDB comme source d'inventaire.
Pour vérifier que rien ne s'est mal passé, affichez la documentation de l'un des modules en exécutant la commande suivante :
$ ansible-doc servicenow.itsm.incident Si Ansible ne nous a pas crié dessus, vous êtes prêt.
Gérer les incidents, à la manière d'Ansible
La création d'un nouveau ticket d'incident à l'aide d'Ansible est relativement simple, mais avant de pouvoir le faire, vous devez indiquer à Ansible où se trouve votre instance ServiceNow et quelles informations d'identification utiliser. Pour ce faire, définissez trois variables d'environnement :
$ export SN_HOST='https://dev12345.service-now.com'
$ export SN_USERNAME='user'
$ export SN_PASSWORD='pass' Maintenant que vos informations d'identification sont prêtes, vous pouvez créer un nouvel incident. Le playbook minimal d'Ansible ressemblerait à ceci :
---
- hosts: localhost
gather_facts: false
tasks:
- name: Create new incident
servicenow.itsm.incident:
state: new
short_description: Demo incident Une fois l'exécution du playbook précédent terminée, vous trouverez un nouvel incident répertorié dans ServiceNow.
Vous pouvez mettre à jour un incident existant en fournissant un numéro de ticket ou un identifiant système de l'enregistrement de l'incident. Ansible comparera les états actuel et souhaité de l'incident et apportera les modifications nécessaires pour les synchroniser.
---
- hosts: localhost
gather_facts: false
tasks:
- name: Update incident
servicenow.itsm.incident:
number: INC0010022
state: in_progress
Si vous exécutez Ansible avec le --diff switch, il signalera les modifications qu'il a apportées à l'enregistrement de l'incident :
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",
Vous pouvez également supprimer un incident existant en définissant l'état paramètre à absent .
---
- hosts: localhost
gather_facts: false
tasks:
- name: Delete incident
servicenow.itsm.incident:
number: INC0010022
state: absent Vous pouvez interagir avec les problèmes et les demandes de modification de la même manière. Cependant, la gestion des éléments de configuration est un peu différente, alors concentrons-nous ensuite sur ce domaine.
Mettre à jour la CMDB
Étant donné que la CMDB ServiceNow comporte plusieurs types d'éléments de configuration, vous devez spécifier le sys_class_name paramètre lors de l'ajout de nouveaux éléments. Par défaut, le servicenow.itsm.configuration_item module utilisera le cmdb_ci nom de classe système, mais vous pouvez le remplacer par n'importe quel autre nom cmdb_ci-derived classe.
---
- 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 }}" Vous avez utilisé le générique autre paramètre pouvant contenir des paires clé-valeur arbitraires dans la dernière tâche. Comme les tables ServiceNow sont extensibles, tous les modules ont ce paramètre. Vous pouvez utiliser l'autre paramètre pour définir les valeurs de colonne que les modules n'exposent pas en tant que paramètres de niveau supérieur. Tous les modules ServiceNow Ansible ont ce paramètre.
Lors de la mise à jour ou de la suppression d'un élément existant, vous n'avez pas à spécifier le nom de la classe système car le module récupère automatiquement le nom de l'enregistrement en cours. Cependant, vous devez fournir un sys_id valeur du paramètre.
---
- 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 Inventaire dynamique
La CMDB peut également servir de source d'inventaire. Étant donné que les éléments de configuration qui représentent des serveurs et des machines virtuelles (VM) contiennent généralement des adresses IP, vous pouvez les utiliser comme source d'inventaire.
La configuration minimale du plug-in d'inventaire ressemble à ceci :
---
plugin: servicenow.itsm.now Lorsqu'il est utilisé comme source d'inventaire, le plug-in répertorie tous les serveurs de cmdb_ci_server table. Vous pouvez automatiquement regrouper et filtrer les hôtes d'inventaire en fonction des conditions spécifiées dans le group_by options de configuration :
---
plugin: servicenow.itsm.now
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Dans l'exemple précédent, Ansible a créé deux groupes :un pour Windows XP et un pour les ordinateurs Linux. Le plugin d'inventaire effectue autant de filtrage que possible sur le backend, minimisant la quantité de données téléchargées.
Vous pouvez également configurer les valeurs de colonne que le plug-in d'inventaire ajoute en tant que variables hôtes :
---
plugin: servicenow.itsm.now
columns:
- name
- classification
- cpu_type
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Pour tester la configuration, exécutez la commande suivante :
$ ansible-inventory -i inventory.now.yaml --graph --vars
En supposant que vous ayez stocké la configuration de l'inventaire dans inventory.now.yaml dossier. Le résultat devrait ressembler à ceci :
@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: Et maintenant que vous savez comment utiliser les modules individuels et le plug-in d'inventaire, il est temps de passer à la grande finale.
Résolution automatique d'une demande de modification standard
Les demandes de modification standard sont des procédures pré-approuvées avec des risques minimes, et ces propriétés en font des candidats de choix pour l'automatisation.
Alors sans plus tarder, voici le playbook qui va :
- Rechercher la demande de modification par son numéro
- Marquer la demande de modification comme étant en cours de traitement
- Récupérer l'élément de configuration concerné à partir de la demande de modification
- Effectuer les opérations demandées sur ledit élément de configuration, et enfin
- Fermer la demande de modification
---
- 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 aurait pu penser que l'on pouvait mettre autant de choses géniales dans un seul livre de jeu ?
[ Vous souhaitez en savoir plus sur l'automatisation du système ? Démarrez avec The Automated Enterprise, un livre gratuit de Red Hat. ]
Le futur est automatique
J'ai couvert pas mal de choses mais je n'ai réussi qu'à effleurer la surface de ce qui est possible. Alors dirigez-vous vers le hub d'automatisation ou Ansible Galaxy, téléchargez la collection ServiceNow ITSM Ansible et commencez à explorer. Vous pouvez également voir cette nouvelle solution en action dans ce webinaire.
Si vous avez besoin d'aide pour l'automatisation et l'intégration de vos processus ServiceNow avec la plate-forme d'automatisation Red Hat Ansible, contactez notre équipe chez XLAB Steampunk qui peut vous aider à être opérationnel en un rien de temps.