Ansible'i sisu kogude inventeerimispluginad Ansible Toweris

IT-keskkonnad muutuvad üha keerulisemaks. Sellistes tingimustes on IT-automaatika süsteemi jaoks kriitilise tähtsusega omada ajakohast teavet võrku kuuluvate ja töötlemisele alluvate sõlmede kohta. Red Hat Ansible Automation Platformis lahendatakse see probleem nn inventari kaudu (inventory) – haldatud sõlmede nimekirjad.

Oma kõige lihtsamas vormis on inventar staatiline fail. See on ideaalne variant, kui hakkate Ansible'iga tööle, kuid automaatika laienedes osutub see ebapiisavaks.

Ja just sellepärast:

1. Kuidas uuendada ja hoida ajakohasena täielikku kontrollitavate sõlmede nimekirja, kui midagi pidevalt muutub, kui töökoormused – ja nende järgi ka sõlmed, kus need käivad – siis tekivad ja siis kaovad?
2. Kuidas klassifitseerida IT-infrastruktuuri komponente, et sihipäraselt valida sõlmed, kuhu rakendada automaatikat?

Mõlemale küsimusele annab vastuse dünaamiline inventar (dynamic inventory) – skript või plug-in, mis otsib automatiseeritavaid sõlmi, pöördudes tõe allika poole (source of truth). Lisaks sellele klassifitseerib dünaamiline inventuur automaatselt sõlmi gruppidesse, et saaksite täpsemalt valida sihtsüsteeme Ansible automaatika teostamiseks.

Inventuuripluginad annavad Ansible kasutajale võimaluse pöörduda väliste platvormide poole sihitud sõlmede dünaamiliseks otsimiseks ja kasutada neid platvorme tõe allikana inventuuri koostamisel. Standardne allikate nimekiri Ansible'is sisaldab pilveteenuseid AWS EC2, Google GCP ja Microsoft Azure, samuti on olemas palju muid inventuuripluginaid.

Ansible Tower pakutakse koos mitmete inventuuripluginatega, mis töötavad otse «karbist välja» ning lisaks ülaltoodud pilveteenustele pakuvad integratsiooni VMware vCenter'i, Red Hat OpenStack Platform'i ja Red Hat Satellite'iga. Nende pluginade puhul piisab sihtplatvormile ühenduse loomiseks ainult kasutajatunnuste esitamisest, pärast mida saab neid kasutada Ansible Tower'is inventuuride andmete allikana.

Lisaks Ansible Tower'i standardpluginidele on olemas ka teisi inventeerimispliine, mida toetab Ansible'i kogukond. Üleminekul Red Hat Ansible Content Collections hakati neid pluginaid kaasama vastavatesse kogudesse.

Selles postituses analüüsime näiteks ServiceNow inventeerimispliini, mis on populaarne IT-teenuste haldamise platvorm, mille CMDB-s hoitakse sageli teavet kõikide seadmete kohta. Samuti võib CMDB sisaldada automaatika jaoks kasulikku konteksti, näiteks teavet serverite omanike, teenindusastmete (production/non-production), installitud värskenduste ja hooldustakistuste kohta. Ansible'i inventeerimispliin suudab töötada ServiceNow CMDB-ga ja kuulub kogusse servicenow portaalis galaxy.ansible.com.

Git-repositooriumis

Kuna Ansible Tower kasutab kogust inventeerimispliini, tuleb see määrata projekti allikana. Ansible Toweris on projekt integreerimine mingi versioonihaldesüsteemiga, nagu git-reposiit, mida saab kasutada mitte ainult automatiseerimisplekkide, vaid ka muutujate ja inventeerimiskeerete sünkroonimiseks.

Meie hoidla on tegelikult väga lihtne:

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

Fail servicenow.yml sisaldab üksikasju inventari lisandmooduli kohta. Meie puhul määrame lihtsalt CMDB ServiceNow tabeli, mida soovime kasutada. Samuti määratleme 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, millise ServiceNow instance’iga me ühendust loome, ega määrata ühtegi sisselogimisandmeid. Kõik see seadistame hiljem Ansible Toweris.

Fail collections/requirements.yml on vajalik, et Ansible Tower saaks vajaliku kogumi alla laadida ning seega vajaliku inventari lisandmooduli kätte. Vastasel juhul peaksime selle kogumi käsitsi kõikides meie Ansible Tower sõlmedes installima ja hooldama.

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

- name: servicenow.servicenow

Pärast seda, kui oleme selle konfiguratsiooni versioonihaldussüsteemi edastanud, saab Ansible Toweris luua projekti, mis viitab sobivale hoidjale. Allolevas näites seondub Ansible Tower meie hoidjaga GitHubis. Pange tähele SCM URL-i: see võimaldab määrata konto privaathoidjale ligipääsemiseks ning määrata kindlaks konkreetse haru, sildi või kinnituse tõmbamiseks.

Loome ServiceNow jaoks volitused

Nagu juba mainitud, ei sisalda meie hoidjas olev konfiguratsioon ServiceNow'le ühendamiseks vajalikke volitusi ega täpsusta, millise ServiceNow instantsiga me suhtleme. Seetõttu loome need andmed Ansible Toweris. Vastavalt ServiceNow inventariplugina dokumentatsioonile, on olemas rida keskkonnamuutujaid, mille abil määrame ühendusparameetrid, näiteks nii:

= username
    	ServiceNow kasutajakonto, see peaks omama õigusi cmdb_ci_server'i (vaikimisi) lugemiseks või tabeli, mille SN_TABLE määrate

    	set_via:
      	env:
      	- name: SN_USERNAME

Sellisel juhul, kui keskkonnamuutuja SN_USERNAME on määratud, kasutab inventariplugin seda ServiceNow'ga ühenduse loomiseks.

Peame määrama ka muutujad SN_INSTANCE ja SN_PASSWORD.

Kuid Ansible Tower'is ei ole sellist tüüpi autentimist, kus saaksime neid andmeid ServiceNow jaoks määrata. Kuid Ansible Tower võimaldab meil määratleda kohandatud autentimisviise, täpsemalt saab seda lugeda artiklist „Ansible Tower Feature Spotlight: Custom Credentials“.

Meie puhul näeb input-konfiguratsioon kohandatud autentimisviiside jaoks ServiceNow välja järgmine:

fields:
  - id: SN_USERNAME
	type: string
	label: Kasutajanimi
  - id: SN_PASSWORD
	type: string
	label: Пароль
	secret: true
  - id: SN_INSTANCE
	type: string
	label: ServiceNow instants
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

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

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

Nii, oleme määratlenud vajaliku autentimistüübi, nüüd saame lisada ServiceNow konto ja määrata instantsi, kasutajanime ja parooli, nii:

Loome varude nimekirja

Nii, nüüd on meil kõik valmis, et luua varude nimekiri Ansible Toweris. Nimetame selle ServiceNow:

Inventari loomisel saame andmeallika sellele kinnitada. Siin määrame projekti, mille varem lõime, ja sisestame tee meie inventari YAML-failini versioonihaldussüsteemis, antud juhul servicenow.yml projekti juures. Samuti tuleb siduda ServiceNow konto.

Kontrollimaks, kuidas kõik töötab, proovime andmeallikaga sünkroniseerida, vajutades nuppu 'Sync all'. Kui kõik on õigesti seadistatud, peaksid sõlmed meie inventari importima:

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

Kokkuvõte

Selles postituses vaatleme, kuidas kasutada Ansible Toweris inventeerimisplatvorme kollektsioonidest, kasutades ServiceNow plugina näidet. Samuti jäljendasime turvaliselt oma ServiceNow instantsi ühendamiseks vajalikke mandaate. Inventeerimisplatvormi sidumine projektist töötab mitte ainult kolmandate isikute või konfigureeritavate pluginatega, vaid seda võib kasutada ka teatud vaikimisi inventeerimise tööde modifitseerimiseks. Tänu sellele integreerub Ansible Automation Platform hõlpsasti ja sujuvalt olemasolevate tööriistadega IT-keskkondade automatiseerimisel, mis muutuvad järjest keerulisemaks.

Lisainfot postituses käsitletud teemade kohta, samuti Ansible'i teiste rakenduste aspektide kohta leiate siit:

• Automaatika blogi ServiceNow automatiseerimisest Ansible'i abil.
• Kuidas luua oma kollektsioone.
• Red Hat toetatud kollektsioonide nimekiri Automation Hubis (cloud.redhat.com).
• Ansible Automation Platformi e-raamatud.

*Red Hat ei anna mingeid garantii sellel siin esitatud koodi korrektsuse suhtes. Kõik materjalid on esitatud toetuse puudumise tingimustel, kui pole kirjalikult teisiti loodud.

Allikas: habr.com