Ansible Toweri Ansible Content Collections'i varude pistikprogrammide kasutamine

IT-keskkonnad muutuvad järjest keerukamaks. Nendes tingimustes on IT automatiseerimissüsteemi jaoks ülioluline värske teabe olemasolu võrgus olevate ja töödeldavate sõlmede kohta. Red Hat Ansible Automation Platformis lahendatakse see probleem läbi nn inventuuri (inventar) – hallatavate sõlmede loendid.

Lihtsamal kujul on inventar staatiline fail. See on ideaalne, kui hakkate Ansiblega töötama, kuid automatiseerimise kasvades muutub see ebapiisavaks.

Ja siin on miks:

1. Kuidas värskendada ja säilitada jälgitavate sõlmede täielikku loendit, kui asjad muutuvad pidevalt, kui töökoormused ja seejärel ka sõlmed, millel need töötavad, tulevad ja lähevad?
2. Kuidas klassifitseerida IT-infrastruktuuri komponente, et valida konkreetse automatiseerimise rakendamiseks spetsiaalselt sõlmed?

Dünaamiline inventuur annab vastused mõlemale küsimusele (dünaamiline inventuur) – skript või plugin, mis otsib sõlmpunkte, mida automatiseerida, viidates tõe allikale. Lisaks liigitab dünaamiline inventuur sõlmed automaatselt rühmadesse, et saaksite konkreetse Ansible automatiseerimise teostamiseks sihtsüsteeme täpsemalt valida.

Varude pistikprogrammid anda Ansible'i kasutajale võimalus pääseda juurde välistele platvormidele, et dünaamiliselt sihtsõlmi otsida ja kasutada neid platvorme inventuuri loomisel tõeallikana. Ansible'i standardne allikate loend sisaldab pilveplatvorme AWS EC2, Google GCP ja Microsoft Azure, samuti on Ansible jaoks palju muid varude pistikprogramme.

Ansible Toweriga on kaasas mitmeid varude pistikprogrammid, mis töötavad kohe karbist välja võttes ja pakuvad lisaks ülaltoodud pilveplatvormidele integratsiooni VMware vCenteri, Red Hat OpenStack Platformi ja Red Hat Satellite'iga. Nende pistikprogrammide jaoks peate lihtsalt esitama sihtplatvormiga ühenduse loomiseks mandaadid, misjärel saab neid kasutada Ansible Toweri laoandmete allikana.

Lisaks Ansible Toweriga kaasasolevatele standardsetele pistikprogrammidele on Ansible'i kogukonna toetatud ka teisi varude pistikprogramme. Üleminekuga Red Hat Ansible sisukogud neid pluginaid hakati kaasama vastavatesse kogudesse.

Selles postituses toome näite, kuidas töötada koos populaarse IT-teenuste haldusplatvormi ServiceNow varude pistikprogrammiga, kus kliendid salvestavad sageli teavet kõigi oma seadmete kohta CMDB-s. Lisaks võib CMDB sisaldada automatiseerimiseks kasulikku konteksti, näiteks teavet serverite omanike, teenusetasemete (tootmine/mittetootmine), installitud värskenduste ja hooldusakende kohta. Ansible inventari pistikprogramm võib töötada koos ServiceNow CMDB-ga ja on osa kogust teenindaja portaalis galaxy.ansible.com.

Giti hoidla

Ansible Toweri kogust pärineva varude pistikprogrammi kasutamiseks tuleb see määrata projekti allikaks. Ansible Toweris on projekt integratsioon mingi versioonihaldussüsteemiga, näiteks git-hoidlaga, mida saab kasutada mitte ainult automatiseerimise käsiraamatute, vaid ka muutujate ja varude loendite sünkroonimiseks.

Meie hoidla on tegelikult väga lihtne:

├── collections
│   └── requirements.yml
└── servicenow.yml

Fail servicenow.yml sisaldab pistikprogrammide loendi üksikasju. Meie puhul määrame lihtsalt ServiceNow CMDB-s tabeli, mida tahame kasutada. Seadistame ka väljad, mis lisatakse sõlme muutujatena, pluss teatud teabe rühmade kohta, mida tahame luua.

$ 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: ''

Pange tähele, et see ei määra mingil viisil ServiceNow eksemplari, millega me ühenduse loome, ega määra ühenduse loomiseks mandaate. Seda kõike konfigureerime hiljem Ansible Toweris.

Failikogud/requirements.yml vajalik selleks, et Ansible Tower saaks vajaliku kollektsiooni alla laadida ja seeläbi vajaliku varude pistikprogrammi hankida. Vastasel juhul peaksime selle kollektsiooni kõigisse Ansible Toweri sõlmedesse käsitsi installima ja hooldama.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

Kui oleme selle konfiguratsiooni versioonihaldusse viinud, saame Ansible Toweris luua projekti, mis viitab vastavale hoidlale. Allolev näide seob Ansible Toweri meie githubi hoidlaga. Pöörake tähelepanu SCM-i URL-ile: see võimaldab teil registreerida konto privaatse hoidlaga ühenduse loomiseks, samuti määrata konkreetne haru, silt või väljamaksekohustus.

Mandaatide loomine teenuse ServiceNow jaoks

Nagu mainitud, ei sisalda meie hoidla konfiguratsioon teenusega ServiceNow ühenduse loomiseks mandaate ega määra ServiceNow eksemplari, millega me suhtleme. Seetõttu loome nende andmete määramiseks Ansible Toweris mandaadid. Vastavalt ServiceNow varude pistikprogrammi dokumentatsioon, on mitmeid keskkonnamuutujaid, millega määrame ühenduse parameetrid, näiteks järgmiselt:

= username
    	The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

Sel juhul, kui keskkonnamuutuja SN_USERNAME on määratud, kasutab varude pistikprogramm seda teenusega ServiceNow ühenduse loomiseks kontona.

Peame määrama ka muutujad SN_INSTANCE ja SN_PASSWORD.

Ansible Toweris pole aga seda tüüpi mandaate, kus saaksite ServiceNow jaoks need andmed määrata. Kuid Ansible Tower võimaldab meil määratleda kohandatud mandaatide tüübid, saate selle kohta rohkem lugeda artiklist "Ansible Tower Feature Spotlight: kohandatud volikirjad".

Meie puhul näeb ServiceNow kohandatud mandaatide sisendkonfiguratsioon välja järgmine:

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

Need mandaadid avaldatakse sama nimega keskkonnamuutujatena. Seda on kirjeldatud pihusti konfiguratsioonis:

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

Niisiis, oleme määratlenud vajaliku mandaadi tüübi, nüüd saame lisada ServiceNow konto ja määrata eksemplari, kasutajanime ja parooli järgmiselt:

Loome inventuuri

Nüüd oleme kõik valmis Ansible Toweris inventuuri looma. Nimetagem seda ServiceNow'ks:

Pärast inventuuri loomist saame sellele lisada andmeallika. Siin täpsustame varem loodud projekti ja sisestame oma YAML-i laofaili tee allika juhthoidlasse, meie puhul on see projekti juures servicenow.yml. Lisaks peate linkima oma ServiceNow konto.

Et kontrollida, kuidas kõik toimib, proovime sünkroonida andmeallikaga, klõpsates nuppu „Sünkrooni kõik”. Kui kõik on õigesti konfigureeritud, tuleks sõlmed importida meie loendisse:

Pange tähele, et loodud on ka meile vajalikud rühmad.

Järeldus

Selles postituses vaatlesime, kuidas kasutada Ansible Toweri kogude varude pistikprogramme, kasutades näitena ServiceNow pistikprogrammi. Samuti registreerisime meie ServiceNow eksemplariga ühenduse loomiseks turvaliselt mandaadid. Varude pistikprogrammi linkimine projektist ei tööta mitte ainult kolmanda osapoole või kohandatud pistikprogrammidega, vaid seda saab kasutada ka mõne standardse varude toimimise muutmiseks. See muudab Ansible Automation Platformi hõlpsaks ja sujuvaks integreerimise olemasolevate tööriistadega üha keerukamaks muutuvate IT-keskkondade automatiseerimisel.

Lisateavet selles postituses käsitletud teemade ja muude Ansible kasutamise aspektide kohta leiate siit:

• Blogi autor ServiceNow'i automatiseerimine Ansible'i abil.
• Kuidas luua oma kollektsioone.
• Red Hati toetatud kollektsioonide loend Automation Hubi veebisaidil (cloud.redhat.com).
• Ansible Automation Platformi e-raamatud.

*Red Hat ei garanteeri, et siin sisalduv kood on õige. Kõik materjalid esitatakse kinnituseta, kui pole selgesõnaliselt märgitud teisiti.

Allikas: www.habr.com