IT-miljöer blir mer och mer komplexa. Under dessa förhållanden är det avgörande för IT-automatiseringssystemet att ha aktuell information om de noder som finns i nätverket och är föremål för bearbetning. I Red Hat Ansible Automation Platform löses detta problem genom den så kallade inventeringen () – listor över hanterade noder.
I sin enklaste form är inventering en statisk fil. Detta är idealiskt när du börjar arbeta med Ansible, men när automatiseringen ökar blir den otillräcklig.
Och här är varför:
- Hur uppdaterar och underhåller du en komplett lista över övervakade noder när saker ständigt förändras, när arbetsbelastningar – och därefter noderna de körs på – kommer och går?
- Hur klassificerar man komponenterna i IT-infrastrukturen för att specifikt välja noder för att tillämpa en viss automation?
Dynamisk inventering ger svar på båda dessa frågor () – ett skript eller plugin som söker efter noder som ska automatiseras, med hänvisning till sanningens källa. Dessutom klassificerar den dynamiska inventeringen automatiskt noder i grupper så att du mer exakt kan välja målsystem för att utföra specifik Ansible-automatisering.
ge Ansible-användaren möjligheten att komma åt externa plattformar för att dynamiskt söka efter målnoder och använda dessa plattformar som en sanningskälla när man skapar en inventering. Standardlistan över källor i Ansible inkluderar molnplattformarna AWS EC2, Google GCP och Microsoft Azure, och det finns även många andra inventeringsplugin för Ansible.
Ansible Tower kommer med ett antal , som fungerar direkt och, förutom molnplattformarna som anges ovan, tillhandahåller integration med VMware vCenter, Red Hat OpenStack Platform och Red Hat Satellite. För dessa plugins behöver du bara tillhandahålla referenser för att ansluta till målplattformen, varefter de kan användas som en källa för lagerdata i Ansible Tower.
Utöver standardplugins som ingår i Ansible Tower, finns det andra inventeringsplugins som stöds av Ansible-communityt. Med övergången till dessa plugins började inkluderas i motsvarande samlingar.
I det här inlägget kommer vi att ta ett exempel på att arbeta med inventeringsplugin för ServiceNow, en populär IT-tjänstehanteringsplattform där kunder ofta lagrar information om alla sina enheter i CMDB. Dessutom kan CMDB innehålla sammanhang som är användbart för automatisering, såsom information om serverägare, servicenivåer (produktion/icke-produktion), installerade uppdateringar och underhållsfönster. Ansible inventory plugin kan fungera med ServiceNow CMDB och är en del av samlingen på portalen .
Git repository
För att använda ett inventeringsplugin från en samling i Ansible Tower måste det ställas in som projektkälla. I Ansible Tower är ett projekt en integration med något slags versionskontrollsystem, som ett git-förråd, som kan användas för att synkronisera inte bara automatiseringsspelböcker utan även variabler och inventeringslistor.
Vårt förråd är faktiskt väldigt enkelt:
├── collections
│ └── requirements.yml
└── servicenow.yml
Filen servicenow.yml innehåller detaljer för plugin-inventeringen. I vårt fall anger vi helt enkelt tabellen i ServiceNow CMDB som vi vill använda. Vi ställer också in fälten som kommer att läggas till som nodvariabler, plus viss information om de grupper som vi vill skapa.
$ 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: ''
Observera att detta inte specificerar ServiceNow-instansen som vi kommer att ansluta till på något sätt, och inte specificerar några referenser för anslutning. Vi kommer att konfigurera allt detta senare i Ansible Tower.
behövs så att Ansible Tower kan ladda ner den erforderliga samlingen och därigenom erhålla den nödvändiga inventeringsplugin. Annars skulle vi behöva installera och underhålla den här samlingen manuellt på alla våra Ansible Tower-noder.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
När vi har drivit den här konfigurationen till versionskontroll kan vi skapa ett projekt i Ansible Tower som refererar till motsvarande arkiv. Exemplet nedan länkar Ansible Tower till vårt github-förråd. Var uppmärksam på SCM-URL: den låter dig registrera ett konto för att ansluta till ett privat förråd, samt ange en specifik gren, tagg eller förpliktelse att checka ut.
Skapa autentiseringsuppgifter för ServiceNow
Som nämnts innehåller konfigurationen i vårt arkiv inga referenser för att ansluta till ServiceNow och anger inte vilken ServiceNow-instans vi kommer att kommunicera med. Därför, för att ställa in dessa data, kommer vi att skapa autentiseringsuppgifter i Ansible Tower. Enligt , det finns ett antal miljövariabler med vilka vi ställer in anslutningsparametrarna, till exempel så här:
= 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 det här fallet, om miljövariabeln SN_USERNAME är inställd, kommer inventeringspluginen att använda den som ett konto för att ansluta till ServiceNow.
Vi måste också ställa in variablerna SN_INSTANCE och SN_PASSWORD.
Det finns dock inga inloggningsuppgifter av den här typen i Ansible Tower där du kan ange dessa data för ServiceNow. Men Ansible Tower tillåter oss att definiera , du kan läsa mer om detta i artikeln .
I vårt fall ser ingångskonfigurationen för anpassade autentiseringsuppgifter för ServiceNow ut så här:
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
Dessa referenser kommer att exponeras som miljövariabler med samma namn. Detta beskrivs i injektorkonfigurationen:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Så vi har definierat den typ av autentisering vi behöver, nu kan vi lägga till ett ServiceNow-konto och ställa in instans, användarnamn och lösenord, så här:
Vi skapar inventering
Så nu är vi alla redo att skapa en inventering i Ansible Tower. Låt oss kalla det ServiceNow:
Efter att ha skapat inventeringen kan vi bifoga en datakälla till den. Här specificerar vi projektet vi skapade tidigare och anger sökvägen till vår YAML-inventeringsfil i källkontrollförrådet, i vårt fall är det servicenow.yml i projektroten. Dessutom måste du länka ditt ServiceNow-konto.
För att kontrollera hur allt fungerar, låt oss försöka synkronisera med datakällan genom att klicka på knappen "Synkronisera alla". Om allt är korrekt konfigurerat bör noderna importeras till vårt lager:
Observera att de grupper vi behöver också har skapats.
Slutsats
I det här inlägget tittade vi på hur man använder inventeringsplugin från samlingar i Ansible Tower med hjälp av ServiceNow-plugin som exempel. Vi har också säkert registrerat autentiseringsuppgifter för att ansluta till vår ServiceNow-instans. Att länka ett inventeringsplugin från ett projekt fungerar inte bara med tredjeparts- eller anpassade plugin-program, utan kan också användas för att modifiera driften av vissa standardinventeringar. Detta gör Ansible Automation Platform enkel och sömlös att integrera med befintliga verktyg vid automatisering av allt mer komplexa IT-miljöer.
Du kan hitta mer information om de ämnen som diskuteras i det här inlägget, såväl som andra aspekter av att använda Ansible, här:
- Blogga av .
- .
- Lista över Red Hat-stödda samlingar på Automation Hub-webbplatsen ().
- .
*Red Hat garanterar inte att koden som finns här är korrekt. Allt material tillhandahålls utan stöd om inte annat uttryckligen anges.
Källa: will.com