Ansible'i sisu kogumite inventuuri pluginite kasutamine Ansible Toweris

IT-ökosüsteemid muutuvad järjest keerulisemaks. Nendes tingimustes on IT-automaatikas kriitilise tähtsusega omada ajakohast teavet võrgulementide kohta, mis vajavad töötlemist. Red Hat Ansible Automation Platformis lahendatakse see probleem niiöelda inventeerimise kaudu (inventory) – hallatavate elementide nimekirjad.

Oma kõige lihtsamas vormis on inventeerimine staatiline fail. See on ideaalne variant, kui hakkate Ansible'i kasutama, kuid automatiseerimise laienedes muutub see ebapiisavaks.

Ja põhjused on järgmised:

1. Kuidas värskendada ja hoida ajakohasena täielikku hallatavate elementide nimekirja, kui kõik pidevalt muutub, kui töökoormused – ja nendega koos nende täitmiseks vajalikud elemendid – tekivad ja kaovad?
2. Kuidas klassifitseerida IT-infrastruktuuri komponente, et valida sihitud elemente teatud automatiseerimise rakendamiseks?

Mõlema küsimuse vastused annab dünaamiline inventeerimine (dynamic inventory) – skript või plugin, mis otsib automaatimisse kuuluvad elemendid, pöördudes tõeallika poole (source of truth). Lisaks klassifitseerib dünaamiline inventeerimine automaatselt elemente gruppidesse, et saaksite täpsemalt valida sihtsüsteeme Ansible’i teatud automatiseerimise teostamiseks.

Inventeerimise pluginad annavad Ansible'i kasutajale võimaluse pöörduda väliste platvormide poole dünaamilise sihtelementide otsimiseks ja kasutada neid platvorme tõeallikana inventeerimise koostamisel. Ansible'i standardne allikate nimekiri sisaldab pilveplatvorme nagu AWS EC2, Google GCP ja Microsoft Azure, ning Ansible'i jaoks on ka mitmeid muid inventeerimise pluginaid.

Ansible Tower tarnitakse koos mitmete inventeerimise pluginatega, mis töötavad otse „kasti seest“ ja lisaks eespool nimetatud pilveplatvormidele tagavad need integratsiooni VMware vCenteri, Red Hat OpenStack Platformi ja Red Hat Satellite'iga. Nende pluginatega piisab, kui esitada sihtplatvormile ühenduse loomiseks vajalikud mandaadid, seejärel saab neid kasutada inventeerimisandmete allikana Ansible Toweris.

Lisaks tavapärastele pluginatele, mis on varustatud Ansible Toweriga, on ka teisi inventeerimise pluginaid, mida toetavad Ansible'i kogukonna jõud. Üleminekuga Red Hat Ansible Content Collections on need pluginad hakanud kuuluma vastavatesse kogudesse.

Selles postituses vaatleme inventory-plugin'i tööd ServiceNow's, populaarses IT-teenuste haldamise platvormis, mille CMDB-s hoiavad kliendid sageli teavet oma seadmete kohta. Lisaks sellele võib CMDB sisaldada automatiseerimise konteksti jaoks kasulikku teavet, näiteks serverite omanike, teenindusastmete (production/non-production), installitud uuenduste ja hooldusakenete andmeid. Ansible'i inventori-plugin suudab töötada ServiceNow CMDB-ga ja kuulub kollektsiooni koostisse. servicenow portaalis galaxy.ansible.com.

Git-repositoorium

Et kasutada Ansible Toweris kollektsiooni inventori-plugin'i, tuleb see määrata projektiallikana. Ansible Toweris on projekt integreerimine mõne versioonihaldussüsteemiga, nagu git-repositoorium, mida saab kasutada mitte ainult automatiseerimisplaane, vaid ka muutujaid ja inventari nimekirju sünkroonimiseks.

Meie repositoorium on tegelikult väga lihtne:

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

Fail servicenow.yml sisaldab üksikasju inventori-plugin'i jaoks. Meie juhul määrame lihtsalt tabeli CMDB ServiceNow's, mida soovime kasutada. Samuti määrame väljad, mis lisatakse sõlme muutujatena, pluss teatud teave rühmade kohta, mida soovime 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 siin ei täpsustata kuidagi, millise ServiceNow instantsiga me ühendame, ega määrata ka mingeid autentimisandeid. Kõik need seaded teeme hiljem Ansible Toweris.

Fail collections/requirements.yml on vajalik, et Ansible Tower saaks alla laadida vajaliku kollektsiooni ja seega vajalikud inventori-plugin'id. Vastasel korral tuleks see kollektsioon manuaalselt installida ja hallata kõigil meie Ansible Tower sõlmedel.

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

- name: servicenow.servicenow

Pärast seda, kui oleme selle konfiguratsiooni versioonihaldusesse saatnud, saab Ansible Toweris luua projekti, mis viitab vastavale repole. Allpool toodud näites seondub Ansible Tower meie GitHubi repoga. Pange tähele SCM URL-i: see võimaldab määrata konto, et ühendada privaatset reposid, ning määrata konkreetne haru, sildi või kommi ekstraktsiooni jaoks.

Loome credentials ServiceNow jaoks

Nagu juba mainitud, ei sisalda meie repolis konfiguratsioon ühenduse loomiseks ServiceNow jaoks ja ei täpsusta ServiceNow instantsi, millega me suhtleme. Seetõttu loome nende andmete määramiseks Ansible Toweris credentials. Vastavalt ServiceNow inventeerimise plugina dokumentatsioonile, on olemas rida keskkonnamuutujaid, millega määrame ühenduse parameetrid, näiteks nii:

= username
    	ServiceNow kasutajakonto, mis peaks omama õigusi cmdb_ci_serveri (vaikimisi) lugemiseks või tabeli, mille SN_TABLE määrab, lugemiseks

    	set_via:
      	env:
      	- name: SN_USERNAME

Sel juhul, kui keskkonnamuutuja SN_USERNAME on määratud, kasutab inventeerimise plugina kasutamine seda ServiceNowi ühenduse loomiseks.

Peame ka määrama muutujad SN_INSTANCE ja SN_PASSWORD.

Siiski ei ole Ansible Toweris selliste andmete määramiseks credentials. Kuid Ansible Tower võimaldab meil määratleda kohandatud credentials tüübid, mille kohta saab lisainfot lugeda artiklist „Ansible Tower Feature Spotlight: Custom Credentials“.

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

fields:
  - id: SN_USERNAME
	type: string
	label: Kasutajanimi
  - id: SN_PASSWORD
	type: string
	label: Parool
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Snow Instants
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

Need credentials eksponeeritakse keskkonnamuutujatena sama nimega. See on kirjeldatud injector'i konfiguratsioonis:

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

Nii et oleme määratlenud vajalikud credentiali tüübid, nüüd saab lisada ServiceNow kontot ning määrata instantsi, kasutajanime ja parooli, nii:

Loome inventuuri

Nüüd on meil kõik vajalik, et luua Ansible Toweris inventuuri. Nimeta see ServiceNow:

Pärast inventuuri loomist saame sellele andmeallika külge kinnitada. Siin näitame projekti, mille varem lõime, ja sisestame tee meie inventuuri YAML-failini versioonihaldussüsteemis, meie puhul on see servicenow.yml projekti juures. Samuti tuleb siduda ServiceNow konto.

Kuidas kõik töötab, proovime andmeallikaga sünkroniseerida, vajutades nupule „Sünkroniseeri kõik“. Kui kõik on õigesti seadistatud, imporditakse sõlmed meie inventuuri:

Pange tähele, et vajalikud grupid on samuti loodud.

Kokkuvõte

Selles postituses vaatlesime, kuidas kasutada Ansible Toweris inventuuri pluginaid kogudest, näiteks ServiceNow pluginat. Samuti seadsime ohutult ühenduse andmed meie ServiceNow instantsiga. Projekti inventuuri plugina sidumine töötab mitte ainult kolmandate osapoolte või kohandatavate pluginatega, vaid seda saab kasutada ka mõnede vaikimisi inventuuri töömodifikatsioonidega. Tänu sellele integreerib Ansible Automation Platform hõlpsalt ja sujuvalt olemasolevad tööriistad, automatiseerides IT-keskkondi, mis muutuvad üha keerulisemaks.

Lisainfot postitustes käsitletud teemade kohta ja teiste Ansible rakendamise aspektide kohta leiate siit:

• Blogi ServiceNow automatiseerimise kohta Ansible'iga.
• Kuidas luua oma kogusid.
• Red Hat'i toetatud kogude loetelu Automation Hubis (cloud.redhat.com).
• e-raamat Ansible Automation Platformi kohta.

*Red Hat ei anna mingeid garantiisid siinses koodis esitatud andmete õigsuse kohta. Kõik materjalid on esitatud ilma toeta, välja arvatud juhul, kui on selgesõnaliselt öeldud teisiti.

Allikas: habr.com