Mediile IT devin din ce în ce mai complexe. În aceste condiții, pentru un sistem de automatizare IT este critic să avem informații actualizate despre nodurile care sunt prezente în rețea și care necesită procesare. În Red Hat Ansible Automation Platform, această problemă este abordată prin așa-numitele inventory () – liste cu noduri gestionate.
În forma sa cea mai simplă, inventory-ul este un fișier static. Acesta este un variantă ideală atunci când începeți să lucrați cu Ansible, dar pe măsură ce automatizarea se extinde, aceasta devine insuficientă.
Iată de ce:
- Cum să actualizăm și să menținem o listă completă de noduri controlate în stare actuală, atunci când ceva se schimbă constant, când sarcinile de muncă – și, odată cu ele, nodurile pe care sunt executate – apar și dispar?
- Cum să clasificăm componentele infrastructurii IT pentru a selecta cu precizie nodurile pentru aplicarea unei automatizări specifice?
Răspunsurile la ambele întrebări sunt oferite de un dynamic inventory () – un script sau un plugin care caută nodurile supuse automatizării, apelând la sursa de adevăr (source of truth). În plus, dynamic inventory clasifică automat nodurile în grupuri, astfel încât să puteți selecta mai precis sistemele țintă pentru a efectua o anumită automatizare Ansible.
oferă utilizatorului Ansible posibilitatea de a accesa platforme externe pentru căutarea dinamică a nodurilor țintă și de a utiliza aceste platforme ca sursă de adevăr în formarea inventory-ului. Lista standard a surselor în Ansible include platformele cloud AWS EC2, Google GCP și Microsoft Azure, de asemenea, pentru Ansible există și multe alte pluginuri de inventory.
Ansible Tower vine împreună cu o serie de , care funcționează direct „din cutie” și, pe lângă platformele cloud enumerate mai sus, asigură integrarea cu VMware vCenter, Red Hat OpenStack Platform și Red Hat Satellite. Pentru aceste pluginuri, este suficient să furnizați acreditivele pentru a vă conecta la platforma țintă, după care acestea pot fi utilizate ca sursă de date de inventory în Ansible Tower.
Pe lângă pluginurile standard incluse în Ansible Tower, există și alte pluginuri de inventory, susținute de comunitatea Ansible. Odată cu trecerea la , aceste pluginuri au început să fie incluse în colecțiile corespunzătoare.
În această postare, vom analiza, ca exemplu, utilizarea pluginului de inventar pentru ServiceNow, o platformă populară de gestionare a serviciilor IT, în care clienții adesea stochează informații despre toate dispozitivele lor în CMDB. În plus, CMDB poate conține contexte utile pentru automatizare, cum ar fi informații despre proprietarii serverelor, nivelurile de servicii (production/non-production), actualizările instalate și feroneriile de întreținere. Pluginul de inventar Ansible poate lucra cu CMDB-ul ServiceNow și face parte din colecția pe portal .
repozitoriul Git
Pentru a utiliza pluginul de inventar din colecție în Ansible Tower, trebuie să-l specificați ca sursă a proiectului. În Ansible Tower, un proiect este o integrare cu un sistem de gestionare a versiunilor, cum ar fi un repository git, care poate fi folosit pentru a sincroniza nu doar playbook-urile de automatizare, ci și variabilele și listele de inventar.
Repository-ul nostru este de fapt foarte simplu:
├── collections
│ └── requirements.yml
└── servicenow.yml
Fișierul servicenow.yml conține detalii pentru pluginul de inventar. În cazul nostru, specificăm pur și simplu tabelul din CMDB ServiceNow pe care dorim să-l utilizăm. De asemenea, stabilim câmpurile care vor fi adăugate ca variabile de nod, plus informații specifice despre grupurile pe care dorim să le creăm.
$ 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: ''
Rețineți că aici nu se specifică deloc instanța ServiceNow la care ne vom conecta și nu se stabilește nicio acreditivă pentru conectare. Toate acestea vor fi configurate ulterior în Ansible Tower.
este necesar pentru ca Ansible Tower să poată descărca colecția necesară și astfel să obțină pluginul de inventar dorit. Altfel, ar trebui să instalăm și să întreținem manual această colecție pe toate nodurile noastre Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
După ce am trimis această configurație în sistemul de control al versiunilor, în Ansible Tower putem crea un proiect referitor la repository-ul corespunzător. În exemplul de mai jos, Ansible Tower se leagă de repository-ul nostru de pe github. Observați SCM URL: acesta permite specificarea contului pentru conectarea la un repository privat, dar și stabilirea unei ramuri, etichete sau comit pentru extragere.
Creăm credentials pentru ServiceNow
Așa cum s-a menționat, configurația din repository-ul nostru nu conține credentiale pentru conectarea la ServiceNow și nu specifică instanța ServiceNow cu care vom interacționa. Prin urmare, pentru a stabili aceste date, vom crea credentiale în Ansible Tower. Conform , există o serie de variabile de mediu, cu ajutorul cărora vom stabili parametrii de conectare, de exemplu:
= username
Contul utilizatorului ServiceNow, ar trebui să aibă drepturi de citire cmdb_ci_server (implicit), sau tabelul specificat de SN_TABLE
set_via:
env:
- name: SN_USERNAME
În acest caz, dacă variabila de mediu SN_USERNAME este setată, plugin-ul de inventar va folosi aceasta ca și cont pentru conectarea la ServiceNow.
De asemenea, trebuie să stabilim variabilele SN_INSTANCE și SN_PASSWORD.
Cu toate acestea, în Ansible Tower nu există credentiale de acest tip, unde am putea specifica aceste date pentru ServiceNow. Totuși, Ansible Tower ne permite să definim , mai multe detalii pot fi găsite în articolul .
În cazul nostru, configurația de input pentru credentialele personalizate pentru ServiceNow arată astfel:
fields:
- id: SN_USERNAME
type: string
label: Nume utilizator
- id: SN_PASSWORD
type: string
label: Parolă
secret: true
- id: SN_INSTANCE
type: string
label: Instanță Snow
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Aceste credentiale vor fi expuse ca variabile de mediu cu același nume. Acest lucru este descris în configurația injectorului:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Deci, am definit tipul de credential necesar, acum putem adăuga contul ServiceNow și stabili instanța, numele utilizatorului și parola, astfel:
Creăm un inventar
Deci, acum avem totul pregătit pentru a crea un inventar în Ansible Tower. Să-l numim ServiceNow:
După crearea inventarului, putem atașa o sursă de date la acesta. Aici specificăm proiectul pe care l-am creat anterior și introducem calea către fișierul nostru de inventar YAML în repositoarele sistemului de gestionare a versiunilor, în cazul nostru servicenow.yml în rădăcina proiectului. De asemenea, trebuie să asociem și un cont ServiceNow.
Pentru a verifica dacă totul funcționează, încercăm să ne sincronizăm cu sursa de date, apăsând butonul „Sync all”. Dacă totul este configurat corect, nodurile ar trebui să fie importate în inventar:
Rețineți că grupurile necesare pentru noi au fost de asemenea create.
Concluzie
În această postare, am discutat despre cum să folosim pluginurile de inventar din colecții în Ansible Tower, exemplificând cu pluginul ServiceNow. De asemenea, am scris în siguranță acreditivele pentru a ne conecta la instanța noastră ServiceNow. Asocierea pluginului de inventar din proiect funcționează nu doar cu pluginuri terțe sau personalizate, ci poate fi aplicată și pentru a modifica funcționarea unor pluginuri de inventar standard. Din acest motiv, Ansible Automation Platform se integrează ușor și fără probleme cu instrumentele existente în automatizarea mediilor IT, care devin din ce în ce mai complexe.
Pentru a găsi informații suplimentare despre temele discutate în această postare, precum și despre alte aspecte referitoare la utilizarea Ansible, puteți consulta aici:
- Blog despre .
- .
- Lista colecțiilor suportate de Red Hat pe site-ul Automation Hub ().
- .
*Red Hat nu oferă nicio garanție privind corectitudinea codului prezentat aici. Toate materialele sunt furnizate fără suport, cu excepția cazului în care este specificat altceva explicit.
Sursa: habr.com
