Einführung
Level kann Ansible-Playbooks auf verwalteten Geräten über sein Scripting-Engine ausführen. Der Hauptunterschied zu einem typischen Ansible-Setup: Level verwendet keinen zentralen Steuerknoten. Jedes Gerät lädt das Playbook lokal herunter und führt es aus, und Level streamt die Ausgabe in Echtzeit zu Ihrer Konsole.
Dieser Leitfaden behandelt das Ausführungsmodell, das Erstellen eines Level-Skripts, das aufruftansible-playbook, und das Vorbereiten von Windows-Endpunkten, die eine POSIX-kompatible Umgebung benötigen, um Ansible auszuführen.
⚙️ VORAUSSETZUNGEN
Ansible auf jedem Zielgerät installiert (kein zentraler Steuerknoten — siehe unten)
Für Unix/macOS/Linux-Geräte:
ansibleundansible-playbookavailable inPATHFür Windows-Geräte: eine POSIX-kompatible Umgebung (WSL oder Cygwin/Git Bash) mit installiertem Ansible
Level-Agent auf allen Zielgeräten bereitgestellt
Wie Level Ansible-Playbooks ausführt
Standard-Ansible verwendet einen zentralen Steuermitcomputer, um sich in Zielmaschinen einzumelden und Aufgaben remote auszuführen. Das Modell von Level ist anders:jedes Gerät führt das Playbook lokal auf sich selbst aus.
Wenn ein Level-Skript, das einansible-playbookBefehl auf einem Gerät ausgeführt wird:
Das Skript (und alle angehängten Playbook-Dateien) werden auf das Gerät heruntergeladen.
Das Gerät führt aus
ansible-playbooklokal mit seiner eigenen Ansible-Installation.Der Level-Agent erfasst stdout/stderr und streamt es an die Level-Konsole, während das Playbook ausgeführt wird.
Das bedeutet, dass jedes Gerät Ansible installiert haben muss, nicht nur ein zentraler Computer. Es bedeutet auch, dass Playbooks, die sich aufhosts: localhostoder lokale Verbindungstypen zielen, am besten für die von Level verteilte Automatisierung funktionieren.
HINWEIS: Playbooks that target remote hosts over SSH still work — the device acts as the Ansible control node for those remote connections. This is useful for cases where one managed device needs to reach others on its local network.Creating a Level Script for Ansible
The Level script is a shell wrapper that calls
. The playbook file itself is attached separately and downloaded to the device at runtime.ansible-playbookFor Linux and macOS
1. Go to
Automations → Scripts and click + New script.2. Set the interpreter to
Shell (Bash).3. Add the playbook invocation:
Bash
4. Attach the playbook file to the script or upload it to
#!/bin/bash
ansible-playbook /path/to/playbook.yml
if [ $? -ne 0 ]; then
echo "Playbook failed on $(hostname)" >&2
exit 1
fi
Automations → Files and use a Download File action to place it on the device before the script runs.TIPP:
Use during development to do a dry run that validates syntax and connectivity without making changes.For Windows (via WSL)ansible-playbook --checkSet the interpreter to
PowerShell
.Call Ansible through WSL:PowerShell
WSL must already be installed and configured on the device. See
Setting Up Ansible on Windows
wsl ansible-playbook /mnt/c/LevelPlaybooks/network_test.yml
below.For Windows (via Cygwin or Git Bash)PowerShell
Setting Up Ansible on Windows Endpoints
Because each device runs the playbook locally, Windows endpoints need a POSIX-compatible shell with Python and Ansible installed. Two options:
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /cygdrive/c/LevelPlaybooks/playbook.yml"
Option A: Windows Subsystem for Linux (WSL)
1. In PowerShell as Administrator, run:
PowerShell
Reboot when prompted.
2. From the Ubuntu shell that opens after reboot:
wsl --install
Bash
3. Verify:
Bash
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip
pip3 install ansible
4. In Level scripts, call Ansible via
from PowerShell.
ansible --version
ansible-playbook --version
Option B: Cygwin or Git Bashwsl ansible-playbook ...1. Install
Cygwin
or Git for Windows, selecting Python 3, pip, and OpenSSH during setup.2. From the Cygwin or Git Bash shell:Bash
3. In Level scripts, call Ansible by invoking the Bash executable directly:
PowerShell
pip3 install ansible
WARNUNG:
Align Python and Ansible versions across all Windows endpoints. Version mismatches between endpoints cause inconsistent behavior that's hard to diagnose.
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /path/to/playbook.yml"
Playbook Configuration for Local ExecutionWhen playbooks run locally on each device rather than from a central control node, a few configuration adjustments help:Use
with
for tasks that should run on the device itself:
YAMLhosts: localhost Add verbose flags connection: local in development to get detailed output in Level's console:
Bash
- name: Local configuration
hosts: localhost
connection: local
tasks:
- name: Check connectivity
ansible.builtin.ping:
Level streams all stdout/stderr output, so verbose mode shows task-by-task detail inline.Best Practices
Validate locally before deploying through Level.
ansible-playbook /path/to/playbook.yml -vv
Run
on a test device first. Syntax errors in the playbook surface immediately rather than halfway through a production run.
Exit non-zero on failure. Level marks a script run as failed only if the script exits with a non-zero code. The
ansible-playbook playbook.yml --checkcheck in the wrapper above does this automatically. Without it, a failed playbook can look like a success in Level's run history.Keep playbooks idempotent. Ansible playbooks should produce the same result whether they run once or ten times. This makes them safe to re-run via Level without unintended side effects.
if [ $? -ne 0 ]Use Level's file repository for playbooks.Upload playbook files to
Automations → Files, then use a
.ymlDownload File action before the script step to place them on each device. This keeps your playbooks version-controlled in Level and ensures every device gets the current version.FAQDo I need Ansible on every managed device, or just a central server? Every device that you want to run a playbook needs Ansible installed locally. Level doesn't SSH from a central control node — it distributes and runs the playbook on each device independently.
Can the playbook target other hosts over SSH from the managed device?
Yes. The managed device acts as the Ansible control node for any remote connections defined in the playbook. SSH keys and credentials need to be present on the managed device itself.My playbook runs fine locally but fails in Level. What should I check first?
Check the user context. Level runs scripts as on Linux/macOS and as
on Windows. If the playbook depends on a user home directory, PATH, or environment variable that's only set for a specific user, it won't find those resources. Use absolute paths and explicit environment setup in the playbook.How do I pass variables into the playbook at runtime?
rootUse theSYSTEMflag in thecall. Level's system variables and automation variables can be passed in using the picker in the script editor. For example:
--extra-varsCan I schedule the playbook to run on a recurring basis?ansible-playbookYes. Attach the script to an automation with a Scheduled trigger. Set the schedule, add a Download File action for the playbook if it's stored in Level's file repository, then add the Run Script action. The automation runs the playbook on every device that matches the trigger conditions.{x}picker in the script editor. For example:
ansible-playbook /path/to/playbook.yml --extra-vars "hostname=##{{level_device_name}}"Can I schedule the playbook to run on a recurring basis? Yes. Attach the script to an automation with a Scheduled trigger. Set the schedule, add a Download File action for the playbook if it's stored in Level's file repository, then add the Run Script action. The automation runs the playbook on every device that matches the trigger conditions.