IT-omgevingen worden steeds complexer. In deze omstandigheden is het voor IT-automatiseringssystemen cruciaal om actuele informatie te hebben over de knooppunten die aanwezig zijn in het netwerk en beheerd moeten worden. In het Red Hat Ansible Automation Platform wordt dit probleem opgelost via zogenaamde inventarissen () – lijsten van beheerde knooppunten.
In zijn eenvoudigste vorm is een inventaris een statisch bestand. Dit is de ideale optie wanneer je begint te werken met Ansible, maar naarmate de automatisering toeneemt, is het niet meer voldoende.
En dit is waarom:
- Hoe kan je een volledige lijst met gecontroleerde knooppunten bijwerken en actueel houden als alles constant verandert, als werkbelastingen – en daarmee de knooppunten waarop ze worden uitgevoerd – komen en gaan?
- Hoe kun je de componenten van de IT-infrastructuur classificeren om gericht knooppunten te selecteren voor de toepassing van bepaalde automatiseringen?
Antwoorden op beide vragen worden gegeven door dynamische inventarissen () – een script of plugin die zoekt naar de knooppunten die geautomatiseerd moeten worden, door zich te wenden tot de waarheidssource (source of truth). Bovendien classificeren dynamische inventarissen knooppunten automatisch in groepen, zodat je doelgerichter systemen kunt selecteren voor het uitvoeren van specifieke Ansible-automatiseringen.
geven de Ansible-gebruiker de mogelijkheid om externe platforms te raadplegen voor het dynamisch zoeken naar doelknooppunten en deze platforms als waarheidssource te gebruiken bij het opstellen van de inventaris. De standaardlijst met bronnen in Ansible omvat cloudplatforms zoals AWS EC2, Google GCP en Microsoft Azure, maar er zijn ook veel andere inventarisplugins beschikbaar voor Ansible.
Ansible Tower wordt geleverd met een aantal , die direct ‘uit de doos’ werken en naast de hierboven genoemde cloudplatforms ook integratie met VMware vCenter, Red Hat OpenStack Platform en Red Hat Satellite bieden. Voor deze plugins is het voldoende om inloggegevens op te geven voor verbinding met het doelplatform, waarna ze kunnen worden gebruikt als bron van inventarisgegevens in Ansible Tower.
Naast de standaardplugins van de Ansible Tower-levering zijn er ook andere inventarisplugins die worden ondersteund door de Ansible-gemeenschap. Met de overstap naar worden deze plugins opgenomen in de bijbehorende collecties.
In dit bericht bespreken we als voorbeeld het werken met de inventory-plugin voor ServiceNow, een populair platform voor IT-servicebeheer, waar klanten vaak informatie over al hun apparaten opslaan in de CMDB. Bovendien kan de CMDB nuttige context voor automatisering bevatten, zoals informatie over servereigenaars, serviceniveaus (production/non-production), geïnstalleerde updates en onderhoudsvensters. De Ansible inventory-plugin kan met de CMDB van ServiceNow werken en maakt deel uit van de collectie. op de portal .
Git-repository
Om de inventory-plugin uit de collectie in Ansible Tower te gebruiken, moet deze als projectbron worden ingesteld. In Ansible Tower is een project een integratie met een versiebeheersysteem, zoals een git-repository, die kan worden gebruikt om niet alleen automatiseringsplaybooks, maar ook variabelen en inventorylijsten te synchroniseren.
Onze repository is eigenlijk heel eenvoudig:
├── collections
│ └── requirements.yml
└── servicenow.yml
Het bestand servicenow.yml bevat de details voor de inventory-plugin. In ons geval geven we gewoon de tabel in de CMDB van ServiceNow op die we willen gebruiken. Daarnaast definiëren we de velden die als knooppuntvariabelen zullen worden toegevoegd, plus bepaalde informatie over de groepen die we willen creëren.
$ 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: ''
Let op dat hier op geen enkele manier de ServiceNow-instantie wordt gespecificeerd waarmee we verbinding gaan maken, en er worden geen inloggegevens voor de verbinding opgegeven. Dit zullen we later in Ansible Tower instellen.
is nodig zodat Ansible Tower de benodigde collectie kan downloaden en zo de gewenste inventory-plugin kan verkrijgen. Anders zouden we deze collectie handmatig op al onze Ansible Tower-knooppunten moeten installeren en onderhouden.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Nadat we deze configuratie naar het versiecontrolesysteem hebben gestuurd, kunnen we in Ansible Tower een project aanmaken dat verwijst naar de bijbehorende repository. In het onderstaande voorbeeld verbindt Ansible Tower zich met onze repository op GitHub. Let op de SCM-URL: deze stelt ons in staat om een account op te geven voor verbinding met een privé-repository, en ook om een specifieke tak, label of commit op te geven voor extractie.
Credentials aanmaken voor ServiceNow
Zoals eerder vermeld, bevat de configuratie in onze repository geen inloggegevens voor de verbinding met ServiceNow en specificeert het niet de instantie van ServiceNow waarmee we zullen communiceren. Daarom zullen we deze gegevens opgeven door credentials aan te maken in Ansible Tower. Volgens de , zijn er verschillende omgevingsvariabelen waarmee we de verbindingsparameters kunnen opgeven, bijvoorbeeld als volgt:
= username
Het ServiceNow-gebruikersaccount, het moet rechten hebben om cmdb_ci_server (standaard) of de opgegeven tabel door SN_TABLE te lezen
set_via:
env:
- name: SN_USERNAME
In dit geval, als de omgevingsvariabele SN_USERNAME is ingesteld, zal de inventory-plugin deze gebruiken als het account voor verbinding met ServiceNow.
Daarnaast moeten we de variabelen SN_INSTANCE en SN_PASSWORD opgeven.
Echter, in Ansible Tower zijn er geen credentials van dit type waarin we deze gegevens voor ServiceNow kunnen opgeven. Ansible Tower staat ons echter wel toe om , hierover kan meer worden gelezen in het artikel .
In ons geval ziet de input-configuratie voor aangepaste credentials voor ServiceNow er als volgt uit:
fields:
- id: SN_USERNAME
type: string
label: Gebruikersnaam
- id: SN_PASSWORD
type: string
label: Wachtwoord
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Deze credentials worden geëxposeerd als omgevingsvariabelen met dezelfde naam. Dit wordt beschreven in de injector-configuratie:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Dus, we hebben het juiste type credential gedefinieerd, nu kunnen we het ServiceNow-account toevoegen en de instantie, gebruikersnaam en wachtwoord opgeven, als volgt:
Een inventory aanmaken
Dus, nu zijn we klaar om een inventory aan te maken in Ansible Tower. We noemen het ServiceNow:
Na het aanmaken van de inventory kunnen we een databron eraan koppelen. Hier geven we het project op dat we eerder hebben aangemaakt en voeren we het pad in naar ons inventory-bestand YAML in de versiebeheersysteemrepository, in ons geval is dat servicenow.yml in de hoofdmap van het project. Daarnaast moeten we ook ons ServiceNow-account koppelen.
Om te controleren of alles werkt, proberen we te synchroniseren met de databron door op de knop 'Sync all' te drukken. Als alles correct is ingesteld, moeten de knooppunten worden geïmporteerd in onze inventory:
Let op dat de benodigde groepen ook zijn aangemaakt.
Conclusie
In deze post hebben we besproken hoe we in Ansible Tower inventory-plugins uit collecties kunnen gebruiken, aan de hand van de ServiceNow-plugin. We hebben ook veilig inloggegevens voor de verbinding met onze ServiceNow-instantie vastgelegd. Het koppelen van de inventory-plugin uit het project werkt niet alleen met externe of op maat gemaakte plugins, maar kan ook zeker worden toegepast om de werking van enkele standaard inventory's te modificeren. Hierdoor kan het Ansible Automation Platform eenvoudig en naadloos worden geïntegreerd met bestaande tools bij het automatiseren van IT-omgevingen die steeds complexer worden.
Vind aanvullende informatie over de onderwerpen die in deze post zijn behandeld, evenals over andere aspecten van het gebruik van Ansible hier:
- Blog over .
- .
- Lijst van ondersteunde Red Hat-collecties op de website Automation Hub ().
- .
*Red Hat biedt geen garanties over de juistheid van de hier gepresenteerde code. Al het materiaal wordt geleverd zonder ondersteuning, tenzij expliciet anders vermeld.
Bron: habr.com
