Gli ambienti IT stanno diventando sempre più complessi. In queste condizioni, è fondamentale per un sistema di automazione IT avere informazioni aggiornate sui nodi che sono presenti nella rete e che devono essere elaborati. In Red Hat Ansible Automation Platform, questo problema è affrontato attraverso i cosiddetti inventari () – elenchi di nodi gestiti.
Nella sua forma più semplice, un inventario è un file statico. È l'opzione ideale quando inizi a lavorare con Ansible, ma man mano che l'automazione si espande, diventa insufficiente.
Ecco perché:
- Come aggiornare e mantenere un elenco completo dei nodi controllati, quando qualcosa cambia continuamente, quando i carichi di lavoro – e di conseguenza i nodi su cui vengono eseguiti – emergono e scompaiono?
- Come classificare i componenti dell'infrastruttura IT per selezionare con precisione i nodi ai fini dell'automazione?
Le risposte a entrambe queste domande sono fornite da un inventario dinamico () – uno script o un plugin che cerca i nodi da automatizzare, consultando la fonte di verità (source of truth). Inoltre, l'inventario dinamico classifica automaticamente i nodi in gruppi, consentendoti di selezionare meglio i sistemi target per l'esecuzione della specifica automazione di Ansible.
consentono all'utente di Ansible di accedere a piattaforme esterne per la ricerca dinamica dei nodi target e di utilizzare queste piattaforme come fonte di verità nella creazione degli inventari. L'elenco standard delle fonti in Ansible include piattaforme cloud come AWS EC2, Google GCP e Microsoft Azure, ma ci sono anche molti altri plugin di inventario disponibili per Ansible.
Ansible Tower viene fornito con una serie di , che funzionano direttamente "out of the box" e oltre alle piattaforme cloud sopra menzionate offrono integrazione con VMware vCenter, Red Hat OpenStack Platform e Red Hat Satellite. Per questi plugin è sufficiente fornire le credenziali per connettersi alla piattaforma target, dopodiché possono essere utilizzati come fonte di dati di inventario in Ansible Tower.
Oltre ai plugin standard inclusi nella fornitura di Ansible Tower, ci sono anche altri plugin di inventario supportati dalla comunità di Ansible. Con il passaggio a , questi plugin sono diventati parte delle collezioni corrispondenti.
In questo post, analizzeremo come funziona il plugin di inventario per ServiceNow, una popolare piattaforma di gestione dei servizi IT, nella cui CMDB i clienti spesso archiviano informazioni su tutti i loro dispositivi. Inoltre, la CMDB può contenere contesto utile per l'automazione, come ad esempio informazioni sui proprietari dei server, sui livelli di servizio (produzione/non produzione), sugli aggiornamenti installati e sulle finestre di manutenzione. Il plugin di inventario Ansible può lavorare con CMDB ServiceNow ed è incluso nella collezione sul portale .
Git repository
Per utilizzare il plugin di inventario nella Ansible Tower dalla collezione, deve essere specificato come sorgente del progetto. In Ansible Tower, un progetto è un'integrazione con un sistema di gestione delle versioni, come un repository git, che può essere utilizzato per sincronizzare non solo i playbook di automazione, ma anche variabili e liste di inventario.
Il nostro repository è in realtà molto semplice:
├── collections
│ └── requirements.yml
└── servicenow.yml
Il file servicenow.yml contiene i dettagli per il plugin di inventario. Nel nostro caso, specifichiamo semplicemente la tabella nella CMDB di ServiceNow che vogliamo utilizzare. Inoltre, definiamo i campi che saranno aggiunti come variabili del nodo, più determinate informazioni sui gruppi che vogliamo creare.
$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
- key: sn_sys_class_name | lower
prefix: ''
separator: ''
- key: sn_os | lower
prefix: ''
separator: ''
Si noti che qui non viene specificato alcun istanza di ServiceNow a cui ci connetteremo, né vengono forniti dati di accesso per il collegamento. Tutto ciò lo configureremo in seguito nella Ansible Tower.
è necessario affinché Ansible Tower possa scaricare la collezione richiesta e quindi ottenere il plugin di inventario necessario. Altrimenti, sarebbe necessario installare manualmente e mantenere questa collezione su tutti i nostri nodi di Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Dopo aver inviato questa configurazione al sistema di controllo della versione, in Ansible Tower è possibile creare un progetto che fa riferimento al repository corrispondente. Nell'esempio seguente, Ansible Tower si collega al nostro repository su github. Si noti l'URL SCM: consente di specificare un account per collegarsi a un repository privato, oltre a definire un ramo, un tag o un commit specifici da estrarre.
Creiamo le credenziali per ServiceNow
Come già detto, la configurazione nel nostro repository non contiene credenziali per collegarsi a ServiceNow e non specifica l'istanza di ServiceNow con cui comunicheremo. Pertanto, per fornire questi dati, creeremo credenziali in Ansible Tower. Secondo , ci sono diverse variabili d'ambiente che utilizzeremo per impostare i parametri di connessione, ad esempio:
= username
L'account utente ServiceNow, deve avere diritti per leggere cmdb_ci_server (predefinito), o la tabella specificata da SN_TABLE
set_via:
env:
- name: SN_USERNAME
In questo caso, se la variabile d'ambiente SN_USERNAME è impostata, il plugin per l'inventario la utilizzerà come account per collegarsi a ServiceNow.
Dobbiamo anche impostare le variabili SN_INSTANCE e SN_PASSWORD.
Tuttavia, in Ansible Tower non ci sono credenziali di questo tipo, dove poter specificare questi dati per ServiceNow. Tuttavia, Ansible Tower ci consente di definire , ulteriori dettagli possono essere trovati nell'articolo .
Nel nostro caso, la configurazione di input per le credenziali personalizzate per ServiceNow appare come segue:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Queste credenziali saranno esposte come variabili d'ambiente con lo stesso nome. Questo è descritto nella configurazione dell'injector:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Quindi, abbiamo definito il tipo di credential necessario, ora possiamo aggiungere l'account ServiceNow e impostare l'istanza, il nome utente e la password, in questo modo:
Creiamo un inventario
Quindi, ora siamo pronti a creare un inventario in Ansible Tower. Lo chiameremo ServiceNow:
Dopo aver creato l'inventario, possiamo allegare a esso una fonte di dati. Qui indichiamo il progetto che abbiamo creato in precedenza e inseriamo il percorso del nostro file inventario YAML nel repository del sistema di gestione delle versioni, nel nostro caso è servicenow.yml nella radice del progetto. Inoltre, è necessario collegare anche l'account di ServiceNow.
Per verificare come funziona il tutto, proviamo a sincronizzarci con la fonte di dati premendo il pulsante «Sync all». Se tutto è configurato correttamente, i nodi devono essere importati nel nostro inventario:
Nota che anche i gruppi necessari sono stati creati.
Conclusione
In questo post abbiamo esaminato come utilizzare i plugin di inventario di Ansible Tower dalle collezioni, prendendo come esempio il plugin di ServiceNow. Abbiamo anche inserito in modo sicuro le credenziali per connetterci al nostro istanza di ServiceNow. Il collegamento di un plugin di inventario dal progetto funziona non solo con plugin di terze parti o personalizzabili, ma può anche essere utilizzato per modificare il funzionamento di alcuni plugin di inventario standard. Questo consente alla Ansible Automation Platform di integrarsi facilmente e senza soluzione di continuità con gli strumenti esistenti nella automazione degli ambienti IT, che stanno diventando sempre più complessi.
Puoi trovare ulteriori informazioni sugli argomenti trattati in questo post, così come su altri aspetti dell'applicazione di Ansible qui:
- Blog su .
- .
- Elenco delle collezioni supportate da Red Hat sul sito Automation Hub ().
- .
*Red Hat non offre alcuna garanzia sulla correttezza del codice fornito qui. Tutti i materiali sono forniti senza supporto, a meno che non sia esplicitamente dichiarato il contrario.
Fonte: habr.com
