Användning av inventeringsplugins från Ansible Content Collections i Ansible Tower.

IT-miljöer blir allt mer komplexa. Under dessa förhållanden är det kritiskt för systemet för IT-automatisering att ha aktuell information om noder som finns i nätverket och ska hanteras. I Red Hat Ansible Automation Platform hanteras denna fråga genom så kallade inventarier (inventory) – listor över hanterade noder.

I sin enklaste form är inventariet en statisk fil. Detta är det perfekta alternativet när du börjar arbeta med Ansible, men i takt med att automatiseringen expanderar, blir det otillräckligt.

Och här är varför:

1. Hur uppdaterar och underhåller man den fullständiga listan över kontrollerade noder när något ständigt förändras, när arbetsbelastningar – och därmed noderna där de körs – hela tiden kommer och går?
2. Hur klassificerar man komponenter i IT-infrastrukturen för att noggrant välja noder för att tillämpa vissa automatiseringar?

Svar på båda dessa frågor ges av dynamiska inventarier (dynamic inventory) – ett skript eller en plugin som söker efter noder som är under automatisering och tar hjälp av källan till sanningen (source of truth). Dessutom klassificerar det dynamiska inventariet automatiskt noder i grupper, vilket gör att du kan välja målsystem med större precision för att utföra olika Ansible-automatiseringar.

Inventari-plugins ger Ansible-användaren möjlighet att interagera med externa plattformar för dynamisk sökning av mål noder och använda dessa plattformar som källa till sanningen vid skapandet av inventarier. Den standardiserade listan över källor i Ansible inkluderar molnplattformar som AWS EC2, Google GCP och Microsoft Azure, och det finns också många andra inventari-plugins för Ansible.

Ansible Tower levereras med en uppsättning inventari-plugins, som fungerar direkt "ur lådan" och förutom ovan nämnda molnplattformar erbjuder också integration med VMware vCenter, Red Hat OpenStack Platform och Red Hat Satellite. För dessa plugins räcker det att tillhandahålla autentiseringsuppgifter för att ansluta till den målplattform, efter vilket de kan användas som källa för inventariedata i Ansible Tower.

Utöver de medföljande plugins från Ansible Towers leverans finns det även andra inventari-plugins som stöds av Ansible-communityn. Med övergången till Red Hat Ansible Content Collections blir dessa plugins en del av de relevanta samlingarna.

I det här inlägget kommer vi att gå igenom hur man arbetar med inventarie-plugin för ServiceNow, en populär plattform för IT-tjänstehantering, där kunder ofta lagrar information om alla sina enheter i CMDB. Dessutom kan CMDB innehålla användbar kontext för automatisering, såsom information om serverägare, service-nivåer (production/non-production), installerade uppdateringar och underhållsfönster. Ansible-inventariepluginet kan arbeta med CMDB ServiceNow och ingår i kollektionen servicenow på portalen galaxy.ansible.com.

Git-repository

För att använda inventariepluginet i Ansible Tower från kollektion måste det anges som projektkälla. I Ansible Tower är ett projekt en integration med något versionshanteringssystem, som ett git-repo, som kan användas för att synkronisera inte bara automatiseringsspelplaner, utan även variabler och inventarielistor.

Vårt repo är faktiskt väldigt enkelt:

├── collections
│   └── requirements.yml
└── servicenow.yml

Filen servicenow.yml innehåller detaljer för inventariepluginet. I vårt fall anger vi bara tabellen i CMDB ServiceNow som vi vill använda. Vi specificerar också de fält som ska läggas till som nodvariabler, samt viss information om 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 här specificeras ingen instans av ServiceNow som vi kommer att koppla till, och inga autentiseringsuppgifter anges för anslutningen. Allt detta kommer vi att konfigurera senare i Ansible Tower.

Filen collections/requirements.yml behövs så att Ansible Tower kan ladda ner den nödvändiga kollektionen och därmed få den nödvändiga inventariepluginet. Annars skulle vi behöva installera och underhålla denna kollektion manuellt på alla våra Ansible Tower-noder.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

Efter att vi har skickat denna konfiguration till versionshanteringssystemet kan vi skapa ett projekt i Ansible Tower som hänvisar till det relevanta arkivet. I exemplet nedan kopplas Ansible Tower till vårt arkiv på github. Observera SCM URL:en, som gör att du kan ange ett konto för att ansluta till det privata arkivet, samt specificera en viss gren, etikett eller commit som ska hämtas.

Skapar inloggningsuppgifter för ServiceNow

Som redan nämnts innehåller inte konfigurationen i vårt arkiv några inloggningsuppgifter för att ansluta till ServiceNow och specificerar inte den ServiceNow-instans som vi kommer att kommunicera med. Därför kommer vi att skapa inloggningsuppgifter i Ansible Tower för att ange dessa uppgifter. Enligt dokumentationen för ServiceNow-inventarplugin, finns det ett antal miljövariabler som vi kan använda för att specificera anslutningsparametrarna, till exempel så här:

= användarnamn
    	ServiceNow-användarkonto, det bör ha rätt att läsa cmdb_ci_server (standard) eller tabellen som specificerats av SN_TABLE

    	set_via:
      	env:
      	- namn: SN_USERNAME

I detta fall, om miljövariabeln SN_USERNAME är angiven, kommer inventarpluginet att använda den som konto för att ansluta till ServiceNow.

Vi måste också ange variablerna SN_INSTANCE och SN_PASSWORD.

Dock finns det inga sådana inloggningsuppgifter av denna typ i Ansible Tower, där vi kan ange dessa uppgifter för ServiceNow. Men Ansible Tower låter oss definiera anpassade typer av inloggningsuppgifter, mer information om detta kan läsas i artikeln «Ansible Tower Feature Spotlight: Custom Credentials».

I vårt fall ser input-konfigurationen för de anpassade inloggningsuppgifterna för ServiceNow ut som följer:

fields:
  - id: SN_USERNAME
	typ: sträng
	etikett: Användarnamn
  - id: SN_PASSWORD
	typ: sträng
	etikett: Lösenord
	hemlig: true
  - id: SN_INSTANCE
	typ: sträng
	etikett: Snowinstans
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

Dessa inloggningsuppgifter kommer att exponeras som miljövariabler med samma namn. Detta beskrivs i injector-konfigurationen:

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

Så vi har definierat den typ av inloggningsuppgift vi behöver, nu kan vi lägga till ServiceNow-kontot och ange instansen, användarnamnet och lösenordet på följande sätt:

Skapar inventarier

Så nu är vi redo att skapa en inventarie i Ansible Tower. Vi kallar den ServiceNow:

Efter att ha skapat inventariet kan vi koppla en datakälla till det. Här anger vi projektet som vi skapade tidigare och anger sökvägen till vår inventariefil YAML i versionshanteringssystemet, i vårt fall servicenow.yml i projektets rotmapp. Dessutom måste vi koppla vårt ServiceNow-konto.

För att kontrollera hur allt fungerar, låt oss försöka synkronisera med datakällan genom att klicka på knappen «Sync all». Om allt är korrekt inställt bör noderna importeras till vårt inventarium:

Observera att de nödvändiga grupperna också har skapats.

Slutsats

I det här inlägget har vi granskat hur man använder inventariplugin från samlingar i Ansible Tower med fokus på pluginet ServiceNow. Vi har också säkert angett autentiseringsuppgifterna för att ansluta till vår ServiceNow-instans. Kopplingen av inventariplugin från projektet fungerar inte bara med externa eller anpassade plugins, utan kan även tillämpas för att ändra funktionen hos vissa inbyggda inventarier. Tack vare detta integreras Ansible Automation Platform smidigt med befintliga verktyg vid automatisering av IT-miljöer som blir alltmer komplexa.

Du kan hitta mer information om de ämnen som behandlas i det här inlägget samt andra aspekter av Ansible här:

• Blogg om automatisering av ServiceNow med Ansible.
• Hur man skapar sina egna samlingar.
• Lista över stödja Red Hat-samlingar på Automation Hub-webbplatsen (cloud.redhat.com).
• E-böcker om Ansible Automation Platform.

*Red Hat lämnar inga garantier för korrektheten hos den kod som anges här. Allt material tillhandahålls utan support, om inte annat uttryckligen anges.

Källa: habr.com