Introducción
Level puede ejecutar playbooks de Ansible en dispositivos administrados a través de su motor de scripting. La principal diferencia respecto a una configuración típica de Ansible: Level no utiliza un nodo de control central. Cada dispositivo descarga y ejecuta el playbook localmente, y Level transmite la salida a su consola en tiempo real.
Esta guía cubre el modelo de ejecución, cómo crear un script de Level que llamaansible-playbook, y cómo preparar puntos finales de Windows que necesitan un entorno compatible con POSIX para ejecutar Ansible.
⚙️ REQUISITOS PREVIOS
Ansible instalado en cada dispositivo de destino (no un nodo de control central — ver abajo)
Para dispositivos Unix/macOS/Linux:
ansibleyansible-playbookavailable inPATHPara dispositivos Windows: un entorno compatible con POSIX (WSL o Cygwin/Git Bash) con Ansible instalado
Agente de Level implementado en todos los dispositivos de destino
Cómo Level ejecuta playbooks de Ansible
Ansible estándar utiliza un equipo de control central para SSH en hosts de destino y ejecutar tareas de forma remota. El modelo de Level es diferente:cada dispositivo ejecuta el playbook localmente en sí mismo.
Cuando se ejecuta un script de Level que contiene unansible-playbookcomando en un dispositivo:
El script (y cualquier archivo de playbook adjunto) se descarga en el dispositivo.
El dispositivo ejecuta
ansible-playbooklocalmente usando su propia instalación de Ansible.El agente de Level captura stdout/stderr y lo transmite a la consola de Level mientras se ejecuta el playbook.
Esto significa que cada dispositivo necesita tener Ansible instalado, no solo una máquina central. También significa que los playbooks dirigidos ahosts: localhosto tipos de conexión local funcionan mejor para la automatización distribuida por Level.
NOTA: 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.SUGERENCIA:
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
ADVERTENCIA:
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.Preguntas frecuentesDo 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.