IT-medioj fariĝas pli kaj pli kompleksaj. En ĉi tiuj kondiĉoj, estas kritike por la IT-aŭtomatiga sistemo havi ĝisdatigitajn informojn pri la nodoj, kiuj ĉeestas en la reto kaj submetataj al pretigo. En la Red Hat Ansible Automation Platform, ĉi tiu problemo estas solvita per la tiel nomata inventaro () - listoj de administritaj nodoj.
En ĝia plej simpla formo, inventaro estas senmova dosiero. Ĉi tio estas ideala kiam vi komencas labori kun Ansible, sed kiam aŭtomatigo pliiĝas, ĝi fariĝas nesufiĉa.
Kaj jen kial:
- Kiel vi ĝisdatigas kaj konservas kompletan liston de monitoritaj nodoj kiam aferoj konstante ŝanĝiĝas, kiam laborkvantoj—kaj poste la nodoj sur kiuj ili funkcias—venas kaj iras?
- Kiel klasifiki la komponantojn de la IT-infrastrukturo por specife elekti nodojn por apliki apartan aŭtomatigon?
Dinamika inventaro donas respondojn al ambaŭ ĉi tiuj demandoj () - skripto aŭ kromaĵo kiu serĉas nodojn por esti aŭtomatigitaj, rilatante al la fonto de vero. Krome, la dinamika inventaro aŭtomate klasifikas nodojn en grupojn por ke vi povu pli precize elekti celsistemojn por plenumi specifan aŭtomatigon de Ansible.
donu al la uzanto de Ansible la kapablon aliri eksterajn platformojn por dinamike serĉi celajn nodojn kaj uzi ĉi tiujn platformojn kiel fonton de vero dum kreado de inventaro. La norma listo de fontoj en Ansible inkluzivas nubajn platformojn AWS EC2, Google GCP kaj Microsoft Azure, kaj ekzistas ankaŭ multaj aliaj inventarkromaĵoj por Ansible.
Ansible Tower venas kun kelkaj , kiuj funkcias tuj el la skatolo kaj, krom la nubaj platformoj listigitaj supre, provizas integriĝon kun VMware vCenter, Red Hat OpenStack Platform kaj Red Hat Satellite. Por ĉi tiuj kromaĵoj, vi nur bezonas provizi akreditaĵojn por konekti al la cela platformo, post kio ili povas esti uzataj kiel fonto de inventardatumoj en Ansible Tower.
Krom la normaj aldonaĵoj inkluzivitaj kun Ansible Tower, ekzistas aliaj inventarkromaĵoj subtenataj de la Ansible-komunumo. Kun la transiro al ĉi tiuj kromaĵoj komencis esti inkluzivitaj en la respondajn kolektojn.
En ĉi tiu afiŝo, ni prenos ekzemplon pri laborado kun la inventora kromaĵo por ServiceNow, populara platformo pri administrado de IT-servo, en kiu klientoj ofte stokas informojn pri ĉiuj siaj aparatoj en la CMDB. Krome, la CMDB povas enhavi kuntekston kiu estas utila por aŭtomatigo, kiel ekzemple informoj pri servilposedantoj, servniveloj (produktado/ne-produktado), instalitaj ĝisdatigoj, kaj funkciservaj fenestroj. La Ansible-inventora kromaĵo povas funkcii kun ServiceNow CMDB kaj estas parto de la kolekto sur la portalo .
Git-deponejo
Por uzi inventarkromaĵon de kolekto en Ansible Tower, ĝi devas esti agordita kiel la projektfonto. En Ansible Tower, projekto estas integriĝo kun ia versio-kontrolsistemo, kiel git-deponejo, kiu povas esti uzata por sinkronigi ne nur aŭtomatigajn ludlibrojn, sed ankaŭ variablojn kaj inventarlistojn.
Nia deponejo estas fakte tre simpla:
├── collections
│ └── requirements.yml
└── servicenow.yml
La dosiero servicenow.yml enhavas detalojn por la stokregistro de aldonaĵoj. En nia kazo, ni simple specifas la tabelon en la ServiceNow CMDB, kiun ni volas uzi. Ni ankaŭ fiksas la kampojn, kiuj estos aldonitaj kiel nodaj variabloj, krom certaj informoj pri la grupoj, kiujn ni volas krei.
$ 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: ''
Bonvolu noti, ke ĉi tio ne specifas la ekzempleron de ServiceNow, al kiu ni iel ajn konektos, kaj ne specifas iujn ajn akreditaĵojn por konekto. Ni agordos ĉion ĉi poste en Ansible Tower.
bezonata por ke Ansible Tower povu elŝuti la bezonatan kolekton kaj per tio akiri la bezonatan inventarkromaĵon. Alie, ni devus permane instali kaj konservi ĉi tiun kolekton sur ĉiuj niaj Ansible Tower-nodoj.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Post kiam ni puŝis ĉi tiun agordon al versio-kontrolo, ni povas krei projekton en Ansible Tower, kiu referencas al la responda deponejo. La suba ekzemplo ligas Ansible Tower al nia github-deponejo. Atentu la SCM-URL: ĝi permesas vin registri konton por konektiĝi al privata deponejo, kaj ankaŭ specifi specifan branĉon, etikedon aŭ devontigi kontroli.
Kreante akreditaĵojn por ServiceNow
Kiel menciite, la agordo en nia deponejo ne enhavas akreditaĵojn por konekti al ServiceNow kaj ne specifas la ekzempleron de ServiceNow, kun kiu ni komunikiĝos. Tial, por agordi ĉi tiujn datumojn, ni kreos akreditaĵojn en Ansible Tower. Laŭ , ekzistas kelkaj mediovariabloj per kiuj ni agordos la konektajn parametrojn, ekzemple, jene:
= 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
En ĉi tiu kazo, se la mediovariablo SN_USERNAME estas agordita, la inventora kromaĵo uzos ĝin kiel konton por konekti al ServiceNow.
Ni ankaŭ devas agordi la variablojn SN_INSTANCE kaj SN_PASSWORD.
Tamen, ekzistas neniuj akreditaĵoj de ĉi tiu tipo en Ansible Tower kie vi povus specifi ĉi tiujn datumojn por ServiceNow. Sed Ansible Tower permesas al ni difini , vi povas legi pli pri tio en la artikolo .
En nia kazo, la eniga agordo por kutimaj akreditaĵoj por ServiceNow aspektas jene:
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
Ĉi tiuj akreditaĵoj estos elmontritaj kiel mediaj variabloj kun la sama nomo. Ĉi tio estas priskribita en la injektila agordo:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Do, ni difinis la akreditaĵojn, kiujn ni bezonas, nun ni povas aldoni konton de ServiceNow kaj agordi la petskribon, uzantnomon kaj pasvorton, jene:
Ni kreas inventaron
Do, nun ni ĉiuj pretas krei inventaron en Ansible Tower. Ni nomu ĝin ServiceNow:
Post kreado de la inventaro, ni povas ligi al ĝi datumfonton. Ĉi tie ni specifas la projekton, kiun ni kreis pli frue kaj eniras la vojon al nia YAML-inventara dosiero en la fontkontrola deponejo, en nia kazo ĝi estas servicenow.yml en la projekta radiko. Krome, vi devas ligi vian ServiceNow-konton.
Por kontroli kiel ĉio funkcias, ni provu sinkronigi kun la datumfonto alklakante la butonon "Sinkronigi ĉion". Se ĉio estas agordita ĝuste, tiam la nodoj devus esti importitaj en nian inventaron:
Bonvolu noti, ke la grupoj, kiujn ni bezonas, ankaŭ estis kreitaj.
konkludo
En ĉi tiu afiŝo, ni rigardis kiel uzi inventarajn kromaĵojn de kolektoj en Ansible Tower uzante la aldonaĵon ServiceNow kiel ekzemplon. Ni ankaŭ sekure registris akreditaĵojn por konekti al nia ServiceNow-instanco. Ligi stokregistran kromaĵon de projekto funkcias ne nur kun triaj aŭ kutimaj aldonaĵoj, sed ankaŭ povas esti uzata por modifi la funkciadon de iuj normaj inventaroj. Ĉi tio igas Ansible Automation Platform facila kaj senjunta integriĝi kun ekzistantaj iloj kiam aŭtomatigas ĉiam pli kompleksajn IT-mediojn.
Vi povas trovi pli da informoj pri la temoj diskutitaj en ĉi tiu afiŝo, same kiel aliajn aspektojn de uzado de Ansible, ĉi tie:
- Blogo de .
- .
- Listo de Red Hat subtenataj kolektoj en la retejo de Automation Hub ().
- .
*Red Hat ne garantias, ke la kodo enhavita ĉi tie estas ĝusta. Ĉiuj materialoj estas provizitaj surbaze de ne-aprobo krom se alie eksplicite dirite.
fonto: www.habr.com