Was ist ein Ansible Rulebook?

Ein Ansible® Rulebook ist ein Satz bedingter Regeln, die in Event-Driven Ansible verwendet werden, um IT-Aktionen in einem eventgesteuerten Automatisierungsmodell durchzuführen. Mit Rulebooks weisen Nutzende Event-Driven Ansible an, welche Quelle auf ein Event überwacht werden soll und was bei Eintritt des Events zu tun ist, wenn bestimmte Bedingungen erfüllt sind.

Rulebooks werden genau wie Ansible Playbooks in für Menschen lesbarem YAML geschrieben, verwenden jedoch bedingte „wenn-dann“-Regeln, um zu definieren, wann ein Event eine Aktion auslösen soll. Gemäß den Anweisungen eines Rulebooks überwacht Event-Driven Ansible die Zielquelle für das Event, erkennt den Eintritt, und führt automatisch die zugehörige Aktion aus. 

Mit Ansible Rulebooks können IT-Teams die Entscheidungen kodifizieren, die sie treffen wollen, und unter bestimmten Bedingungen auszuführende Aktionen entwerfen, sodass die Ausführung immer auf die gleiche Weise erfolgt. Rulebooks können auch bestehende Ansible Playbooks initiieren, wenn bestimmte Bedingungen erfüllt sind. So wird der Wert der bewährten Playbooks erhöht, die von den Teams im Laufe der Zeit erstellt und verbessert werden. 

Indem sie ihr Wissen in Rulebooks bündeln, können Teams mit Event-Driven Ansible Fehler minimieren, die ermüdete Mitarbeiter bei der Ausführung sich wiederholender Aufgaben machen, und effizientere, konsistentere IT-Prozesse entwickeln.

Event-Driven Ansible bietet die notwendigen Event Handling-Funktionen, um zeitaufwendige Aufgaben zu automatisieren und auf veränderte Bedingungen in beliebigen IT-Domains zu reagieren. Event-Driven Ansible kann Events, die diskrete Informationen über die Bedingungen in der IT-Umgebung enthalten, verarbeiten, die geeignete Reaktion auf das Event bestimmen und anschließend automatisierte Aktionen zur Lösung oder Problembehebung des Events durchführen. Mit Event-Driven Ansible lassen sich Aufgaben für das IT-Servicemanagement , wie Ticket-Erweiterung, Problembehebung und Benutzerverwaltung, sowie eine Vielzahl weiterer Aufgaben in einer IT-Umgebung automatisieren.

Ihr Beobachtbarkeits-Tool – die Event-Quelle – entdeckt beispielsweise bei der Überwachung von Netzwerk-Routern, dass ein Router nicht reagiert, und erkennt dies als ein Event. Event-Driven Ansible empfängt dieses Ereignis, prüft die Event-Daten gegen die Bedingungen im Rulebook und ordnet das Event der gewünschten Aktion zu, wie dem erneuten Anwenden einer Konfiguration, dem Zurücksetzen des Routers, dem Erstellen eines Servicetickets oder dem Umleiten des Datenverkehrs. Den Anweisungen des Rulebooks folgend, kann Event-Driven Ansible die Aktion zum Zurücksetzen des Routers auslösen und so die normale Funktion wiederherstellen. Ein solcher automatischer Vorgang kann jederzeit ausgeführt werden, selbst mitten in der Nacht, ohne dass jemand vom Netzwerk Engineering-Team geweckt werden muss.

Die Flexibilität von Event-Driven Ansible wird durch Ansible Rulebooks ermöglicht, die Quellen von Events durch Regelnmit zugehörigen Aktionen verbinden.

Die Ansible Rulebooks enthalten die Quelle des Events und bedingte Anweisungen – die Regeln, die angeben, welche Aktionen ausgeführt werden sollen, wenn eine bestimmte Bedingung erfüllt ist. Eine Regel enthält eine einzelne Bedingung und die zugehörige Aktion. Ein Ruleset ist eine Gruppe von mehreren Regeln und Aktionen. Rulebooks können mehrere Rulesets umfassen.

Rulebooks sind flexibel ausgelegt. Sie können:

• Eine oder mehrere Quellen überwachen. 
• Eine oder mehrere Regeln beinhalten.
• Eine oder mehrere Aktionen auslösen. 

Diese Flexibilität von Quellen, Regeln und Aktionen ist in Event-Driven Ansible integriert. Dadurch können Nutzende die bei Vorlage bestimmter IT-Bedingungen gewünschten Aktionen festlegen.

Der erste Teil eines Rulebooks definiert die Quelle(n), die Sie auf Events überwachen wollen. Event-Driven Ansible stützt sich auf intelligente Event-Quellen wie externe Beobachtungstools und Anwendungen, um Ereignisse zu identifizieren und Daten über sie zu erfassen. Event Source Plugins werden verwendet, um Event-Driven Ansible mit diesen Quellen zu verbinden und auf Events zu warten. 

Die ansible.eda Red Hat® Ansible Certified Content Collection enthält eine Reihe vorgefertigter Event Source Plugins, die für den Einstieg in Event-Driven Ansible verwendet werden können. Red Hat empfiehlt Partnern und Anbietern jedoch die Bereitstellung von Plugins, die speziell für ihre Technologie entwickelt wurden, um den Integrationsprozess zu vereinfachen und eine bessere Nutzung der Event-Daten zu ermöglichen.

Plugins zertifizierter Ansible.eda Inhalte

Durch Verwendung von Event Source Plugins aus der Collection ansible.eda können Nutzende schnell mit der Verarbeitung von Events beginnen. Diese Quell-Plugins ermöglichen es Event-Driven Ansible, Events zu erfassen, die dann mit der bedingten Logik eines Rulebooks verarbeitet werden, um zu bestimmen, welche Aktion ausgeführt werden soll. Erfüllt ein Event nicht die Bedingungen des Rulebooks, löst Event-Driven Ansible keine Aktion aus und das Event wird verworfen. 

Einige der in der Collection ansible.eda enthaltenen Quell-Plugins sind Webhooks, Kafka und Prometheus Alertmanager. Diese sind für allgemeine Webhooks, die von verschiedenen Systemen und Tools stammen können, für Nachrichtenwarteschlangen und für Warnmeldungen von Event Monitoring-Systemen in Unternehmen wie Prometheus geeignet. 

Zusätzlich zu diesen Plugins bieten Partner von Red Hat weitere zertifizierte Event Source Plugins an, die speziell auf ihre Technologien und Lösungen zugeschnitten sind. Diese Plugins können zusätzliche Funktionen für Event-Driven Ansible zur Verbesserung der Zusammenarbeit mit diesen Partnertechnologien enthalten. Nutzende haben die Möglichkeit zur Entwicklung ihrer eigenen Quell-Plugins für selbst erstellte Event-Quellen.

Haben Sie beispielsweise einen Netzwerk-Switch und wollen nur wissen, wenn ein Port ausfällt, kann ein Partner ein Plugin erstellen, das genau angibt, worauf Event-Driven Ansible auf dem Switch achten soll. Bei Verwendung dieses Partner-Plugins werden Sie nicht rund um die Uhr mit irrelevanten Informationen über alles, was mit dem Switch passiert, überschüttet. Das zertifizierte Plugin liefert beispielsweise nur den Hostnamen des Geräts, das Problem und eine Vorfallsnummer. Ein generisches Plugin liefert dagegen wie ein Webhook zusätzliche Details, wie etwa den Namen des Absenders, die URL oder andere Daten, die für die Fehlerbehebung nicht relevant sind.

Sobald ein Quell-Plugin ein Event erkannt und Informationen darüber geliefert hat, filtert Event-Driven Ansible diese Daten durch die bedingten Regeln des Rulebooks, um die durchzuführenden Aktionen zu bestimmen. Regeln sind flexible „wenn-dann“-Szenarien, die festlegen, welche Schritte ausgeführt werden sollen, wenn Event-Daten bestimmte Bedingungen erfüllen. 

Überwacht das Quell-Plugin beispielsweise die Ports eines Netzwerk-Routers, könnten die Regeln lauten: Fällt der Port aus und ist 5 Minuten lang nicht verfügbar, muss der Router neu gestartet werden. Werden die Event-Daten gemäß den Regeln geprüft und erfüllen die Bedingungen nicht, werden keine Aktionen ausgeführt. 

Rulebooks können:

• eine oder mehrere Regeln enthalten 
• eine Bedingung, oder mehrere Bedingungen, die mit dem Event-Status übereinstimmen müssen, oder mehrere Bedingungen, von denen nur eine übereinstimmen muss, enthalten 
• die traditionellen mathematischen Operatoren, wie =, ≠, > und unterstützen
• Unterstützt werden die Datentypen Ganzzahlen, Zeichenketten, Booleans (wie and, or, und not), Floats und Nullbedingungen. 

Betrachten Sie beispielsweise ein einzelnes Event und versuchen, mehrere Bedingungen zu erfüllen, können Sie das Boolean andverwenden. Dies bedeutet, dass vor dem Auslösen der Aktion jede dieser Bedingungen erfüllt sein muss.

name: Combining ‘and’ operators condition: event.version == "2.0" and event.name == "test" and event.alert_count > 10 action:   debug:

Überwachen Sie mehrere Events und versuchen, mehrere Bedingungen zu erfüllen, können Sie allverwenden. Dies bedeutet, dass jede der Bedingungen erfüllt sein muss, bevor eine Übereinstimmung als gegeben gilt. Da diese Bedingungen mit mehreren Events verbunden sind, werden sie in separaten Zeilen aufgeführt.

name: Condition using both a fact and an event condition:   all:     - fact.meta.hosts == "localhost"     - event.target_os == "windows" action:   debug:

Bei der Verwendung von anygilt die Bedingung als erfüllt, und die Aktion wird ausgelöst, wenn eine der Bedingungen erfüllt ist. Wie im obigen Beispiel werden auch hier mehrere Events betrachtet, sodass die Bedingungen in separaten Zeilen aufgeführt sind.

name: Any condition can match condition:   any:     - event.target_os == "linux"     - event.target_os == "windows" action:   debug:

Hinweis: In den obigen Beispielen würde die Aktion Debug die Event-Informationen ausgeben, sodass Ihnen diese Daten in Event-Driven Ansible angezeigt werden.

Erfüllen Event-Daten die Bedingungen eines Rulebooks, löst Event-Driven Ansible die festgelegte Aktion oder Aktionen aus. 

Zu den gängigen Aktionen gehören:

• Run_playbook führt ein vorhandenes Ansible-Playbook aus, das Sie bereits zur Automatisierung bestimmter Aktionen, wie der Fehlerbehebung bei einem Server, erstellt haben. 
• Run_job_template führt ein Job Template über den Automation Controller in Red Hat Ansible Automation Platform aus. Da Sie das Template innerhalb von Ansible Automation Platform ausführen, nutzen Sie die damit verbundenen Vorteile wie Inventory Management, Nutzenden- und Zugriffskontrollen und Analysen zur abgeschlossenen Aktion. 
• Run_module startet ein vorhandenes Ansible-Modul, das eine spezifischere, gezielte Aktion ausführt, wenn Sie nicht ein komplettes Playbook ausführen möchten.
• Post_event erlaubt die Aufnahme eines Events in ein laufendes Ruleset. Dies wird in der Regel nach der Aktion run_playbook oder run_job_template eingefügt und bietet die Möglichkeit, Informationen zum Ergebnis der Aktion zurück in Event-Driven Ansible zu übertragen.
• Set_fact zeichnet spezifische Daten über ein Event oder eine Aktion auf, sodass sie in Event-Driven Ansible zurückgeführt und für andere Aktionen verwendet werden können. Event-Daten sind flüchtige, transiente Daten. Mit der Einstellung von Fakten können Sie bestimmte Informationen über Events speichern und diese Daten persistent machen.
• Debug ist vergleichbar mit dem Debug in Ansible Playbooks. Werden keine Argumente angegeben, werden das entsprechende Event Payload und zusätzliche wichtige Informationen ausgegeben.

Dieser Abschnitt enthält einige einfache Beispiele für Ansible Rulebooks. Wenn Sie sich nicht alle Einzelheiten merken können, ist das kein Problem. Diese Beispiele sollen Ihnen eine grundlegende Vorstellung davon vermitteln, wie Quellen, Regeln und Aktionen im Rahmen eines vollständigen Rulebooks zusammenwirken. 

In diesem ersten Beispiel geht es um eine relativ einfache, einzelne Aktion. Mit folgendem Code führt Event-Driven Ansible bei einem Ausfall in der Event-Quelle ein Remediation Playbook aus.

rules:   - name: An automatic remediation rule     condition: event.outage == true     action:       run_playbook:         name: remediate_outage.yml

Im folgenden Beispiel für ein etwas komplizierteres Rulebook definieren wir die Event-Quelle als das Dynatrace Certified Source Plugin. Die Regeln definieren Bedingungen, auf die wir achten. In diesem Fall geben sie bestimmte Nutzungsbedingungen für Anwendungen und Hardware an.

--- - name: Listen for events on a webhook   hosts: all   sources:     - dynatrace.eda.dt_esa_api:         dt_api_host: "https://abc.live.dynatrace.com"         dt_api_token: "asjfsjkfjfjh"         delay: 60    Rules:     - name: Problem payload Dynatrace for CPU issue       condition: event.payload.problemTitle contains "CPU saturation"       action:         run_job_template:           name: "Remediate CPU saturation issue"           organization: "Default"     - name: Problem payload Dynatrace for App Failure rate increase issue       condition: event.payload.problemTitle contains "Failure rate increase"       action:         run_job_template:           name: "Remediate Application issue"           organization: "Default"     - name: Update comments in Dynatrace       condition:          all:            - event.status == "OPEN"       action:         run_playbook:           name: dt-update-comments.yml

Die empfangene Event Payload wird auf die Meldungen „CPU saturation“ oder „Failure rate increase“ überprüft. Sind diese Meldungen im Payload enthalten, ordnet Event-Driven Ansible diese Events Remediation Playbooks oder Job Templates zu, um das Problem zu beheben.

Red Hat Ansible Automation Platform verwendet für Menschen lesbares YAML, damit Nutzende Automatisierungsinhalte gemeinsam nutzen, überprüfen und verwalten können. Sie enthält die für die Implementierung einer unternehmensweiten Automatisierung erforderlichen Tools, einschließlich Event-Driven Ansible, Playbooks und Analysen. Zudem können Ihre Teams zur Verringerung der operativen Komplexität die IT-Infrastruktur mit einem visuellen Dashboard, Role-based Access Control und weiteren Funktionen zentralisieren und kontrollieren.

Mit einer Red Hat Subskription erhalten Sie zertifizierte Inhalte von unserem robusten Partnernetzwerk, Zugriff auf gehostete Managementservices und technischen Lifecycle-Support zur Skalierung der Automatisierung im gesamten Unternehmen. Außerdem profitieren Sie von unserem Fachwissen, das wir bei unserer erfolgreichen Zusammenarbeit mit Tausenden von Kunden entwickelt haben.

Die Einführung von Red Hat Ansible Lightspeed with IBM watsonx Code Assistant macht Ansible auch für Einsteiger ohne Vorkenntnisse leichter zugänglich und hilft erfahrenen Ansible-Entwicklerinnen und -Entwicklern, produktiver, effizienter und fehlerfreier zu arbeiten. Bei der Entwicklung kann eine Anfrage in einfachem Englisch eingegeben werden, und Ansible Lightspeed interagiert mit IBM watsonx Basismodellen, um Code-Empfehlungen zu generieren, die zur Erstellung von Ansible Playbooks verwendet werden.