Systemadministratoren werden regelmäßig gebeten, Serviceanfragen schnell abzuschließen, um Geschäfts- und Benutzeranforderungen besser zu erfüllen, wobei sich immer mehr Administratoren auf Ansible verlassen. Wie können wir als Systemadministratoren schneller reagieren, wenn diese Anfragen kommen?
IT Service Management (ITSM) ist eine Sammlung von Richtlinien und Prozessen für die Verwaltung und Unterstützung von IT-Services. Das Hauptaugenmerk von ITSM liegt auf der Wertsteigerung der Servicekette der Kunden. Aber ohne die richtige Automatisierungsunterstützung kann die Bereitstellung von IT-Services schnell zu einem großen Zeitfresser für Administratoren werden.
[Das könnte Ihnen auch gefallen: Schnellstartanleitung für Ansible für Linux-Systemadministratoren]
Hier kommen die Red Hat Ansible Automation Platform und die Red Hat Ansible Certified Content Collection für ServiceNow ins Spiel. Ansible Automation (mit etwas Hilfe von vorhandenen Ansible-Inhalten) kann nahezu jede Aufgabe automatisieren, während die Module aus dieser zertifizierten Sammlung es Ihnen ermöglichen, die ServiceNow-Informationen auf dem neuesten Stand zu halten.
Diese Sammlung wurde vom XLAB Steampunk-Team in enger Zusammenarbeit mit Red Hat Ansible entworfen und entwickelt, wobei speziell die Endbenutzer berücksichtigt wurden. ServiceNow-Module verfügen über eine intuitive Benutzeroberfläche, die von einer robusten Implementierung unterstützt wird und Unterstützung für Dinge bietet, die Ansible-Benutzer erwarten (z. B. Prüfmodus und Änderungserkennung).
In diesem Beitrag zeige ich einige Beispiele für Ansible Playbooks, die sich um wichtige Verwaltungsaufgaben kümmern, wie zum Beispiel:
- Aktualisieren von Vorfällen, Problemen und Änderungsanfragen
- Aktualisieren der ServiceNow Configuration Management Database (CMDB)
- Verwendung der CMDB als Inventarquelle
Installieren der zertifizierten Inhaltssammlung für ServiceNow
Sie können servicenow.itsm herunterladen Sammlung von Automation Hub oder Ansible Galaxy. Bevor Sie auf Inhalte im Automation Hub zugreifen können, müssen Sie zuerst Ihre Anmeldedaten in der Ansible-Konfigurationsdatei konfigurieren. Einzelheiten finden Sie im Blogbeitrag „Hands On With Ansible Collections“.
Sobald Sie Ihre Anmeldedaten haben, können Sie die ServiceNow-Sammlung installieren, indem Sie den folgenden Befehl ausführen:
$ ansible-galaxy collection install servicenow.itsm Wenn alles nach Plan läuft, haben Sie jetzt Zugriff auf die folgenden Module:
- servicenow.itsm.vorfall zum Verwalten von Incident-Tickets
- servicenow.itsm.problem für die Interaktion mit Problemen
- servicenow.itsm.change_request für den Umgang mit Änderungen
- servicenow.itsm.configuration_item zur Verwaltung der CMDB
Jedes der Module hat auch ein Gegenstück, das Ihnen schreibgeschützten Zugriff auf ServiceNow-Datensätze gibt.
Die Certified Content Collection für ServiceNow enthält auch ein Inventar-Plugin namens servicenow.itsm.now damit können Sie CMDB als Inventarquelle verwenden.
Um sicherzustellen, dass nichts schief gelaufen ist, zeigen Sie die Dokumentation für eines der Module an, indem Sie den folgenden Befehl ausführen:
$ ansible-doc servicenow.itsm.incident Wenn Ansible uns nicht angeschrien hat, sind Sie fertig.
Vorfälle verwalten auf Ansible-Art
Das Erstellen eines neuen Incident-Tickets mit Ansible ist relativ einfach, aber bevor Sie dies tun können, müssen Sie Ansible mitteilen, wo sich Ihre ServiceNow-Instanz befindet und welche Anmeldeinformationen verwendet werden sollen. Setzen Sie dazu drei Umgebungsvariablen:
$ export SN_HOST='https://dev12345.service-now.com'
$ export SN_USERNAME='user'
$ export SN_PASSWORD='pass' Jetzt, da Sie Ihre Anmeldedaten bereit haben, können Sie einen neuen Vorfall erstellen. Das minimale Ansible-Playbook würde etwa so aussehen:
---
- hosts: localhost
gather_facts: false
tasks:
- name: Create new incident
servicenow.itsm.incident:
state: new
short_description: Demo incident Sobald die Ausführung des vorherigen Playbooks abgeschlossen ist, finden Sie in ServiceNow einen neuen Vorfall aufgelistet.
Sie können einen vorhandenen Vorfall aktualisieren, indem Sie entweder eine Ticketnummer oder eine System-ID des Vorfalldatensatzes angeben. Ansible vergleicht den aktuellen und den gewünschten Status des Vorfalls und nimmt die notwendigen Änderungen vor, um sie zu synchronisieren.
---
- hosts: localhost
gather_facts: false
tasks:
- name: Update incident
servicenow.itsm.incident:
number: INC0010022
state: in_progress
Wenn Sie Ansible mit --diff ausführen wechseln, wird es berichten, welche Änderungen es im Ereignisdatensatz implementiert hat:
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",
Sie können einen bestehenden Vorfall auch löschen, indem Sie den Status festlegen Parameter auf absent .
---
- hosts: localhost
gather_facts: false
tasks:
- name: Delete incident
servicenow.itsm.incident:
number: INC0010022
state: absent Sie können auf die gleiche Weise mit Problemen und Änderungswünschen umgehen. Die Verwaltung von Konfigurationselementen ist jedoch etwas anders, also konzentrieren wir uns als Nächstes auf diesen Bereich.
Aktualisierung der CMDB
Da die ServiceNow-CMDB mehr als einen Konfigurationselementtyp hat, müssen Sie den sys_class_name angeben Parameter beim Hinzufügen neuer Elemente. Standardmäßig ist das servicenow.itsm.configuration_item Modul verwendet die cmdb_ci Systemklassenname, aber Sie können ihn in jeden anderen cmdb_ci-abgeleiteten ändern Klasse.
---
- 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 }}" Sie haben das generische other verwendet Parameter, der beliebige Schlüssel-Wert-Paare in der letzten Aufgabe enthalten kann. Da ServiceNow-Tabellen erweiterbar sind, verfügen alle Module über diesen Parameter. Sie können den anderen verwenden -Parameter zum Festlegen von Spaltenwerten, die Module nicht als Parameter der obersten Ebene verfügbar machen. Alle ServiceNow Ansible-Module haben diesen Parameter.
Beim Aktualisieren oder Löschen eines vorhandenen Elements müssen Sie den Systemklassennamen nicht angeben, da das Modul den Namen automatisch aus dem aktuellen Datensatz abruft. Sie müssen jedoch eine sys_id angeben Parameterwert.
---
- 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 Dynamisches Inventar
Die CMDB kann auch als Inventarquelle dienen. Da Konfigurationselemente, die Server und virtuelle Maschinen (VMs) darstellen, normalerweise IP-Adressen enthalten, können Sie sie als Inventarquelle verwenden.
Die minimale Konfiguration für das Inventory-Plugin sieht so aus:
---
plugin: servicenow.itsm.now Bei Verwendung als Inventarquelle listet das Plugin alle Server von cmdb_ci_server auf Tisch. Sie können Inventarhosts basierend auf den in group_by angegebenen Bedingungen automatisch gruppieren und filtern Konfigurationsoption:
---
plugin: servicenow.itsm.now
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Im vorherigen Beispiel hat Ansible zwei Gruppen erstellt:eine für Windows XP- und eine für Linux-Computer. Das Inventar-Plug-in filtert so viel wie möglich im Backend und minimiert so die Menge der heruntergeladenen Daten.
Sie können auch konfigurieren, welche Spaltenwerte das Inventar-Plugin als Hostvariablen hinzufügt:
---
plugin: servicenow.itsm.now
columns:
- name
- classification
- cpu_type
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Führen Sie zum Testen der Konfiguration den folgenden Befehl aus:
$ ansible-inventory -i inventory.now.yaml --graph --vars
Angenommen, Sie haben die Inventarkonfiguration in inventory.now.yaml gespeichert Datei. Die Ausgabe sollte in etwa so aussehen:
@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: Und jetzt, da Sie wissen, wie Sie einzelne Module und das Inventar-Plug-in verwenden, ist es Zeit für das große Finale.
Automatische Auflösung einer Standardänderungsanfrage
Standard-Änderungsanforderungen sind vorab genehmigte Verfahren mit minimalen Risiken, und diese Eigenschaften machen sie zu erstklassigen Kandidaten für die Automatisierung.
Also, ohne weitere Umschweife, hier ist das Playbook, das Folgendes tun wird:
- Suchen Sie die Änderungsanforderung anhand ihrer Nummer
- Markieren Sie die Änderungsanforderung als in Bearbeitung
- Rufen Sie das betroffene Konfigurationselement aus der Änderungsanforderung ab
- Führen Sie die angeforderten Operationen für das Konfigurationselement aus und schließlich
- Schließen Sie die Änderungsanfrage
---
- 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 Wer hätte gedacht, dass man so viel Großartiges in ein einziges Playbook packen kann?
[ Suchen Sie nach mehr Informationen zur Systemautomatisierung? Beginnen Sie mit The Automated Enterprise, einem kostenlosen Buch von Red Hat. ]
Die Zukunft ist automatisch
Ich habe ziemlich viel abgedeckt, aber immer noch nur an der Oberfläche dessen gekratzt, was möglich ist. Gehen Sie also zu Automation Hub oder Ansible Galaxy, laden Sie die ServiceNow ITSM Ansible Collection herunter und beginnen Sie mit der Erkundung. Sie können diese neue Lösung auch in diesem Webinar in Aktion sehen.
Wenn Sie Hilfe bei Ihrer ServiceNow-Prozessautomatisierung und Integration mit der Red Hat Ansible Automation Platform benötigen, wenden Sie sich an unser Team bei XLAB Steampunk, das Ihnen helfen kann, in kürzester Zeit einsatzbereit zu sein.