Zum Hauptinhalt springen

Ansible Scripting-Leitfaden

Run Ansible playbooks on managed devices using Level's scripting engine, with setup instructions for Unix and Windows endpoints.

Einführung

Level kann Ansible-Playbooks auf verwalteten Geräten über seine Scripting-Engine ausführen. Der wesentliche Unterschied zu einem typischen Ansible-Setup: Level verwendet keinen zentralen Control-Node. Jedes Gerät lädt das Playbook herunter und führt es lokal aus, während Level die Ausgabe in Echtzeit an Ihre Konsole überträgt.

Dieser Leitfaden beschreibt das Ausführungsmodell, wie man ein Level-Skript erstellt, das ansible-playbook, und wie man Windows-Endpunkte vorbereitet, die eine POSIX-kompatible Umgebung für die Ausführung von Ansible benötigen.

⚙️ VORAUSSETZUNGEN

  • Ansible muss auf jedem Zielgerät installiert sein (kein zentraler Control-Node – siehe unten)

  • Für Unix/macOS/Linux-Geräte: ansible und ansible-playbook verfügbar in PATH

  • Für Windows-Geräte: eine POSIX-kompatible Umgebung (WSL oder Cygwin/Git Bash) mit installiertem Ansible

  • Level-Agent auf allen Zielgeräten installiert

Wie Level Ansible-Playbooks ausführt

Standard-Ansible verwendet einen zentralen Control-Rechner, der sich per SSH in Zielhosts einloggt und Aufgaben remote ausführt. Das Modell von Level ist anders: Jedes Gerät führt das Playbook lokal auf sich selbst aus.

Wenn ein Level-Skript, das einen ansible-playbook Befehl auf einem Gerät ausgeführt wird:

  1. Das Skript (und alle angehängten Playbook-Dateien) werden auf das Gerät heruntergeladen.

  2. Das Gerät führt ansible-playbook lokal mithilfe der eigenen Ansible-Installation aus.

  3. Der Level-Agent erfasst stdout/stderr und überträgt es an die Level-Konsole, während das Playbook ausgeführt wird.

Das bedeutet, dass auf jedem Gerät Ansible installiert sein muss, nicht nur auf einem zentralen Rechner. Es bedeutet auch, dass Playbooks, die auf hosts: localhost oder lokale Verbindungstypen eignen sich am besten für die von Level verteilte Automatisierung.

ℹ️ HINWEIS: Playbooks, die entfernte Hosts über SSH ansprechen, funktionieren weiterhin – das Gerät fungiert dabei als Ansible-Control-Node für diese Remote-Verbindungen. Dies ist nützlich, wenn ein verwaltetes Gerät andere Geräte in seinem lokalen Netzwerk erreichen muss.

Ein Level-Skript für Ansible erstellen

Das Level-Skript ist ein Shell-Wrapper, der ansible-playbook. Die Playbook-Datei selbst wird separat angehängt und zur Laufzeit auf das Gerät heruntergeladen.

Für Linux und macOS

1. Gehen Sie zu Automatisierungen → Skripte und klicken Sie auf + Neues Skript.

2. Stellen Sie den Interpreter auf Shell (Bash).

3. Fügen Sie den Playbook-Aufruf hinzu:

Bash

#!/bin/bash
ansible-playbook /path/to/playbook.yml
if [ $? -ne 0 ]; then
  echo "Playbook failed on $(hostname)" >&2
  exit 1
fi

4. Hängen Sie die Playbook-Datei an das Skript an oder laden Sie sie in Automatisierungen → Dateien und verwenden Sie eine Datei herunterladen Aktion, um es vor der Skriptausführung auf das Gerät zu übertragen.

💡 TIPP: Verwenden Sie ansible-playbook --check während der Entwicklung für einen Probelauf, der Syntax und Konnektivität validiert, ohne Änderungen vorzunehmen.

Für Windows (über WSL)

  1. Stellen Sie den Interpreter auf PowerShell.

  2. Ansible über WSL aufrufen:

PowerShell

wsl ansible-playbook /mnt/c/LevelPlaybooks/network_test.yml

WSL muss bereits auf dem Gerät installiert und konfiguriert sein. Siehe Ansible auf Windows einrichten unten.

Für Windows (über Cygwin oder Git Bash)

PowerShell

C:\cygwin64\bin\bash.exe -lc "ansible-playbook /cygdrive/c/LevelPlaybooks/playbook.yml"

Ansible auf Windows-Endpunkten einrichten

Da jedes Gerät das Playbook lokal ausführt, benötigen Windows-Endpunkte eine POSIX-kompatible Shell mit installiertem Python und Ansible. Zwei Optionen:

Option A: Windows-Subsystem für Linux (WSL)

1. Führen Sie in PowerShell als Administrator Folgendes aus:

PowerShell

wsl --install

Starten Sie das Gerät neu, wenn Sie dazu aufgefordert werden.

2. Aus der Ubuntu-Shell, die nach dem Neustart geöffnet wird:

Bash

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip
pip3 install ansible

3. Überprüfen:

Bash

ansible --version
ansible-playbook --version

4. Rufen Sie Ansible in Level-Skripten über wsl ansible-playbook ... über PowerShell.

Option B: Cygwin oder Git Bash

1. Installieren Sie Cygwin oder Git für Windows und wählen Sie dabei Python 3, pip und OpenSSH während der Einrichtung aus.

2. Aus der Cygwin- oder Git Bash-Shell:

Bash

pip3 install ansible

3. Rufen Sie Ansible in Level-Skripten auf, indem Sie die Bash-Executable direkt aufrufen:

PowerShell

C:\cygwin64\bin\bash.exe -lc "ansible-playbook /path/to/playbook.yml"

⚠️ WARNUNG: Stimmen Sie Python- und Ansible-Versionen auf allen Windows-Endpunkten ab. Versionsunterschiede zwischen Endpunkten verursachen inkonsistentes Verhalten, das schwer zu diagnostizieren ist.

Playbook-Konfiguration für lokale Ausführung

Wenn Playbooks lokal auf jedem Gerät statt von einem zentralen Control-Node ausgeführt werden, helfen einige Konfigurationsanpassungen:

Verwenden Sie hosts: localhost with connection: local für Aufgaben, die auf dem Gerät selbst ausgeführt werden sollen:

YAML

- name: Local configuration
  hosts: localhost
  connection: local
  tasks:
    - name: Check connectivity
      ansible.builtin.ping:

Ausführliche Flags hinzufügen in der Entwicklung, um detaillierte Ausgaben in der Level-Konsole zu erhalten:

Bash

ansible-playbook /path/to/playbook.yml -vv

Level überträgt die gesamte stdout/stderr-Ausgabe, sodass der ausführliche Modus aufgabenweise Details direkt anzeigt.

Bewährte Vorgehensweisen

  • Lokal validieren, bevor Sie über Level bereitstellen. Führen Sie ansible-playbook playbook.yml --check auf einem Testgerät zuerst aus. Syntaxfehler im Playbook werden sofort angezeigt, anstatt erst mitten in einem Produktionslauf aufzutauchen.

  • Bei Fehler mit Nicht-Null beenden. Level markiert einen Skriptlauf nur dann als fehlgeschlagen, wenn das Skript mit einem Nicht-Null-Code beendet wird. Die if [ $? -ne 0 ] Prüfung im obigen Wrapper erledigt dies automatisch. Ohne sie kann ein fehlgeschlagenes Playbook in der Ausführungshistorie von Level wie ein Erfolg aussehen.

  • Playbooks idempotent halten. Ansible-Playbooks sollten dasselbe Ergebnis liefern, unabhängig davon, ob sie einmal oder zehnmal ausgeführt werden. Dadurch können sie sicher über Level erneut ausgeführt werden, ohne unbeabsichtigte Nebeneffekte.

  • Level's Datei-Repository für Playbooks verwenden. Playbook- .yml Dateien nach Automatisierungen → Dateien, und verwenden Sie dann eine Datei herunterladen Aktion vor dem Skriptschritt, um sie auf jedem Gerät zu platzieren. So bleiben Ihre Playbooks in Level versioniert, und jedes Gerät erhält die aktuelle Version.

Häufig gestellte Fragen

  • Muss Ansible auf jedem verwalteten Gerät installiert sein, oder reicht ein zentraler Server? Jedes Gerät, auf dem ein Playbook ausgeführt werden soll, muss Ansible lokal installiert haben. Level verbindet sich nicht per SSH von einem zentralen Control-Node aus – es verteilt das Playbook auf jedes Gerät und führt es dort unabhängig aus.

  • Kann das Playbook andere Hosts über SSH vom verwalteten Gerät aus ansprechen? Ja. Das verwaltete Gerät fungiert als Ansible-Control-Node für alle im Playbook definierten Remote-Verbindungen. SSH-Schlüssel und Anmeldedaten müssen auf dem verwalteten Gerät selbst vorhanden sein.

  • Mein Playbook läuft lokal einwandfrei, schlägt aber in Level fehl. Was sollte ich zuerst prüfen? Überprüfen Sie die Ausführen als Einstellung. Aktueller Benutzer führt das Skript als aktiv angemeldeter Benutzer unter Linux oder macOS aus. Unter Linux setzt dieser Modus das HOME, USER, LOGNAME, SHELL, und eine Basis- PATH, und fügt dann die passende systemd-Sitzungsumgebung hinzu, wenn verfügbar. Unter macOS wird beim Wechsel des Ausführungsbenutzers die Benutzerumgebung nicht neu aufgebaut; das Skript erbt die Umgebung des Agents. Verwenden Sie absolute Pfade und setzen Sie alle zusätzlichen Umgebungsvariablen, die das Playbook benötigt, explizit.

  • Wie übergebe ich zur Laufzeit Variablen an das Playbook? Verwenden Sie den --extra-vars Flags im ansible-playbook Aufruf. Die Systemvariablen und Automatisierungsvariablen von Level können mithilfe des {x} Auswahl im Skript-Editor. Zum Beispiel:
    ​ansible-playbook /path/to/playbook.yml --extra-vars "hostname={{level_device_name}}"

  • Kann ich das Playbook so planen, dass es regelmäßig ausgeführt wird? Ja. Hängen Sie das Skript an eine Automatisierung mit einem geplanten Auslöser an. Legen Sie den Zeitplan fest, fügen Sie eine Aktion „Datei herunterladen" für das Playbook hinzu, wenn es im Datei-Repository von Level gespeichert ist, und fügen Sie dann die Aktion „Skript ausführen" hinzu. Die Automatisierung führt das Playbook auf jedem Gerät aus, das den Auslöserbedingungen entspricht.

Verwandte Artikel
Hat dies deine Frage beantwortet?