IT-miljøer bliver stadig mere komplekse. I denne sammenhæng er det kritisk for IT-automatiseringssystemet at have opdaterede oplysninger om de noder, der er til stede i netværket og skal behandles. I Red Hat Ansible Automation Platform løses dette spørgsmål gennem såkaldte inventar () – lister over administrerede noder.
I sin simpleste form er inventar en statisk fil. Det er den ideelle løsning, når du begynder at arbejde med Ansible, men efterhånden som automatiseringen udvides, bliver det utilstrækkeligt.
Og her er hvorfor:
- Hvordan opdaterer og vedligeholder man et komplet liste over kontrollerede noder, når noget konstant ændrer sig, når arbejdsbelastninger – og dermed de noder, de kører på – opstår og forsvinder?
- Hvordan klassificerer man komponenterne i IT-infrastrukturen, så man målrettet kan vælge noder til at anvende en bestemt automatisering?
Svarene på begge disse spørgsmål gives af dynamisk inventar () – et script eller plugin, der søger efter noder, der skal automatiseres, ved at henvise til en kilde til sandhed (source of truth). Derudover klassificerer det dynamiske inventar automatisk noder i grupper, så du kan vælge målrettede systemer til at udføre en bestemt Ansible-automatisering mere præcist.
giver Ansible-brugeren mulighed for at få adgang til eksterne platforme for dynamisk at finde målrettede noder og bruge disse platforme som kilde til sandhed, når inventaret dannes. Den standardliste over kilder i Ansible inkluderer cloud-platforme som AWS EC2, Google GCP og Microsoft Azure, samt der findes mange andre inventar-plugins til Ansible.
Ansible Tower leveres med en række , der fungerer direkte 'out of the box' og ud over de ovennævnte cloud-platforme sikrer integration med VMware vCenter, Red Hat OpenStack Platform og Red Hat Satellite. For disse plugins er det tilstrækkeligt at give legitimationsoplysninger for at få adgang til den ønskede platform, hvorefter de kan bruges som kilde til inventaroplysninger i Ansible Tower.
Udover de standard plugins, der følger med Ansible Tower, findes der også andre inventar-plugins, der støttes af Ansible-fællesskabet. Med overgangen til blev disse plugins inkluderet i de relevante kollektioner.
I dette indlæg vil vi som eksempel se på arbejdet med inventory-pluginet til ServiceNow, en populær IT-service management platform, hvor kunder ofte opbevarer oplysninger om alle deres enheder i CMDB. Desuden kan CMDB indeholde nyttig kontekst til automatisering, såsom oplysninger om ejere af servere, service niveauer (produktion/ikke-produktion), installerede opdateringer og vedligeholdelsesvinduer. Ansible inventory-pluginet kan arbejde med ServiceNow CMDB og indgår i samlingen. på portalen .
Git-repository
For at bruge inventory-pluginet fra samlingen i Ansible Tower, skal det angives som kilde til projektet. I Ansible Tower er et projekt en integration med et versionsstyringssystem, såsom et git-repository, som kan bruges til at synkronisere ikke kun automatiserings-playbooks, men også variabler og inventory-lister.
Vores repository er faktisk meget enkelt:
├── collections
│ └── requirements.yml
└── servicenow.yml
Filen servicenow.yml indeholder detaljer til inventory-pluginet. I vores tilfælde angiver vi blot tabellen i CMDB ServiceNow, som vi ønsker at bruge. Vi angiver også felterne, der skal tilføjes som nodens variable, plus visse oplysninger om grupper, vi ønsker at 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, at den specifikke ServiceNow-instans, som vi vil oprette forbindelse til, ikke er angivet her, og der er ingen legitimationsoplysninger til forbindelsen. Alt dette vil vi justere senere i Ansible Tower.
er nødvendig for, at Ansible Tower kan downloade den nødvendige samling og dermed 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
Efter vi har sendt denne konfiguration til versionskontrolsystemet, kan der i Ansible Tower oprettes et projekt, der henviser til det relevante repository. I eksemplet nedenfor kobles Ansible Tower til vores repository på github. Bemærk SCM URL'en: den gør det muligt at angive en konto til at tilgå et privat repository samt definere en specifik gren, et tag eller et commit til at hente.
Opretter credentials til ServiceNow
Som nævnt indeholder konfigurationen i vores repository ikke credentials til at tilgå ServiceNow og specificerer ikke den ServiceNow-instans, vi skal kommunikere med. Derfor vil vi oprette credentials i Ansible Tower for at angive disse oplysninger. Ifølge , findes der en række miljøvariabler, som vi kan bruge til at angive forbindelsesparametrene, eksempelvis:
= username
ServiceNow brugerkontoen, den skal have rettigheder til at læse cmdb_ci_server (standard), eller den tabel der er angivet af SN_TABLE
set_via:
env:
- name: SN_USERNAME
I dette tilfælde, hvis miljøvariablen SN_USERNAME er angivet, vil inventory-plugin bruge den som konto til at tilgå ServiceNow.
Vi skal også angive variablerne SN_INSTANCE og SN_PASSWORD.
Men i Ansible Tower findes der ikke credentials af denne type, hvor vi kan angive disse oplysninger til ServiceNow. Ansible Tower giver os derimod mulighed for at definere , hvilket der kan læses mere om i artiklen .
I vores tilfælde ser input-konfigurationen for de tilpassede credentials 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 credentials vil blive eksponeret som miljøvariabler med samme navn. Dette beskrives i injector-konfigurationen:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Således har vi defineret den credential-type, vi har brug for, nu kan vi tilføje ServiceNow-kontoen og angive instansen, brugernavnet og adgangskoden, sådan her:
Opretter inventory
Så nu er vi klar til at oprette et inventory i Ansible Tower. Lad os kalde det ServiceNow:
Efter oprettelsen af inventory kan vi knytte en datakilde til den. Her angiver vi det projekt, vi tidligere har oprettet, og indtaster stien til vores inventory YAML-fil i versionsstyringssystemet, i dette tilfælde er det servicenow.yml i roden af projektet. Derudover skal vi binde ServiceNow-kontoen.
For at kontrollere, hvordan alt fungerer, prøver vi at synkronisere med datakilden ved at klikke på knappen 'Sync all'. Hvis alt er korrekt konfigureret, skal knudepunkterne importeres til vores inventory:
Bemærk, at de nødvendige grupper også er blevet oprettet.
Konklusion
I dette indlæg har vi set på, hvordan man anvender inventory-plugins fra samlinger i Ansible Tower med eksemplet fra ServiceNow-pluginet. Vi har også sikkert angivet legitimationsoplysninger for at forbinde til vores ServiceNow-instance. Binding af inventory-pluginet fra projektet fungerer ikke kun med tredjeparts- eller tilpassede plugins, men kan også anvendes til at modificere funktionen af nogle indbyggede inventory. Dette gør Ansible Automation Platform nemt og sømløst integreret med eksisterende værktøjer til automatisering af it-miljøer, som bliver mere og mere komplekse.
Find yderligere oplysninger om de emner, der er behandlet i dette indlæg, samt om andre aspekter af Ansible-brugen her:
- Blog om .
- .
- Liste over understøttede Red Hat-samlinger på Automation Hub ().
- .
*Red Hat giver ingen garantier for korrektheden af den kode, der er angivet her. Alt materiale gives uden support, medmindre andet er angivet eksplicit.
Kilde: habr.com
