Event-Driven Ansible

Event-Driven Ansible ist da und es eröffnet eine ganz neue Welt von Möglichkeiten für die Arbeit mit Ansible. Dieser Artikel gibt eine Einführung in das Thema und zeigt ein minimales Beispiel.

✉️ Immer einen Schritt voraus – mit unserem Newsletter!

Mit unserem Newsletter erhalten Sie regelmäßig Informationen zu aktuellen IT-Themen und Open-Source-Lösungen – kompakt und relevant.
👉 Jetzt kostenlos anmelden

Was ist Event-Driven Ansible?

Event-Driven Ansible ist eine neue Art der Arbeit mit Ansible, die auf Ereignissen basiert. Wenn ein bestimmtes Ereignis eintritt, wird eine entsprechende Aktion ausgelöst. Dies ermöglicht eine sofortige und automatisierte Reaktion auf Probleme oder unerwartete Ereignisse. Es ist derzeit als Developer Preview verfügbar.

Wie es funktioniert

Die Informationen darüber, welche Ereignisse überwacht und welche Maßnahmen ergriffen werden sollen, sind in einem so genannten „Ansible Rulebook“ enthalten.

sources

Dies ist eine Liste möglicher Quellen, aus denen Ereignisse gesammelt werden können. Im Moment sind bereits einige Quellen verfügbar. Zum Beispiel bietet das webhook-Quellen-Plugin einen Webhook, der von jeder Anwendung ausgelöst werden kann. Das kafka-Plugin ermöglicht den Empfang von Ereignissen über ein Kafka-Topic. Die aktuelle Liste der unterstützten Quellen finden Sie hier.

rules

Regeln beschreiben, welche Aktionen in Abhängigkeit von bestimmten Ereignissen durchgeführt werden sollen. Einige der möglichen Aktionen sind: run_playbook, run_job_template, run_workflow_template, und viele mehr. Eine vollständige Liste finden Sie hier.

Ein Rulebook wird mit dem CLI-Tool ansible-rulebook gestartet, das über pip verfügbar ist. Alternativ besteht für Kunden der Ansible Automation Platform auch die Möglichkeit, den EDA-Controller zu installieren: eine Web-UI für Event-Driven Ansible.

Beispiel

Schauen wir uns ein minimales Beispiel an, das zeigt, wie Event-Driven Ansible funktioniert. Wir stellen uns eine Situation vor, in der wir einen Webserver laufen haben und ihn überwachen wollen. Das können wir mit dem folgenden Rulebook tun:

# check_url_rulebook.yml
---
- name: Check webserver
  hosts: all
  sources:
    - ansible.eda.url_check:
        urls:
          - https://< webserver_fqdn >
        delay: 10
  rules:
    - name: Restart Nginx
      condition: event.url_check.status == "down"
      action:
        run_playbook:
          name: atix.eda.restart_nginx

Dieses Rulebook verwendet das url_check-Plugin, um die Webseite https://< webserver_fqdn > alle 10 Sekunden abzufragen. Es gibt nur eine Regel. Wenn der URL-Check den Status down liefert, wird automatisch ein Ansible-Playbook gestartet. In diesem Fall ist das gestartete Playbook unter einer privaten Sammlung, atix.eda, installiert und versucht einfach, den nginx-Dienst neu zu starten:

# restart_nginx.yml
---
- hosts: all
  gather_facts: false
  tasks:
    - name: Restart Nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
      become: true

Wir können die Überwachung des Webservers mit diesem Befehl starten:

ansible-rulebook --rulebook check_url_rulebook.yml -i inventory.yml --verbose

Beachten Sie, dass wir auch eine Inventardatei, inventory.yml, übergeben müssen, die die Hosts enthält, die vom atix.eda.restart_nginx-Playbook adressiert werden sollen. In diesem Fall enthält das Inventar nur einen Host, nämlich den Webserver.

Der obige Befehl wird im Vordergrund ausgeführt und wartet auf Ereignisse.

Wenn er noch kein Ereignis erhalten hat, sieht die Ausgabe wie folgt aus:

2023-11-29 13:53:07,183 - ansible_rulebook.rule_set_runner - INFO - Waiting for actions on events from Check url
2023-11-29 13:53:07 183 [drools-async-evaluator-thread] INFO org.drools.ansible.rulebook.integration.api.io.RuleExecutorChannel - Async channel connected
2023-11-29 13:53:07,184 - ansible_rulebook.rule_set_runner - INFO - Waiting for events, ruleset: Check url

Wenn wir nun den Webserver von Hand anhalten, sehen wir zunächst, dass das Ereignis registriert ist:

2023-11-29 13:54:37 407 [main] INFO org.drools.ansible.rulebook.integration.api.rulesengine.RegisterOnlyAgendaFilter - Activation of effective rule "Restart Nginx" with facts: {m={url_check={url=https://< webserver_fqdn >, status=down, error_msg=Cannot connect to host  ssl:default [Connect call failed ('', 443)]}, meta={source={name=ansible.eda.url_check, type=ansible.eda.url_check}, received_at=2023-11-29T13:54:37.366718Z, uuid=709d45b8-803a-48e2-ad17-99d993c6e957}}}
2023-11-29 13:54:37,419 - ansible_rulebook.rule_generator - INFO - calling Restart Nginx

und dann das entsprechende Playbook gestartet wird:

2023-11-29 13:54:37,423 - ansible_rulebook.action.run_playbook - INFO - ruleset: Check url, rule: Restart Nginx
2023-11-29 13:54:38,425 - ansible_rulebook.action.run_playbook - INFO - Calling Ansible runner

PLAY [all] *********************************************************************

TASK [Restart Nginx] ***********************************************************
changed: []

PLAY RECAP *********************************************************************
         : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
2023-11-29 13:54:44,628 - ansible_rulebook.action.runner - INFO - Ansible runner Queue task cancelled

Fazit

Event-Driven Ansible hat das Potenzial, die Art und Weise, wie mit Problemen umgegangen wird, zu revolutionieren. Das Projekt befindet sich noch in der Anfangsphase. Hoffen wir, dass in den kommenden Monaten neue spannende Event-Sources-Plugins hinzukommen.

Ottavia Balducci

+ posts