Verwendung des neuen Constructed Inventory-Features in Ansible Automation Platform 2.4

Das neue Feature „Constructed Inventory“

In diesem Blog stellen wir die Idee einer neuen intelligenteren Art der Inventory-Verwaltung vor, die auf einem von Ansible erstellten Plugin basiert. In Ansible Automation Platform 2.4 wurde dieses Plugin als vollständig unterstütztes Feature eingeführt. In diesem Blog möchten wir Ihnen diese Funktion näherbringen. 

Constructed Inventory ist der Nachfolger des vorhandenen Features Smart Inventory und  wird jetzt als eine weitere Option beim Erstellen eines Inventorys im Ansible Automation Platform-Controller angezeigt. Diese Funktion verwendet eine Liste „normaler“ Inventories als Eingabe, führt benutzerdefinierte Operationen aus, filtert und erzeugt ein resultierendes Inventory mit Inhalten aus den Eingabe-Inventories.

Was ist „Constructed Inventory“?

Diese Funktion ähnelt dem bestehenden Smart Inventory, da Nutzende damit Jobs auf Hosts in mehreren Inventories ausführen können. 

Constructed Inventory bietet jedoch neue Möglichkeiten, einschließlich der integrierten Fähigkeit, sogenannte „hostvars“ und „groupvars“ zu definieren und zu verwenden:

• Gruppen sind im Constructed Inventory vorhanden und spielen eine wichtige Rolle bei der Konfiguration.
• Benutzerdefinierte Logik (zum Hinzufügen von Gruppen und Variablen und zum Herunterwählen von Hosts) wird über ansible-inventory ausgeführt, was der Controller für Sie übernimmt, und in der Benutzeroberfläche im Rahmen einer Inventory-Aktualisierung angezeigt.
• Das Format der benutzerdefinierten Logik ist das weit verbreitete Ansible-ähnliche jinja2.

Als Leitprinzip gilt, dass Sie bei der Erstellung eines Constructed Inventory genauso denken wie beim Generieren eines Playbooks. Im Gegensatz dazu mussten Sie bei Smart Inventory das Inventory aus dem Blickwinkel der Anwendung betrachten.

Constructed Inventory in der Benutzeroberfläche

Nachdem Sie unter Inventories auf „Add constructed inventory“ geklickt haben, wird folgendes Menü angezeigt:

Es gibt 3 Schlüsselelemente, die nur bei Constructed Inventory zu finden sind.

• Unter Input Inventories (Eingabe-Inventories) listen Sie vorhandene Inventories auf, aus denen das Constructed Inventory Inhalte (Hosts, Gruppen usw.) abruft.
• Limit wird direkt an ansible-inventory übergeben und ermöglicht das Filtern der Hosts unter Verwendung der Standardsyntax für Ansible-Hostmuster.
• Source vars ist die Eingabe für das ansible.builtin.constructed Inventory-Plugin.

HINWEIS: Die Eingabe-Inventories sind so angeordnet, dass im Falle von Hostnamens- und Variablenkonflikten die Variablen aus dem letzten Inventory Vorrang haben. Variablen werden zusammengeführt, sodass eine Variable aus einem vorherigen Eingabe-Inventory nicht aufgehoben wird. Bestehen keine Hostnamenskonflikte, spielt dies keine Rolle. Daher wird in dem hier verwendeten Beispiel die Reihenfolge erwähnt.

Dies wird im Folgenden anhand eines Beispiels erläutert.

Constructed Inventory in seiner einfachsten Form

Sie müssen mindestens ein Eingabe-Inventory verwenden, die anderen Felder müssen jedoch nicht ausgefüllt werden. Manchmal kann es sinnvoll sein, 2 oder mehr Eingabe-Inventories bereitzustellen und die Felder „Limit“ und „Source vars“ leer zu lassen. Anschließend können Sie Jobs ausführen, die eine Kombination des Inventory-Inhalts aus beiden Eingabe-Inventories verarbeiten. 

Fortgeschrittene Use Cases für Constructed Inventories

Um die Funktion von Limit und Source vars zu erläutern, die die ultimative Funktionsfähigkeit bieten, ist ein konkretes Beispiel hilfreich.

Einrichten des Constructed Inventory

Stellen Sie sich vor, Sie verfügen über 2 Inventories, die vom selben Cloud-Anbieter stammen, aber unterschiedliche Regionen abdecken und daher unterschiedliche Hosts enthalten. Diese Inventories werden aufgrund separater Accounts, Funktionen und Standorte separat geführt. In diesem Beispiel stellen wir uns einfache Eingabe-Inventories der Region East/West vor.

Wir beziehen die Inventories aus Git-basierten .ini-Dateien, die wir mit einem Config as Code-Ansatz unter Verwendung von DevOps-Praktiken verwalten.

Richten Sie zunächst ein neues Projekt ein und synchronisieren Sie es, damit wir wissen, woher die Informationen zum Inventory stammen. Wählen Sie Projects in der Benutzeroberfläche aus, und klicken Sie auf Add:

Nach dem Ausfüllen und Speichern wird das Projekt automatisch synchronisiert:

Jetzt erstellen wir die neuen Inventories, die auf die Informationen aus den Projektdateien verweisen. Klicken Sie unter „Inventories“ auf „Create“:

Klicken Sie dann im gewünschten Inventory auf Sources und anschließend auf Add:

Geben Sie unter Name einen Namen für diese Quelle ein, in diesem Fall für die Hosts der Region East. Wählen Sie unter Source die Option Sourced from a Project aus, und stellen das gerade hinzugefügte Projekt und die entsprechende east.ini-Quelldatei bereit:

Klicken Sie nach dem Speichern auf Sync, um die Informationen zu synchronisieren:

Nach der Synchronisierung können Sie in der Jobausgabe sehen, was verarbeitet wurde:

In diesem Fall sehen Sie, dass 3 Hosts und 3 Gruppen erkannt und automatisch hinzugefügt wurden. Diese Informationen werden in der Benutzeroberfläche unter Hosts angezeigt.

Jetzt müssen wir denselben Vorgang für die Region West vornehmen. Sie können diese Übung nach dem obigen Beispiel ausführen, aber unter Verwendung der Informationen zu west.ini als Quelle.

Für dieses hypothetische Szenario möchten wir Jobs für einige der Hosts aus den Regionen East und West gleichzeitig auf Grundlage der von uns definierten Kriterien ausführen.

Erstellen wir nun ein neues Constructed Inventory in der Benutzeroberfläche:

Wir fügen beide Cloud Inventories als Eingaben hinzu. Anschließend verwenden wir source-vars, um eine neue Gruppe „target_group“ zu erstellen, und verwenden dann Limit als Filter für diese Gruppe:

Nach der Synchronisierung können Sie in der Jobausgabe sehen, was geschieht:

Wir haben jetzt 4 Gruppen mit 4 Hosts, die Sie unter Hosts und Groups in der UI durchsuchen können, um das Ergebnis zu bestätigen. Sehen wir uns die Gruppen für dieses spezielle Beispiel an:

Bei der Aktualisierung des Constructed Inventory wurden die Gruppen „account_1234“, „account_4321“ und „accounts“ aus den Eingabe-Inventories in das resultierende Constructed Inventory kopiert. 

Außerdem sehen wir, dass das Constructed Inventory auch die Gruppe „target_group“ enthält, über die wir in Kürze sprechen.

Wenn dieses Constructed Inventory von einem Job-Template zum Ausführen eines Jobs verwendet werden würde, könnten alle definierten Gruppen vom Job verwendet werden.

Jetzt können Sie, wenn Sie im Constructed Inventory-Formular auf source-vars verweisen, die Definition der neuen Gruppe „target_group“ finden.

    plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

Die Gruppe „target_group“ war in den ursprünglichen Inventories für die Regionen East und West nicht vorhanden. Sie wurde durch das Constructed Inventory-Plugin erstellt, als die Aktualisierung erfolgte. 

In diesem Fall werden Hosts der Gruppe hinzugefügt, wenn das jinja2-Template {{ account_alias | default("") == "product_dev" }} für einen bestimmten Host einen wahrheitsgemäßen Wert (wie 1, „1“ oder True) ergibt. 

Während der Aktualisierung werden diese Templates von Ansible für jeden Host in den Eingabe-Inventories gerendert, um diese Auswertungen vorzunehmen. Bei größeren Eingabe-Inventories kann davon ausgegangen werden, dass die Aktualisierung innerhalb von Minuten erfolgt. 

Constructed Inventories werden automatisch aktualisiert, bevor ein Template ausgeführt wird, das sie verwendet. Wenn diese Aktualisierungen jedoch zu lange dauern, können Sie die Häufigkeit der Aktualisierungen mit der Option Update cache timeout in den Einstellungen für Constructed Inventories in der Benutzeroberfläche ändern. Wenn Sie diese Option auf einen Wert > 1 setzen, werden die Ergebnisse der Aktualisierung des Constructed Inventory für diese Anzahl von Sekunden zwischengespeichert.

Das Jinja2-Template zur Erstellung der Gruppe „target_group“ enthält einen Host, wenn bei der Überprüfung dieses Hosts die Hostvariable von „account_alias“ vorhanden ist und gleich „product_dev“ ist. 

Die „| default“-Syntax ist erforderlich für den Fall, dass die Variable für manche Hosts nicht definiert ist. 

„strict: true“ schreibt vor, dass bei einem Verweis auf eine nicht definierte Variable die Inventory-Aktualisierung fehlschlägt, sodass der Befehl „| default“ erforderlich ist. 

Die Verwendung von „|default|“ und dem strict-Parameter ist die beste Methode, um den undefinierten Fall eindeutig zu machen.

Das Erstellen von Gruppen kann nützlich sein, um Gruppen spontan hinzuzufügen, auf die in Playbooks verwiesen werden soll. Warum sollten Sie das tun? Manchmal ist es praktisch, Gruppen aus hostvars zu synthetisieren, weil Sie mit Gruppen Aktionen ausführen können, die mit hostvars nicht möglich sind, wie die Verwendung von Hostmustern, wie mit Limit in diesem Beispiel. 

Sehen Sie sich alle erzeugten Hosts für unser Constructed Inventory an:

Dieses Beispiel zeigt, dass host3 im Inventory East und host5 im Inventory West nicht enthalten sind. Das liegt daran, dass sie sich in den Eingabe-Inventories in einem anderen Account („account_43210“) befinden, das einen „account_alias“ aufweist, der nicht mit dem angegebenen Wert für „product_dev“ übereinstimmt. Beachten Sie, dass trotz des Imports der Gruppe für „account_4321“ in das Constructed Inventory keine Hosts in dieser Gruppe unserer Anforderung entsprachen. Daher ist die importierte Gruppe in unserem Constructed Inventory leer.

Im Feld „Source vars“ können Sie host-Variablen eingeben und Gruppen hinzufügen.

Alans GitHub-Repository enthält außerdem ein weiteres, nützliches Beispiel. In construct.yml lösen wir den „Zustand“ eines Hosts auf und weisen ihn einer Reihe von Gruppen zu, je nachdem, ob er heruntergefahren oder Teil einer bestimmten Umgebung (dev) ist. Die Source of Truth für diese .yml-Datei kann von anderen Systemen außerhalb von Ansible Automation Platform stammen, und wir können sie verwenden, um Automatisierungsläufe für Teilmengen von Hosts sofort durchzuführen.

Tipps für das Debugging

Um das vorherige Beispiel zu verwenden, sollten Sie bei der Entwicklung des Constructed Inventory den Wert im Feld „Limit“ löschen und die source-vars wie folgt ändern.

Dadurch wird ein ähnliches Template wie {{ account_alias | default(“”) }} ausgeführt und in einer Variablen namens „effective_account_alias“ gespeichert. Wenn Sie Limit leer lassen, stellen Sie sicher, dass alle Hosts aus den Eingabe-Inventories abgerufen werden. So könnten wir sehr granulare Details der Inklusionskriterien auf einzelnen Hosts prüfen, die unten für „host3“ angezeigt werden.

Hier sehen wir, dass der bewertete Wert von hostvar „effective_account_alias“ als „sustaining“ und nicht als „product_dev“ eingestuft wurde. 

Das Constructed Inventory-Plugin verfügt über eine Reihe weiterer nützlicher und leistungsstarker Optionen. Weitere Details finden Sie in der Plugin-Dokumentation unter https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html.

Einige weitere Beispiele finden Sie auch im User Guide unter https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed.

Zusammenfassung:

Wir hoffen, dass Ihnen hier ein Bild von der praktischen Nutzung des Features „Constructed Inventory“ in Ansible Automation Platform vermittelt wurde. 

Da die zugrunde liegenden Konzepte wie das Hostmuster und das Constructed Inventory-Plugin allgemeine Ansible-Konzepte sind, können Nutzende Gruppen oder Variablen hinzufügen oder Hosts auf Grundlage beliebig komplexer Kriterien einbeziehen.

Zu den Vorteilen zählen:

• Die Möglichkeit, Gruppen dynamisch aus mehreren Sources of Truth zu erstellen.
• Die Möglichkeit, Hosts aus mehreren Inventories herauszufiltern, zu analysieren und zu beschränken, wobei sie jedoch in Automatisierungsläufen verwendet werden können.
• Die Möglichkeit, beim Filtern vordefinierte hostvars zu verwenden.
• Mehrere Teams können über ihr eigenes Inventory und eigene Metadaten verfügen, die mit ihren Hosts verknüpft sind, und diese können zentral über Ansible Automation Platform verwendet werden.