In seiner einfachsten Form ist ein Inventar eine statische Datei. Dies ist ideal, wenn Sie mit Ansible beginnen. Mit zunehmender Automatisierung wird dies jedoch unzureichend.
Und deshalb:
- Wie kann eine vollständige Liste der überwachten Knoten aktualisiert und auf dem neuesten Stand gehalten werden, wenn sich ständig etwas ändert, wenn Workloads - und danach die Knoten, auf denen sie ausgeführt werden - erscheinen und verschwinden?
- -, ?
Die Antworten auf diese beiden Fragen ergeben ein dynamisches Inventar ( das dynamische Inventar a ) - das Skript oder Plugin, das die Automatisierungseinheiten sein soll und sich auf die Quelle der Wahrheit (Quelle der Wahrheit) bezieht. Darüber hinaus kategorisiert das dynamische Inventar die Knoten automatisch in Gruppen, sodass Sie die Zielsysteme für die Durchführung einer Ansible-Automatisierung genauer auswählen können.
Inventar-Plugins geben dem Ansible-Benutzer die Möglichkeit, auf externe Plattformen zuzugreifen, um Zielknoten dynamisch zu finden und diese Plattformen als Quelle der Wahrheit bei der Erstellung von Inventaren zu verwenden. Die Standard-Quellliste von Ansible enthält die Cloud-Plattformen AWS EC2, Google GCP und Microsoft Azure. Außerdem gibt es viele andere Inventar-Plugins für Ansible.
Ansible Tower wird mit einer Reihe von Inventar-Plugins geliefert, die sofort einsatzbereit sind und zusätzlich zu den oben genannten Cloud-Plattformen die Integration in VMware vCenter, die Red Hat OpenStack-Plattform und Red Hat Satellite ermöglichen. Für diese Plugins reicht es aus, Anmeldeinformationen für die Verbindung zur Zielplattform anzugeben. Anschließend können sie als Quelle für Inventardaten in Ansible Tower verwendet werden.
Zusätzlich zu den mit Ansible Tower gelieferten Standard-Plugins gibt es weitere Inventar-Plugins, die von der Ansible-Community unterstützt werden. Mit der Umstellung auf Red Hat Ansible Content Collections wurden diese Plugins in ihre jeweiligen Sammlungen aufgenommen.
In diesem Beitrag nehmen wir ein Beispiel für die Arbeit mit einem Inventar-Plugin für ServiceNow, eine beliebte IT-Service-Management-Plattform, auf der Kunden häufig Informationen zu allen ihren Geräten in der CMDB speichern. Darüber hinaus kann die CMDB einen für die Automatisierung nützlichen Kontext enthalten, z. B. Informationen zu Serverbesitzern, Service-Levels (Produktion / Nicht-Produktion), installierte Updates und Wartungsfenster. Das Ansible-Inventar-Plugin kann mit der ServiceNow-CMDB zusammenarbeiten und ist Teil der servicenow- Sammlung auf dem galaxy.ansible.com- Portal .
Git-Repository
Um ein Inventar-Plugin aus der Sammlung in Ansible Tower verwenden zu können, muss es als Projektquelle festgelegt werden. In Ansible Tower ist ein Projekt eine Integration in eine Art Versionskontrollsystem wie ein Git-Repository, mit dem nicht nur Automatisierungs-Playbooks, sondern auch Variablen und Inventarlisten synchronisiert werden können.
Unser Repository ist eigentlich sehr einfach:
├── collections
│ └── requirements.yml
└── servicenow.yml
Die Datei servicenow.yml enthält die Details für das Plugin-Inventar. In unserem Fall geben wir einfach die Tabelle in der CMDB ServiceNow an, die wir verwenden möchten. Außerdem legen wir die Felder fest, die als Knotenvariablen hinzugefügt werden, 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: ''
Beachten Sie, dass hiermit nicht die ServiceNow-Instanz angegeben wird, zu der in irgendeiner Weise eine Verbindung hergestellt wird, und keine Anmeldeinformationen für die Verbindung angegeben werden. Wir werden das alles später im Ansible Tower konfigurieren.
Die Datei collection / require.yml wird benötigt, damit Ansible Tower die erforderliche Sammlung herunterladen und somit das erforderliche Inventar-Plugin erhalten kann. Andernfalls müssten wir diese Sammlung manuell auf allen unseren Ansible Tower-Knoten installieren und warten.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Sobald wir diese Konfiguration auf die Quellcodeverwaltung übertragen haben, können wir in Ansible Tower ein Projekt erstellen, das mit dem entsprechenden Repository verknüpft ist. Das folgende Beispiel verknüpft den Ansible Tower mit unserem Github-Repository. Beachten Sie die SCM-URL: Sie können ein Konto registrieren, um eine Verbindung zu einem privaten Repository herzustellen, und einen bestimmten Zweig, ein bestimmtes Tag oder eine bestimmte Verpflichtung zum Auschecken angeben.
Erstellen Sie Anmeldeinformationen für ServiceNow
Wie bereits erwähnt, enthält die Konfiguration in unserem Repository keine Anmeldeinformationen für die Verbindung zu ServiceNow und enthält nicht die ServiceNow-Instanz, mit der wir kommunizieren werden. Um diese Daten festzulegen, erstellen wir daher Anmeldeinformationen im Ansible Tower. Gemäß der Dokumentation des ServiceNow-Inventar-Plugins gibt es eine Reihe von Umgebungsvariablen, mit denen wir beispielsweise die Verbindungsparameter festlegen:
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE
set_via:
env:
- name: SN_USERNAME
In diesem Fall verwendet das Inventar-Plugin die Umgebungsvariable SN_USERNAME als Konto, um eine Verbindung zu ServiceNow herzustellen.
Wir müssen auch die Variablen SN_INSTANCE und SN_PASSWORD setzen.
Ansible Tower verfügt jedoch nicht über Anmeldeinformationen dieses Typs, für die diese Daten für ServiceNow angegeben werden könnten. Mit Ansible Tower können wir jedoch benutzerdefinierte Anmeldeinformationstypen definieren. Weitere Informationen hierzu finden Sie im Artikel "Ansible Tower Feature Spotlight: Benutzerdefinierte Anmeldeinformationen" .
In unserem Fall sieht die Eingabekonfiguration für benutzerdefinierte Anmeldeinformationen für ServiceNow folgendermaßen aus:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Diese Anmeldeinformationen werden als Umgebungsvariablen mit demselben Namen angezeigt. Dies ist in der Injektorkonfiguration beschrieben:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Wir haben also die Art der erforderlichen Anmeldeinformationen definiert. Jetzt können Sie das ServiceNow-Konto hinzufügen und die Instanz, den Benutzernamen und das Kennwort wie folgt festlegen:
Wir erstellen Inventar
Jetzt sind wir alle bereit, ein Inventar in Ansible Tower zu erstellen. Nennen wir 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 geben den Pfad zu unserer YAML-Inventardatei im Quellcodeverwaltungs-Repository ein. In unserem Fall ist es servicenow.yml im Projektstamm. Außerdem muss das ServiceNow-Konto gebunden sein.
Um zu überprüfen, wie alles funktioniert, versuchen wir, eine Synchronisierung mit der Datenquelle durchzuführen, indem Sie auf die Schaltfläche "Alle synchronisieren" klicken. Wenn alles richtig konfiguriert ist, sollten die Knoten in unser Inventar importiert werden:
Bitte beachten Sie, dass die von uns benötigten Gruppen ebenfalls erstellt wurden.
Fazit
In diesem Beitrag haben wir uns am Beispiel des ServiceNow-Plugins mit der Verwendung von Inventar-Plugins aus Sammlungen in Ansible Tower befasst. Wir haben auch Anmeldeinformationen für die Verbindung zu unserer ServiceNow-Instanz gesichert. Das Binden eines Inventar-Plug-Ins aus einem Projekt funktioniert nicht nur mit Plug-Ins von Drittanbietern oder benutzerdefinierten Plug-Ins, sondern kann auch zum Ändern der Arbeit einiger regulärer Inventare verwendet werden. Auf diese Weise kann die Ansible Automation Platform nahtlos in vorhandene Tools integriert werden, um immer komplexere IT-Umgebungen zu automatisieren.
Weitere Informationen zu den in diesem Beitrag behandelten Themen sowie zu anderen Aspekten der Verwendung von Ansible finden Sie hier:
- Blog zur Automatisierung mit ServiceNow Ansible .
- .
- Red Hat Automation Hub (cloud.redhat.com).
- Ansible Automation Platform.
*Red Hat . , .