Die IT-Umgebungen werden immer komplexer. In diesem Zusammenhang ist es fĂŒr Systeme der IT-Automatisierung von entscheidender Bedeutung, aktuelle Informationen ĂŒber die Knoten zu haben, die im Netzwerk vorhanden sind und verarbeitet werden mĂŒssen. In der Red Hat Ansible Automation Platform wird dieses Problem durch sogenannte Inventare gelöst () â Listen der verwalteten Knoten.
In ihrer einfachsten Form ist ein Inventar eine statische Datei. Dies ist die ideale Lösung, wenn Sie anfangen, mit Ansible zu arbeiten, aber mit der Ausweitung der Automatisierung reicht dies nicht mehr aus.
Und das ist der Grund:
- Wie aktualisiert und pflegt man eine vollstĂ€ndige Liste der kontrollierten Knoten, wenn sich stĂ€ndig etwas Ă€ndert, wenn Arbeitslasten â und damit die Knoten, auf denen sie ausgefĂŒhrt werden â kommen und gehen?
- Wie klassifiziert man die Komponenten der IT-Infrastruktur, um gezielt Knoten fĂŒr die Anwendung einer bestimmten Automatisierung auszuwĂ€hlen?
Antworten auf beide Fragen liefert das dynamische Inventar () â ein Skript oder Plugin, das nach automatisierungsbedĂŒrftigen Knoten sucht und dabei auf die Quelle der Wahrheit (source of truth) zugreift. DarĂŒber hinaus klassifiziert das dynamische Inventar Knoten automatisch in Gruppen, damit Sie gezielter bestimmte Systeme fĂŒr die DurchfĂŒhrung einer bestimmten Ansible-Automatisierung auswĂ€hlen können.
geben dem Ansible-Benutzer die Möglichkeit, auf externe Plattformen zuzugreifen, um gezielt nach Knoten zu suchen, und diese Plattformen als Quelle der Wahrheit beim Erstellen des Inventars zu verwenden. Die Standardliste der Quellen in Ansible umfasst Cloud-Plattformen wie AWS EC2, Google GCP und Microsoft Azure; zudem gibt es viele andere Inventar-Plugins fĂŒr Ansible.
Ansible Tower wird mit einer Reihe von , die direkt "out of the box" funktionieren und neben den oben genannten Cloud-Plattformen auch die Integration mit VMware vCenter, Red Hat OpenStack Platform und Red Hat Satellite bieten, geliefert. FĂŒr diese Plugins genĂŒgt es, Anmeldeinformationen fĂŒr den Zugriff auf die Zielplattform bereitzustellen, danach können sie als Quelle fĂŒr Inventardaten in Ansible Tower verwendet werden.
ZusĂ€tzlich zu den Standard-Plugins aus dem Lieferumfang von Ansible Tower gibt es auch andere Inventar-Plugins, die von der Ansible-Community unterstĂŒtzt werden. Mit dem Ăbergang zu wurden diese Plugins in die entsprechenden Sammlungen aufgenommen.
In diesem Beitrag werden wir als Beispiel die Arbeit mit dem Inventar-Plugin fĂŒr ServiceNow, einer beliebten IT-Service-Management-Plattform, behandeln, in deren CMDB Kunden oft Informationen ĂŒber ihre GerĂ€te speichern. DarĂŒber hinaus kann die CMDB nĂŒtzlichen Kontext fĂŒr die Automatisierung enthalten, wie Informationen ĂŒber Serverbesitzer, Servicelevels (Produktion/Nicht-Produktion), installierte Updates und Wartungsfenster. Das Ansible-Inventar-Plugin kann mit der CMDB von ServiceNow arbeiten und ist Teil der Sammlung. im Portal .
Git-Repository
Um das Inventar-Plugin aus der Sammlung in Ansible Tower zu verwenden, muss es als Projektquelle angegeben werden. In Ansible Tower ist ein Projekt die Integration mit einem Versionskontrollsystem, wie einem Git-Repository, das zur Synchronisierung nicht nur von AutomatisierungsspielbĂŒchern, sondern auch von Variablen sowie Inventarlisten verwendet werden kann.
Unser Repository ist tatsÀchlich sehr einfach:
âââ collections
â âââ requirements.yml
âââ servicenow.yml
Die Datei servicenow.yml enthĂ€lt Details fĂŒr das Inventar-Plugin. In unserem Fall geben wir einfach die Tabelle in der CMDB von ServiceNow an, die wir verwenden möchten. Wir definieren auch die Felder, die als Knotenvariablen hinzugefĂŒgt werden sollen, sowie bestimmte Informationen zu den Gruppen, die wir erstellen möchten.
$ 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: ''
Bitte beachten Sie, dass hier nicht spezifiziert wird, auf welche ServiceNow-Instanz wir zugreifen werden, und dass keine Anmeldedaten fĂŒr die Verbindung angegeben werden. All dies werden wir spĂ€ter in Ansible Tower konfigurieren.
ist erforderlich, damit Ansible Tower die benötigte Sammlung herunterladen kann und somit das gewĂŒnschte Inventar-Plugin erhĂ€lt. Andernfalls mĂŒsste diese Sammlung manuell auf allen unseren Ansible Tower-Knoten installiert und gepflegt werden.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Nachdem wir diese Konfiguration in das Versionskontrollsystem ĂŒbertragen haben, kann im Ansible Tower ein Projekt erstellt werden, das auf das entsprechende Repository verweist. Im folgenden Beispiel wird Ansible Tower mit unserem Repository auf GitHub verknĂŒpft. Beachten Sie die SCM-URL: Sie ermöglicht es, ein Konto fĂŒr den Zugriff auf private Repositories anzugeben sowie einen bestimmten Branch, Tag oder Commit zum Abrufen festzulegen.
Erstellen von Anmeldedaten fĂŒr ServiceNow
Wie bereits erwĂ€hnt, enthĂ€lt die Konfiguration in unserem Repository keine Anmeldedaten fĂŒr den Zugriff auf ServiceNow und spezifiziert nicht die Instanz von ServiceNow, mit der wir kommunizieren werden. Daher werden wir diese Daten durch Erstellen von Anmeldedaten im Ansible Tower festlegen. Laut , gibt es eine Reihe von Umgebungsvariablen, mit denen wir die Verbindungseinstellungen festlegen, zum Beispiel so:
= Benutzername
Das ServiceNow-Benutzerkonto, es sollte Berechtigungen haben, um cmdb_ci_server (Standard) oder die von SN_TABLE angegebene Tabelle zu lesen.
set_via:
env:
- name: SN_USERNAME
In diesem Fall, wenn die Umgebungsvariable SN_USERNAME gesetzt ist, verwendet das Inventar-Plugin diese als Anmeldedaten fĂŒr den Zugriff auf ServiceNow.
ZusĂ€tzlich mĂŒssen wir die Variablen SN_INSTANCE und SN_PASSWORD festlegen.
Allerdings gibt es im Ansible Tower keine Anmeldedaten dieses Typs, bei denen diese Daten fĂŒr ServiceNow angegeben werden könnten. Stattdessen erlaubt uns Ansible Tower, , weitere Informationen dazu finden Sie in dem Artikel .
In unserem Fall sieht die Eingabekonfiguration fĂŒr die benutzerdefinierten Anmeldedaten fĂŒr ServiceNow wie folgt aus:
fields:
- id: SN_USERNAME
type: string
label: Benutzername
- id: SN_PASSWORD
type: string
label: Passwort
secret: true
- id: SN_INSTANCE
type: string
label: Snow-Instanz
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Diese Anmeldedaten werden als Umgebungsvariablen mit demselben Namen exponiert. Dies wird in der Konfiguration des Injectors beschrieben:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
So, wir haben den benötigten Anmeldedatentyp definiert, jetzt können wir das ServiceNow-Konto hinzufĂŒgen und die Instanz, den Benutzernamen und das Passwort wie folgt festlegen:
Inventar erstellen
So, jetzt haben wir alles bereit, um ein Inventar im Ansible Tower zu erstellen. Nennen wir es ServiceNow:
Nach der Erstellung des Inventars können wir eine Datenquelle daran anhĂ€ngen. Hier geben wir das Projekt an, das wir zuvor erstellt haben, und fĂŒhren den Pfad zu unserer Inventar-YAML-Datei im Versionsverwaltungssystem ein, in unserem Fall servicenow.yml im Stammverzeichnis des Projekts. AuĂerdem mĂŒssen wir das ServiceNow-Konto verknĂŒpfen.
Um zu ĂŒberprĂŒfen, wie alles funktioniert, versuchen wir, uns mit der Datenquelle zu synchronisieren, indem wir die SchaltflĂ€che âAlle synchronisierenâ drĂŒcken. Wenn alles korrekt eingerichtet ist, sollten die Knoten in unser Inventar importiert werden:
Bitte beachten Sie, dass auch die benötigten Gruppen erstellt wurden.
Fazit
In diesem Beitrag haben wir behandelt, wie man in Ansible Tower Inventar-Plugins aus Sammlungen am Beispiel des ServiceNow-Plugins verwendet. Wir haben auch sicher die Anmeldeinformationen fĂŒr die Verbindung zu unserer ServiceNow-Instanz eingegeben. Die VerknĂŒpfung des Inventar-Plugins aus dem Projekt funktioniert nicht nur mit externen oder benutzerdefinierten Plugins, sondern kann auch verwendet werden, um das Verhalten einiger integrierter Inventare zu modifizieren. Dadurch lĂ€sst sich die Ansible Automation Platform problemlos und nahtlos mit bestehenden Tools zur Automatisierung von IT-Umgebungen integrieren, die immer komplexer werden.
ZusÀtzliche Informationen zu den in diesem Beitrag behandelten Themen sowie zu anderen Aspekten der Verwendung von Ansible finden Sie hier:
- Blog ĂŒber .
- .
- Liste der unterstĂŒtzten Red Hat-Sammlungen auf der Seite Automation Hub ().
- .
*Red Hat gibt keine Garantie fĂŒr die Richtigkeit des hier angegebenen Codes. Alle Materialien werden unter der Bedingung bereitgestellt, dass keine UnterstĂŒtzung angeboten wird, es sei denn, dies wird ausdrĂŒcklich anders erklĂ€rt.
Quelle: habr.com
