IT-miljøer bliver mere og mere komplekse. Under disse forhold er det afgørende for IT-automatiseringssystemet at have opdateret information om de noder, der er til stede i netværket og er underlagt behandling. I Red Hat Ansible Automation Platform er dette problem løst gennem den såkaldte inventory () – lister over administrerede noder.
I sin enkleste form er inventar en statisk fil. Dette er ideelt, når du begynder at arbejde med Ansible, men efterhånden som automatiseringen øges, bliver den utilstrækkelig.
Og her er hvorfor:
- Hvordan opdaterer og vedligeholder du en komplet liste over overvågede noder, når tingene hele tiden ændrer sig, når arbejdsbelastninger – og efterfølgende de noder, de kører på – kommer og går?
- Hvordan klassificeres komponenterne i IT-infrastrukturen for specifikt at vælge noder til anvendelse af en bestemt automatisering?
Dynamisk opgørelse giver svar på begge disse spørgsmål () – et script eller et plugin, der søger efter noder, der skal automatiseres, med henvisning til sandhedens kilde. Derudover klassificerer den dynamiske opgørelse automatisk noder i grupper, så du mere præcist kan vælge målsystemer til at udføre specifik Ansible-automatisering.
give Ansible-brugeren mulighed for at få adgang til eksterne platforme for dynamisk at søge efter målknudepunkter og bruge disse platforme som en kilde til sandhed, når der oprettes en beholdning. Standardlisten over kilder i Ansible inkluderer cloud-platforme AWS EC2, Google GCP og Microsoft Azure, og der er også mange andre inventory-plugins til Ansible.
Ansible Tower leveres med et antal , som fungerer lige ud af boksen og, udover de ovennævnte cloud-platforme, giver integration med VMware vCenter, Red Hat OpenStack Platform og Red Hat Satellite. For disse plugins skal du blot angive legitimationsoplysninger for at oprette forbindelse til målplatformen, hvorefter de kan bruges som en kilde til lagerdata i Ansible Tower.
Ud over de standard-plugins, der er inkluderet i Ansible Tower, er der andre inventory-plugins, der understøttes af Ansible-fællesskabet. Med overgangen til disse plugins begyndte at blive inkluderet i de tilsvarende samlinger.
I dette indlæg vil vi tage et eksempel på at arbejde med inventory plugin til ServiceNow, en populær IT-service management platform, hvor kunder ofte gemmer information om alle deres enheder i CMDB. Derudover kan CMDB'en indeholde kontekst, der er nyttig til automatisering, såsom information om serverejere, serviceniveauer (produktion/ikke-produktion), installerede opdateringer og vedligeholdelsesvinduer. Ansible inventory plugin kan arbejde med ServiceNow CMDB og er en del af samlingen på portalen .
Git repository
For at bruge et inventory plugin fra en samling i Ansible Tower, skal det indstilles som projektkilde. I Ansible Tower er et projekt en integration med en form for versionskontrolsystem, som et git-lager, som kan bruges til at synkronisere ikke kun automatiserings-playbooks, men også variabler og inventarlister.
Vores lager er faktisk meget simpelt:
├── collections
│ └── requirements.yml
└── servicenow.yml
Servicenow.yml-filen indeholder detaljer for plugin-beholdningen. I vores tilfælde angiver vi blot den tabel i ServiceNow CMDB, som vi ønsker at bruge. Vi indstiller også de felter, der vil blive tilføjet som nodevariable, plus visse oplysninger om de grupper, vi vil oprette.
$ 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: ''
Bemærk venligst, at dette ikke angiver den ServiceNow-instans, som vi vil oprette forbindelse til på nogen måde, og ikke angiver nogen legitimationsoplysninger for forbindelse. Vi konfigurerer alt dette senere i Ansible Tower.
nødvendig, så Ansible Tower kan downloade den påkrævede samling og derved få det nødvendige inventory plugin. Ellers skulle vi manuelt installere og vedligeholde denne samling på alle vores Ansible Tower-noder.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Når vi har skubbet denne konfiguration til versionskontrol, kan vi oprette et projekt i Ansible Tower, der refererer til det tilsvarende lager. Eksemplet nedenfor linker Ansible Tower til vores github-lager. Vær opmærksom på SCM-URL'en: den giver dig mulighed for at registrere en konto for at oprette forbindelse til et privat lager, samt angive en specifik filial, tag eller forpligtelse til at tjekke ud.
Oprettelse af legitimationsoplysninger til ServiceNow
Som nævnt indeholder konfigurationen i vores lager ikke legitimationsoplysninger til at oprette forbindelse til ServiceNow og specificerer ikke den ServiceNow-instans, som vi vil kommunikere med. For at indstille disse data vil vi derfor oprette legitimationsoplysninger i Ansible Tower. Ifølge , er der en række miljøvariabler, som vi vil indstille forbindelsesparametrene med, for eksempel sådan:
= 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 tilfælde, hvis miljøvariablen SN_USERNAME er indstillet, vil inventory-pluginnet bruge det som en konto til at oprette forbindelse til ServiceNow.
Vi skal også indstille variablerne SN_INSTANCE og SN_PASSWORD.
Der er dog ingen legitimationsoplysninger af denne type i Ansible Tower, hvor du kan angive disse data for ServiceNow. Men Ansible Tower giver os mulighed for at definere , kan du læse mere om dette i artiklen .
I vores tilfælde ser inputkonfigurationen for brugerdefinerede legitimationsoplysninger til ServiceNow sådan ud:
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 legitimationsoplysninger vil blive eksponeret som miljøvariabler med samme navn. Dette er beskrevet i injektorkonfigurationen:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Så vi har defineret den legitimationstype, vi har brug for, nu kan vi tilføje en ServiceNow-konto og indstille forekomsten, brugernavnet og adgangskoden sådan:
Vi laver inventar
Så nu er vi alle klar til at oprette en beholdning i Ansible Tower. Lad os kalde det ServiceNow:
Efter oprettelse af opgørelsen kan vi vedhæfte en datakilde til den. Her specificerer vi det projekt, vi oprettede tidligere, og indtaster stien til vores YAML-inventarfil i kildekontrollageret, i vores tilfælde er det servicenow.yml i projektroden. Derudover skal du tilknytte din ServiceNow-konto.
For at kontrollere, hvordan alt fungerer, lad os prøve at synkronisere med datakilden ved at klikke på knappen "Synkroniser alle". Hvis alt er konfigureret korrekt, skal noderne importeres til vores beholdning:
Bemærk, at de grupper, vi skal bruge, også er blevet oprettet.
Konklusion
I dette indlæg så vi på, hvordan man bruger inventory plugins fra samlinger i Ansible Tower ved at bruge ServiceNow plugin som eksempel. Vi har også sikkert registreret legitimationsoplysninger til at oprette forbindelse til vores ServiceNow-instans. At linke et lagerplugin fra et projekt fungerer ikke kun med tredjeparts- eller brugerdefinerede plugins, men kan også bruges til at ændre driften af nogle standardbeholdninger. Dette gør Ansible Automation Platform nem og problemfri at integrere med eksisterende værktøjer ved automatisering af stadig mere komplekse it-miljøer.
Du kan finde mere information om de emner, der diskuteres i dette indlæg, samt andre aspekter af brugen af Ansible, her:
- Blog af .
- .
- Liste over Red Hat-understøttede samlinger på Automation Hub-webstedet ().
- .
*Red Hat garanterer ikke, at koden indeholdt heri er korrekt. Alt materiale leveres på et ikke-godkendt grundlag, medmindre andet udtrykkeligt er angivet.
Kilde: www.habr.com