51 Einstieg in Event-Driven Ansible (EDA)

51.1 Ziel

Teilnehmer sollen nach diesem Abschnitt in der Lage sein:

• den Grundgedanken von Event-Driven Ansible zu verstehen
• ein einfaches Rulebook mit Webhook-Quelle auszuführen
• Events gezielt per curl auszulösen
• den Ablauf von Event -> Rule -> Action nachzuvollziehen

51.2 Überblick

Event-Driven Ansible (EDA) erweitert das klassische Ansible-Modell um reaktive Eventverarbeitung. Statt Playbooks manuell auszuführen, werden diese durch externe Ereignisse ausgelöst (z. B. Webhooks, Kafka, Redis).

Ablaufmodell:

• Event trifft ein (z. B. HTTP-POST)
• Rulebook wertet Bedingung aus
• Aktion wird ausgeführt (z. B. run_playbook)

51.3 Verzeichnisstruktur für Minimalbeispiel

eda-demo/
├── rulebook.yml
├── playbooks/
│   └── hello.yml
└── inventory.yml

51.4 Beispiel: Einfaches Webhook-Rulebook

rulebook.yml

- name: Webhook-Demo
  hosts: localhost
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
        endpoint: /event
  rules:
    - name: Event empfangen und reagieren
      condition: event.payload.message is defined
      action:
        run_playbook:
          name: playbooks/hello.yml
          extra_vars:
            eingang: "{{ event.payload.message }}"

playbooks/hello.yml

- name: Dummy-Playbook
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Nachricht ausgeben
      debug:
        msg: "Webhook sagte: {{ eingang }}"

inventory.yml

all:
  hosts:
    localhost:
      ansible_connection: local

51.5 Starten des Event-Listeners

ansible-rulebook \
  --rulebook rulebook.yml \
  --inventory inventory.yml \
  --verbose

51.6 Test: Event senden per curl

curl -X POST http://localhost:5000/event \
  -H 'Content-Type: application/json' \
  -d '{"message": "Hallo Schulungsteilnehmer"}'

Erwartung:

• Playbook wird automatisch ausgeführt
• Ausgabe: “Webhook sagte: Hallo Schulungsteilnehmer”

51.7 Optional: Betrieb per systemd

/etc/systemd/system/ansible-eda.service

[Unit]
Description=EDA Listener
After=network.target

[Service]
ExecStart=/usr/local/bin/ansible-rulebook \
  --rulebook /opt/eda-demo/rulebook.yml \
  --inventory /opt/eda-demo/inventory.yml
WorkingDirectory=/opt/eda-demo
Restart=always

[Install]
WantedBy=multi-user.target

51.8 Beispiel: Reaktion auf Dateiänderung

Ziel: Reagieren auf Änderungen einer Konfigurationsdatei und entsprechendes Playbook ausführen.

rulebook.yml

- name: File-Watcher
  hosts: localhost
  sources:
    - ansible.eda.file:
        path: /tmp/demo.conf
        ignore_initial: true
  rules:
    - name: Datei wurde geändert
      condition: event.payload.src_path.endswith("demo.conf")
      action:
        run_playbook:
          name: playbooks/on_file_change.yml
          extra_vars:
            changed_file: "{{ event.payload.src_path }}"

playbooks/on_file_change.yml

- name: Reaktion auf Dateiänderung
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Ausgabe der geänderten Datei
      debug:
        msg: "Geänderte Datei: {{ changed_file }}"

Test:

echo "Änderung $(date)" >> /tmp/demo.conf

Erwartung:

• Regel löst aus
• Playbook wird automatisch gestartet
• Pfad zur Datei wird ausgegeben

51.9 Weitere Eventquellen und Anwendungsfälle

Neben webhook und file bietet EDA weitere Eventquellen. Hier eine Übersicht der unterstützten Plugins mit typischen Szenarien:

51.9.1 Kafka (Streaming)

sources:
  - ansible.eda.kafka:
      host: kafka.example.com
      port: 9092
      topic: system-events
      group_id: eda-group

Use Case: Infrastrukturereignisse in Echtzeit (z. B. Security Alerts, Service-Status)

51.9.2 Redis (Pub/Sub)

sources:
  - ansible.eda.redis:
      host: redis.example.com
      port: 6379
      channels:
        - alerts

Use Case: Push-Nachrichten aus SIEM-Systemen oder Zwischenpuffern

51.9.3 Prometheus Alertmanager

sources:
  - ansible.eda.webhook:
      host: 0.0.0.0
      port: 9093
      endpoint: /alertmanager

Use Case: Automatisierte Reaktionen auf Metrik-basierte Alerts

51.9.4 Dateiüberwachung

Bereits gezeigt, aber auch geeignet für:

• Config Drift Detection
• Triggern von Compliance Audits

51.9.5 Weitere Quellen (experimentell oder in Entwicklung)

• Azure Events / AWS SNS (über externe Konnektoren)
• Custom Python-Plugins (eigene Eventsource)
• Timer-Events (z. B. alle X Sekunden)

51.9.6 Aktionen (Actions)

Neben run_playbook sind weitere Aktionen möglich:

• print_event: Debug-Ausgabe
• set_fact: Eventdaten zwischenspeichern
• shutdown: Prozess gezielt beenden
• run_module: Direktmodul ohne Playbook (z. B. ping)

Diese lassen sich beliebig kombinieren, filtern und verschachteln.

Damit ist EDA nicht nur ein Event-Trigger, sondern eine generische Entscheidungs- und Automatisierungslogik – eingebettet in die bestehende Ansible-Umgebung.