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.
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
Neueste Artikel von Ottavia Balducci (alle ansehen)
- Event-Driven Ansible - 18. Januar 2024
- AWX und GitLab Webhooks - 25. Januar 2023
- Ansible Best Practices - 9. Januar 2023