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
