Introduction
Level can run Ansible playbooks on managed devices through its scripting engine. The key difference from a typical Ansible setup: Level doesn't use a central control node. Each device downloads and runs the playbook locally, and Level streams the output to your console in real time.
This guide covers the execution model, how to create a Level script that calls ansible-playbook, and how to prepare Windows endpoints that need a PSystème d'exploitationIX-compatible environment to run Ansible.
⚙️ PREREQUISITES
Ansible installed on each target device (not a central control node — see below)
For Unix/macSystème d'exploitation/Linux devices:
ansibleandansible-playbookavailable inPATHFor Windows devices: a PSystème d'exploitationIX-compatible environment (WSL or Cygwin/Git Bash) with Ansible installed
Level agent deployed on all target devices
How Level Runs Ansible Playbooks
Standard Ansible uses a central control machine to SSH into target hosts and execute tasks remotely. Level's model is different: each device runs the playbook locally on itself.
When a Level script containing an ansible-playbook command runs on a device:
The script (and any attached playbook files) are downloaded to the device.
The device executes
ansible-playbooklocally using its own Ansible installation.The Level agent captures stdout/stderr and streams it to the Level console as the playbook runs.
This means every device needs Ansible installed, not just a central machine. It also means playbooks targeting hosts: localhost or local connection types work best for Level-distributed automation.
ℹ️ REMARQUE: 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 ansible-playbook. The playbook file itself is attached separately and downloaded to the device at runtime.
For Linux and macSystème d'exploitation
1. Go to Automations → Scripts and click + New script.
2. Set the interpreter to Shell (Bash).
3. Add the playbook invocation:
Bash
#!/bin/bash
ansible-playbook /path/to/playbook.yml
if [ $? -ne 0 ]; then
echo "Playbook failed on $(hostname)" >&2
exit 1
fi
4. Attach the playbook file to the script or upload it to Automations → Files and use a Download File action to place it on the device before the script runs.
💡 CONSEIL: Use ansible-playbook --check during development to do a dry run that validates syntax and connectivity without making changes.
For Windows (via WSL)
Set the interpreter to PowerShell.
Call Ansible through WSL:
PowerShell
wsl ansible-playbook /mnt/c/LevelPlaybooks/network_test.yml
WSL must already be installed and configured on the device. See Setting Up Ansible on Windows below.
For Windows (via Cygwin or Git Bash)
PowerShell
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /cygdrive/c/LevelPlaybooks/playbook.yml"
Setting Up Ansible on Windows Endpoints
Because each device runs the playbook locally, Windows endpoints need a PSystème d'exploitationIX-compatible shell with Python and Ansible installed. Two options:
Option A: Windows Subsystem for Linux (WSL)
1. In PowerShell as Administrator, run:
PowerShell
wsl --install
Reboot when prompted.
2. From the Ubuntu shell that opens after reboot:
Bash
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip
pip3 install ansible
3. Verify:
Bash
ansible --version
ansible-playbook --version
4. In Level scripts, call Ansible via wsl ansible-playbook ... from PowerShell.
Option B: Cygwin or Git Bash
1. Install Cygwin or Git for Windows, selecting Python 3, pip, and OpenSSH during setup.
2. From the Cygwin or Git Bash shell:
Bash
pip3 install ansible
3. In Level scripts, call Ansible by invoking the Bash executable directly:
PowerShell
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /path/to/playbook.yml"
⚠️ WARNING: Align Python and Ansible versions across all Windows endpoints. Version mismatches between endpoints cause inconsistent behavior that's hard to diagnose.
Playbook Configuration for Local Execution
When playbooks run locally on each device rather than from a central control node, a few configuration adjustments help:
Use hosts: localhost with connection: local for tasks that should run on the device itself:
YAML
- name: Local configuration
hosts: localhost
connection: local
tasks:
- name: Check connectivity
ansible.builtin.ping:
Add verbose flags in development to get detailed output in Level's console:
Bash
ansible-playbook /path/to/playbook.yml -vv
Level streams all stdout/stderr output, so verbose mode shows task-by-task detail inline.
Best Practices
Validate locally before deploying through Level. Run
ansible-playbook playbook.yml --checkon 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
if [ $? -ne 0 ]check 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.
Use Level's file repository for playbooks. Upload playbook
.ymlfiles to Automations → Files, then use a Download 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.
FAQ
Do 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
rooton Linux/macSystème d'exploitation and asSYSTEMon 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? Use the
--extra-varsflag in theansible-playbookcall. Level's system variables and automation variables can be passed in using the{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.