IT-Umgebungen werden immer komplexer. In diesem Kontext ist es für ein IT-Automatisierungssystem entscheidend, aktuelle Informationen über die Knoten zu haben, die im Netzwerk vorhanden sind und verwaltet werden müssen. In der Red Hat Ansible Automation Platform wird dieses Problem durch die sogenannten Inventare gelöst () – Listen von verwalteten Knoten.
In ihrer einfachsten Form ist ein Inventar eine statische Datei. Das ist ideal, wenn Sie beginnen, mit Ansible zu arbeiten, aber im Laufe der Automatisierung reicht das nicht mehr aus.
Und genau deshalb:
- Wie hält man eine umfassende Liste der kontrollierten Knoten aktuell, wenn sich ständig etwas ändert, wenn Arbeitslasten – und damit die Knoten, auf denen sie ausgeführt werden – entstehen und verschwinden?
- Wie klassifiziert man die Komponenten der IT-Infrastruktur, um gezielt Knoten für die Anwendung bestimmter Automatisierungen auszuwählen?
Die Antworten auf beide Fragen liefert das dynamische Inventar () – ein Skript oder Plugin, das nach automatisierbaren Knoten sucht, indem es auf die Quelle der Wahrheit (source of truth) zugreift. Darüber hinaus klassifiziert das dynamische Inventory Knoten automatisch in Gruppen, sodass Sie die Zielsysteme für die Durchführung einer bestimmten Ansible-Automatisierung genauer auswählen können.
geben dem Ansible-Benutzer die Möglichkeit, auf externe Plattformen zuzugreifen, um dynamisch Zielknoten zu finden, und diese Plattformen als Quelle der Wahrheit bei der Erstellung des Inventars zu nutzen. Die Standardliste der Quellen in Ansible umfasst Cloud-Plattformen wie AWS EC2, Google GCP und Microsoft Azure, außerdem gibt es viele weitere Inventory-Plugins für Ansible.
Ansible Tower wird mit einer Reihe von geliefert, 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. Für diese Plugins müssen lediglich die Anmeldeinformationen bereitgestellt werden, um eine Verbindung zur Zielplattform herzustellen, danach können sie als Quelle für Inventardaten in Ansible Tower verwendet werden.
Neben den standardmäßigen Plugins, die mit Ansible Tower geliefert werden, gibt es auch andere Inventory-Plugins, die von der Ansible-Community unterstützt werden. Mit der Umstellung auf wurden diese Plugins in die entsprechenden Sammlungen aufgenommen.
In diesem Beitrag betrachten wir als Beispiel die Verwendung des Inventory-Plugins für ServiceNow, einer beliebten IT-Service-Management-Plattform, in deren CMDB Kunden häufig Informationen über all ihre Geräte speichern. Darüber hinaus kann die CMDB nützliche Kontexte für die Automatisierung enthalten, wie beispielsweise Informationen zu Serverbesitzern, Service Levels (Production/Non-Production), installierten Updates und Wartungsfenstern. Das Ansible Inventory-Plugin kann mit der ServiceNow CMDB arbeiten und ist Teil der Sammlung auf dem Portal .
Git-Repository
Um das Inventory-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 Versionsverwaltungssystem, wie einem Git-Repository, das zur Synchronisation von nicht nur Automatisierungsplaybooks, sondern auch Variablen und Inventory-Listen verwendet werden kann.
Unser Repository ist eigentlich 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. Außerdem definieren wir die Felder, die als Knoten-Variablen hinzugefügt werden, sowie bestimmte Informationen zu den Gruppen, die wir erstellen wollen.
$ 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 keine spezifische ServiceNow-Instanz angegeben wird, mit der wir uns verbinden werden, und keine Anmeldedaten für die Verbindung festgelegt sind. All dies werden wir später in Ansible Tower konfigurieren.
wird benötigt, damit Ansible Tower die erforderliche Sammlung herunterladen und somit das benötigte Inventar-Plugin erhalten kann. Andernfalls müsste diese Sammlung manuell auf allen unseren Ansible Tower-Knoten installiert und gewartet 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 bindet Ansible Tower an unser Repository auf GitHub. Beachten Sie die SCM-URL: Sie ermöglicht es, ein Konto für die Verbindung zu einem privaten Repository anzugeben und einen bestimmten Branch, Tag oder Commit für den Abruf festzulegen.
Erstellen wir Anmeldeinformationen für ServiceNow
Wie bereits erwähnt, enthält die Konfiguration in unserem Repository keine Anmeldeinformationen für die Verbindung zu ServiceNow und spezifiziert nicht die ServiceNow-Instanz, mit der wir kommunizieren werden. Daher werden wir diese Daten in Ansible Tower durch die Erstellung von Anmeldeinformationen festlegen. Gemäß , gibt es eine Reihe von Umgebungsvariablen, mit denen wir die Verbindungsparameter festlegen können, zum Beispiel so:
= username
Das ServiceNow-Benutzerkonto, es sollte Rechte zum Lesen von cmdb_ci_server (Standard) oder der in SN_TABLE angegebenen Tabelle haben
set_via:
env:
- name: SN_USERNAME
In diesem Fall, wenn die Umgebungsvariable SN_USERNAME gesetzt ist, wird das Inventory-Plugin diese als Anmeldekonto für die Verbindung zu ServiceNow verwenden.
Außerdem müssen wir die Variablen SN_INSTANCE und SN_PASSWORD festlegen.
In Ansible Tower gibt es jedoch keine entsprechenden Credentials, um diese Daten für ServiceNow anzugeben. Ansible Tower ermöglicht es uns jedoch, , weitere Informationen finden Sie in dem Artikel .
In unserem Fall sieht die Input-Konfiguration für die benutzerdefinierten Credentials 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 Credentials werden als Umgebungsvariablen mit denselben Namen exponiert. Dies wird in der Konfiguration des Injectors beschrieben:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Nun haben wir den benötigten Credential-Typ definiert, können wir das ServiceNow-Konto hinzufügen und die Instanz, den Benutzernamen und das Passwort wie folgt angeben:
Inventar erstellen
Jetzt sind wir bereit, ein Inventar in Ansible Tower zu erstellen. Wir nennen es ServiceNow:
Nach dem Erstellen des Inventars können wir eine Datenquelle anhängen. Hier geben wir das Projekt an, das wir zuvor erstellt haben, und fügen den Pfad zu unserer YAML-Inventar-Datei im Versionsverwaltungssystem ein, in unserem Fall ist das servicenow.yml im Hauptverzeichnis des Projekts. Außerdem müssen wir auch das ServiceNow-Konto verknüpfen.
Um zu überprüfen, ob alles funktioniert, versuchen wir, uns mit der Datenquelle zu synchronisieren, indem wir die Schaltfläche „Alles synchronisieren“ klicken. 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 uns angesehen, wie man in Ansible Tower Inventar-Plugins aus Kollektionen anhand des ServiceNow-Plugins verwendet. Wir haben auch sicher die Anmeldeinformationen für die Verbindung zu unserem ServiceNow-Instanz festgelegt. Die Bindung des Inventar-Plugins aus dem Projekt funktioniert nicht nur mit Drittanbieter- oder benutzerdefinierten Plugins, sondern kann auch zur Modifizierung der Funktionalität einiger Standard-Inventare verwendet werden. Damit lässt sich die Ansible Automation Platform problemlos und nahtlos mit bestehenden Tools zur Automatisierung von IT-Umgebungen integrieren, die immer komplexer werden.
Weitere Informationen zu den in diesem Beitrag behandelten Themen sowie zu anderen Aspekten der Nutzung von Ansible finden Sie hier:
- Blog über .
- .
- Liste unterstützter Red Hat-Kollektionen auf der Automation Hub-Website ().
- .
*Red Hat gibt keine Garantien für die Richtigkeit des hier bereitgestellten Codes. Alle Materialien werden ohne Unterstützung bereitgestellt, es sei denn, dies wurde ausdrücklich anders angegeben.
Quelle: habr.com
