Agli amministratori di sistema viene chiesto regolarmente di completare rapidamente le richieste di servizio per soddisfare meglio le esigenze aziendali e degli utenti, con sempre più amministratori che si affidano ad Ansible per farlo. Come possiamo, come amministratori di sistema, rispondere più velocemente quando arrivano queste richieste?
La gestione dei servizi IT (ITSM) è una raccolta di politiche e processi per la gestione e il supporto dei servizi IT. L'obiettivo principale di ITSM è aumentare il valore della catena di servizi dei clienti. Ma senza l'opportuno supporto per l'automazione, la fornitura di servizi IT può diventare rapidamente un importante dispendio di tempo per gli amministratori.
[ Potrebbe piacerti anche: Guida introduttiva ad Ansible per gli amministratori di sistema Linux ]
È qui che entrano in gioco la Red Hat Ansible Automation Platform e la Red Hat Ansible Certified Content Collection per ServiceNow. Ansible Automation (con l'aiuto dei contenuti Ansible esistenti) può automatizzare qualsiasi attività, mentre i moduli di questa raccolta certificata consentono di mantenere aggiornate le informazioni di ServiceNow.
Questa collezione è stata progettata e sviluppata dal team di XLAB Steampunk in stretta collaborazione con Red Hat Ansible, tenendo a mente in particolare gli utenti finali. I moduli ServiceNow hanno un'interfaccia utente intuitiva supportata da una solida implementazione, che offre supporto per le cose che gli utenti Ansible si aspettano (ad esempio, modalità di verifica e rilevamento delle modifiche).
In questo post, mostro alcuni esempi di Ansible Playbook che si occupano di attività amministrative essenziali come:
- Aggiornamento di incidenti, problemi e richieste di modifica
- Aggiornamento del database di gestione della configurazione di ServiceNow (CMDB)
- Utilizzo del CMDB come fonte di inventario
Installazione della raccolta di contenuti certificati per ServiceNow
Puoi scaricare servicenow.itsm Raccolta da hub di automazione o Ansible Galaxy. Prima di poter accedere ai contenuti nell'hub di automazione, devi prima configurare le credenziali nel file di configurazione di Ansible. Per i dettagli, fare riferimento al post del blog "Hands On With Ansible Collections".
Una volta che hai le tue credenziali, puoi installare ServiceNow Collection eseguendo il comando seguente:
$ ansible-galaxy collection install servicenow.itsm Se tutto va secondo i piani, ora hai accesso ai seguenti moduli:
- servicenow.itsm.incident per la gestione dei ticket di incidente
- servicenow.itsm.problem per interagire con i problemi
- servicenow.itsm.change_request per la gestione delle modifiche
- servicenow.itsm.configuration_item per la gestione del CMDB
Ciascuno dei moduli ha anche una controparte che ti dà accesso in sola lettura ai record di ServiceNow.
La raccolta di contenuti certificati per ServiceNow contiene anche un plug-in di inventario chiamato servicenow.itsm.now che ti consente di utilizzare CMDB come origine dell'inventario.
Per verificare che nulla sia andato storto, mostra la documentazione per uno dei moduli eseguendo il comando seguente:
$ ansible-doc servicenow.itsm.incident Se Ansible non ci ha sgridato, sei a posto.
Gestire gli incidenti, il modo Ansible
La creazione di un nuovo ticket di incidente utilizzando Ansible è ragionevolmente semplice, ma prima di poterlo fare, devi indicare ad Ansible dove si trova la tua istanza ServiceNow e quali credenziali utilizzare. Fallo impostando tre variabili di ambiente:
$ export SN_HOST='https://dev12345.service-now.com'
$ export SN_USERNAME='user'
$ export SN_PASSWORD='pass' Ora che hai le credenziali pronte, puoi creare un nuovo incidente. Il playbook minimo di Ansible sarebbe simile a questo:
---
- hosts: localhost
gather_facts: false
tasks:
- name: Create new incident
servicenow.itsm.incident:
state: new
short_description: Demo incident Al termine dell'esecuzione del playbook precedente, troverai un nuovo incidente elencato in ServiceNow.
È possibile aggiornare un incidente esistente fornendo un numero di ticket o un ID di sistema del record dell'incidente. Ansible confronterà lo stato attuale e quello desiderato dell'incidente e apporterà le modifiche necessarie per sincronizzarli.
---
- hosts: localhost
gather_facts: false
tasks:
- name: Update incident
servicenow.itsm.incident:
number: INC0010022
state: in_progress
Se esegui Ansible con --diff switch, riporterà le modifiche apportate al record dell'incidente:
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",
Puoi anche eliminare un incidente esistente impostando lo stato parametro su absent .
---
- hosts: localhost
gather_facts: false
tasks:
- name: Delete incident
servicenow.itsm.incident:
number: INC0010022
state: absent È possibile interagire con i problemi e modificare le richieste allo stesso modo. Tuttavia, la gestione degli elementi di configurazione è leggermente diversa, quindi concentriamoci su quest'area in seguito.
Aggiornamento del CMDB
Poiché ServiceNow CMDB ha più di un tipo di elemento di configurazione, devi specificare il sys_class_name parametro quando si aggiungono nuovi elementi. Per impostazione predefinita, il servicenow.itsm.configuration_item il modulo utilizzerà cmdb_ci nome della classe di sistema, ma puoi cambiarlo in qualsiasi altro 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 }}" Hai usato il generico altro parametro che può contenere coppie chiave-valore arbitrarie nell'ultima attività. Poiché le tabelle di ServiceNow sono estensibili, tutti i moduli hanno questo parametro. Puoi usare l'altro parametro per impostare i valori di colonna che i moduli non espongono come parametri di primo livello. Tutti i moduli ServiceNow Ansible hanno questo parametro.
Quando si aggiorna o si elimina un elemento esistente, non è necessario specificare il nome della classe di sistema perché il modulo recupererà automaticamente il nome dal record corrente. Tuttavia, devi fornire un sys_id valore del parametro.
---
- 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 dinamico
Il CMDB può anche fungere da origine dell'inventario. Poiché gli elementi di configurazione che rappresentano server e macchine virtuali (VM) di solito contengono indirizzi IP, puoi utilizzarli come origine dell'inventario.
La configurazione minima per il plug-in dell'inventario è simile alla seguente:
---
plugin: servicenow.itsm.now Se utilizzato come origine dell'inventario, il plug-in elencherà tutti i server dal cmdb_ci_server tavolo. Puoi raggruppare e filtrare automaticamente gli host dell'inventario in base alle condizioni specificate in group_by opzione di configurazione:
---
plugin: servicenow.itsm.now
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Nell'esempio precedente, Ansible ha creato due gruppi:uno per Windows XP e uno per computer Linux. Il plug-in dell'inventario esegue il maggior numero possibile di filtri sul back-end, riducendo al minimo la quantità di dati scaricati.
Puoi anche configurare i valori di colonna che il plug-in dell'inventario aggiunge come variabili host:
---
plugin: servicenow.itsm.now
columns:
- name
- classification
- cpu_type
group_by:
os:
includes:
- Linux Red Hat
- Windows XP Per testare la configurazione, esegui il seguente comando:
$ ansible-inventory -i inventory.now.yaml --graph --vars
Supponendo che tu abbia memorizzato la configurazione dell'inventario in inventory.now.yaml file. L'output dovrebbe essere simile a questo:
@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: E ora che sai come utilizzare i singoli moduli e il plug-in dell'inventario, è il momento del gran finale.
Risoluzione automatica di una richiesta di modifica standard
Le richieste di modifica standard sono procedure pre-approvate con rischi minimi e queste proprietà le rendono i candidati ideali per l'automazione.
Quindi, senza ulteriori indugi, ecco il playbook che:
- Cerca la richiesta di modifica in base al suo numero
- Segna la richiesta di modifica come in lavorazione
- Recupera l'elemento di configurazione interessato dalla richiesta di modifica
- Esegui le operazioni richieste su tale elemento di configurazione e, infine
- Chiudi la richiesta di modifica
---
- 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 Chi avrebbe mai potuto pensare che si possano racchiudere così tante meraviglie in un unico playbook?
[ Cerchi ulteriori informazioni sull'automazione dei sistemi? Inizia con The Automated Enterprise, un libro gratuito di Red Hat. ]
Il futuro è automatico
Ho coperto parecchio, ma sono comunque riuscito a scalfire solo la superficie di ciò che è possibile. Quindi vai all'hub di automazione o Ansible Galaxy, scarica ServiceNow ITSM Ansible Collection e inizia a esplorare. Puoi anche vedere questa nuova soluzione in azione in questo webinar.
Se hai bisogno di aiuto con l'automazione dei processi ServiceNow e l'integrazione con Red Hat Ansible Automation Platform, contatta il nostro team di XLAB Steampunk che può aiutarti a iniziare a lavorare in pochissimo tempo.