IT-miljøer blir mer og mer komplekse. I disse forholdene er det kritisk for IT-automatiseringssystemet å ha oppdatert informasjon om nodene som er tilstede i nettverket og gjenstand for behandling. I Red Hat Ansible Automation Platform er dette problemet løst gjennom den såkalte inventar () – lister over administrerte noder.
I sin enkleste form er inventar en statisk fil. Dette er ideelt når du begynner å jobbe med Ansible, men etter hvert som automatiseringen øker, blir den utilstrekkelig.
Og her er hvorfor:
- Hvordan oppdaterer og vedlikeholder du en komplett liste over overvåkede noder når ting er i konstant endring, når arbeidsbelastninger – og deretter nodene de kjører på – kommer og går?
- Hvordan klassifisere komponentene i IT-infrastrukturen for å spesifikt velge noder for å bruke en bestemt automatisering?
Dynamisk inventar gir svar på begge disse spørsmålene () – et skript eller plugin som søker etter noder som skal automatiseres, med henvisning til sannhetens kilde. I tillegg klassifiserer den dynamiske beholdningen automatisk noder i grupper, slik at du mer nøyaktig kan velge målsystemer for å utføre spesifikk Ansible-automatisering.
gi Ansible-brukeren muligheten til å få tilgang til eksterne plattformer for å dynamisk søke etter målnoder og bruke disse plattformene som en kilde til sannhet når du oppretter en beholdning. Standardlisten over kilder i Ansible inkluderer skyplattformene AWS EC2, Google GCP og Microsoft Azure, og det finnes også mange andre inventar-plugins for Ansible.
Ansible Tower leveres med en rekke , som fungerer rett ut av esken og, i tillegg til skyplattformene som er oppført ovenfor, gir integrasjon med VMware vCenter, Red Hat OpenStack Platform og Red Hat Satellite. For disse pluginene trenger du bare å oppgi legitimasjon for å koble til målplattformen, hvoretter de kan brukes som en kilde til lagerdata i Ansible Tower.
I tillegg til standardpluginene som følger med Ansible Tower, er det andre inventarplugins som støttes av Ansible-fellesskapet. Med overgangen til disse pluginene begynte å bli inkludert i de tilsvarende samlingene.
I dette innlegget vil vi ta et eksempel på å jobbe med inventory plugin for ServiceNow, en populær IT-tjenesteadministrasjonsplattform der kunder ofte lagrer informasjon om alle enhetene sine i CMDB. I tillegg kan CMDB inneholde kontekst som er nyttig for automatisering, for eksempel informasjon om servereiere, tjenestenivåer (produksjon/ikke-produksjon), installerte oppdateringer og vedlikeholdsvinduer. Ansible inventory plugin kan fungere med ServiceNow CMDB og er en del av samlingen på portalen .
Git repository
For å bruke en inventarplugin fra en samling i Ansible Tower, må den settes som prosjektkilde. I Ansible Tower er et prosjekt en integrasjon med et slags versjonskontrollsystem, som et git-lager, som kan brukes til å synkronisere ikke bare automatiseringsspillbøker, men også variabler og inventarlister.
Vårt depot er faktisk veldig enkelt:
├── collections
│ └── requirements.yml
└── servicenow.yml
Servicenow.yml-filen inneholder detaljer for plugin-beholdningen. I vårt tilfelle spesifiserer vi ganske enkelt tabellen i ServiceNow CMDB som vi ønsker å bruke. Vi setter også feltene som skal legges til som nodevariabler, pluss viss informasjon om gruppene vi ønsker å lage.
$ 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: ''
Vær oppmerksom på at dette ikke spesifiserer ServiceNow-forekomsten som vi vil koble til på noen måte, og spesifiserer ikke noen legitimasjon for tilkobling. Vi vil konfigurere alt dette senere i Ansible Tower.
nødvendig slik at Ansible Tower kan laste ned den nødvendige samlingen og dermed få den nødvendige inventarplugin. Ellers må vi manuelt installere og vedlikeholde denne samlingen på alle våre Ansible Tower-noder.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Når vi har presset denne konfigurasjonen til versjonskontroll, kan vi lage et prosjekt i Ansible Tower som refererer til det tilsvarende depotet. Eksemplet nedenfor kobler Ansible Tower til vårt github-lager. Vær oppmerksom på SCM URL: den lar deg registrere en konto for å koble til et privat depot, samt spesifisere en spesifikk gren, tag eller forplikte deg til å sjekke ut.
Opprette legitimasjon for ServiceNow
Som nevnt inneholder ikke konfigurasjonen i vårt depot legitimasjon for å koble til ServiceNow og spesifiserer ikke ServiceNow-forekomsten vi skal kommunisere med. Derfor, for å angi disse dataene, vil vi opprette legitimasjon i Ansible Tower. I følge , er det en rekke miljøvariabler som vi vil sette tilkoblingsparametrene med, for eksempel slik:
= 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
I dette tilfellet, hvis miljøvariabelen SN_USERNAME er angitt, vil inventarpluginen bruke den som en konto for å koble til ServiceNow.
Vi må også angi variablene SN_INSTANCE og SN_PASSWORD.
Det er imidlertid ingen legitimasjon av denne typen i Ansible Tower der du kan spesifisere disse dataene for ServiceNow. Men Ansible Tower lar oss definere , kan du lese mer om dette i artikkelen .
I vårt tilfelle ser inndatakonfigurasjonen for tilpasset legitimasjon for ServiceNow slik ut:
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
Disse legitimasjonene vil bli eksponert som miljøvariabler med samme navn. Dette er beskrevet i injektorkonfigurasjonen:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Så vi har definert legitimasjonstypen vi trenger, nå kan vi legge til en ServiceNow-konto og angi forekomst, brukernavn og passord, slik:
Vi lager inventar
Så nå er vi alle klare til å lage en beholdning i Ansible Tower. La oss kalle det ServiceNow:
Etter å ha opprettet inventaret, kan vi legge ved en datakilde til det. Her spesifiserer vi prosjektet vi opprettet tidligere og legger inn banen til YAML-inventarfilen vår i kildekontrolllageret, i vårt tilfelle er det servicenow.yml i prosjektroten. I tillegg må du koble til ServiceNow-kontoen din.
For å sjekke hvordan alt fungerer, la oss prøve å synkronisere med datakilden ved å klikke på "Synkroniser alle"-knappen. Hvis alt er riktig konfigurert, bør nodene importeres til vårt inventar:
Vær oppmerksom på at gruppene vi trenger også er opprettet.
Konklusjon
I dette innlegget så vi på hvordan du bruker inventarplugins fra samlinger i Ansible Tower ved å bruke ServiceNow-pluginen som eksempel. Vi har også registrert legitimasjon for å koble til ServiceNow-forekomsten vår. Kobling av en inventar-plugin fra et prosjekt fungerer ikke bare med tredjeparts eller egendefinerte plugins, men kan også brukes til å modifisere driften av noen standard varelager. Dette gjør Ansible Automation Platform enkel og sømløs å integrere med eksisterende verktøy ved automatisering av stadig mer komplekse IT-miljøer.
Du kan finne mer informasjon om emnene som diskuteres i dette innlegget, samt andre aspekter ved bruk av Ansible, her:
- Blogg av .
- .
- Liste over Red Hat-støttede samlinger på nettstedet Automation Hub ().
- .
*Red Hat gir ingen garantier for at koden her er korrekt. Alt materiale er gitt på en ikke-godkjenningsbasis med mindre annet er uttrykkelig angitt.
Kilde: www.habr.com