Introduction
Level peut exécuter des playbooks Ansible sur des appareils gérés via son moteur de script. La principale différence par rapport à une configuration Ansible classique : Level n'utilise pas de nœud de contrôle central. Chaque appareil télécharge et exécute le playbook localement, et Level diffuse la sortie vers votre console en temps réel.
Ce guide couvre le modèle d'exécution, la manière de créer un script Level qui appelle ansible-playbook, et comment préparer les points de terminaison Windows qui nécessitent un environnement compatible POSIX pour exécuter Ansible.
⚙️ PRÉREQUIS
Ansible installé sur chaque appareil cible (pas un nœud de contrôle central — voir ci-dessous)
Pour les appareils Unix/macOS/Linux :
ansibleetansible-playbookdisponible dansPATHPour les appareils Windows : un environnement compatible POSIX (WSL ou Cygwin/Git Bash) avec Ansible installé
Agent Level déployé sur tous les appareils cibles
Comment Level exécute les playbooks Ansible
Ansible standard utilise une machine de contrôle centrale pour se connecter en SSH aux hôtes cibles et exécuter des tâches à distance. Le modèle de Level est différent : chaque appareil exécute le playbook localement sur lui-même.
Lorsqu'un script Level contenant un ansible-playbook la commande s'exécute sur un appareil :
Le script (et tous les fichiers de playbook joints) sont téléchargés sur l'appareil.
L'appareil exécute
ansible-playbooklocalement en utilisant sa propre installation Ansible.L'agent Level capture la sortie stdout/stderr et la diffuse vers la console Level au fur et à mesure de l'exécution du playbook.
Cela signifie que chaque appareil doit avoir Ansible installé, pas seulement une machine centrale. Cela signifie également que les playbooks ciblant hosts: localhost ou les types de connexion locaux fonctionnent mieux pour l'automatisation distribuée par Level.
ℹ️ REMARQUE : Les playbooks qui ciblent des hôtes distants via SSH fonctionnent toujours — l'appareil agit comme nœud de contrôle Ansible pour ces connexions distantes. Cela est utile dans les cas où un appareil géré doit en atteindre d'autres sur son réseau local.
Créer un script Level pour Ansible
Le script Level est un wrapper shell qui appelle ansible-playbook. Le fichier de playbook lui-même est joint séparément et téléchargé sur l'appareil au moment de l'exécution.
Pour Linux et macOS
1. Accédez à Automatisations → Scripts et cliquez sur + Nouveau script.
2. Définissez l'interpréteur sur Shell (Bash).
3. Ajoutez l'invocation du playbook :
Bash
#!/bin/bash
ansible-playbook /path/to/playbook.yml
if [ $? -ne 0 ]; then
echo "Playbook failed on $(hostname)" >&2
exit 1
fi
4. Joignez le fichier de playbook au script ou téléversez-le dans Automatisations → Fichiers et utilisez une Télécharger le fichier action pour le placer sur l'appareil avant l'exécution du script.
💡 CONSEIL : Utilisez ansible-playbook --check pendant le développement pour effectuer un test à blanc qui valide la syntaxe et la connectivité sans apporter de modifications.
Pour Windows (via WSL)
Définissez l'interpréteur sur PowerShell.
Appelez Ansible via WSL :
PowerShell
wsl ansible-playbook /mnt/c/LevelPlaybooks/network_test.yml
WSL doit déjà être installé et configuré sur l'appareil. Voir Configuration d'Ansible sur Windows ci-dessous.
Pour Windows (via Cygwin ou Git Bash)
PowerShell
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /cygdrive/c/LevelPlaybooks/playbook.yml"
Configuration d'Ansible sur les points de terminaison Windows
Étant donné que chaque appareil exécute le playbook localement, les points de terminaison Windows nécessitent un shell compatible POSIX avec Python et Ansible installés. Deux options :
Option A : Sous-système Windows pour Linux (WSL)
1. Dans PowerShell en tant qu'administrateur, exécutez :
PowerShell
wsl --install
Redémarrez lorsque vous y êtes invité.
2. Depuis le shell Ubuntu qui s'ouvre après le redémarrage :
Bash
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip
pip3 install ansible
3. Vérifiez :
Bash
ansible --version
ansible-playbook --version
4. Dans les scripts Level, appelez Ansible via wsl ansible-playbook ... depuis PowerShell.
Option B : Cygwin ou Git Bash
1. Installez Cygwin ou Git for Windows, en sélectionnant Python 3, pip et OpenSSH lors de la configuration.
2. Depuis le shell Cygwin ou Git Bash :
Bash
pip3 install ansible
3. Dans les scripts Level, appelez Ansible en invoquant directement l'exécutable Bash :
PowerShell
C:\cygwin64\bin\bash.exe -lc "ansible-playbook /path/to/playbook.yml"
⚠️ AVERTISSEMENT : Alignez les versions de Python et d'Ansible sur tous les points de terminaison Windows. Les incompatibilités de versions entre les points de terminaison provoquent des comportements incohérents difficiles à diagnostiquer.
Configuration du playbook pour l'exécution locale
Lorsque les playbooks s'exécutent localement sur chaque appareil plutôt qu'à partir d'un nœud de contrôle central, quelques ajustements de configuration s'avèrent utiles :
Utilisez hosts: localhost with connection: local pour les tâches qui doivent s'exécuter sur l'appareil lui-même :
YAML
- name: Local configuration
hosts: localhost
connection: local
tasks:
- name: Check connectivity
ansible.builtin.ping:
Ajouter des indicateurs de verbosité en développement pour obtenir une sortie détaillée dans la console de Level :
Bash
ansible-playbook /path/to/playbook.yml -vv
Level diffuse toute la sortie stdout/stderr, donc le mode verbeux affiche le détail tâche par tâche en ligne.
Bonnes pratiques
Validez localement avant de déployer via Level. Exécutez
ansible-playbook playbook.yml --checksur un appareil de test en premier. Les erreurs de syntaxe dans le playbook apparaissent immédiatement plutôt qu'à mi-chemin d'une exécution en production.Quitter avec un code non nul en cas d'échec. Level marque l'exécution d'un script comme échouée uniquement si le script se termine avec un code non nul. La
if [ $? -ne 0 ]La vérification dans le wrapper ci-dessus le fait automatiquement. Sans cela, un playbook en échec peut ressembler à un succès dans l'historique d'exécution de Level.Gardez les playbooks idempotents. Les playbooks Ansible doivent produire le même résultat qu'ils s'exécutent une ou dix fois. Cela les rend sûrs à réexécuter via Level sans effets secondaires non souhaités.
Utilisez le référentiel de fichiers de Level pour les playbooks. Téléversez les fichiers de playbook
.ymlfichiers vers Automatisations → Fichiers, puis utilisez une Télécharger le fichier action avant l'étape du script pour les placer sur chaque appareil. Cela maintient vos playbooks sous contrôle de version dans Level et garantit que chaque appareil obtient la version actuelle.
FAQ
Dois-je avoir Ansible sur chaque appareil géré, ou uniquement sur un serveur central ? Chaque appareil sur lequel vous souhaitez exécuter un playbook doit avoir Ansible installé localement. Level ne se connecte pas en SSH depuis un nœud de contrôle central — il distribue et exécute le playbook sur chaque appareil de manière indépendante.
Le playbook peut-il cibler d'autres hôtes via SSH depuis l'appareil géré ? Oui. L'appareil géré agit comme nœud de contrôle Ansible pour toutes les connexions distantes définies dans le playbook. Les clés SSH et les informations d'identification doivent être présentes sur l'appareil géré lui-même.
Mon playbook s'exécute correctement localement mais échoue dans Level. Que dois-je vérifier en premier ? Vérifiez le paramètre Exécuter en tant que paramètre. Utilisateur actuel exécute le script en tant qu'utilisateur actif connecté sur Linux ou macOS. Sur Linux, ce mode définit le
HOME,USER,LOGNAME,SHELL, et unePATH, puis ajoute l'environnement de session systemd correspondant lorsqu'il est disponible. Sur macOS, le changement d'utilisateur d'exécution ne reconstruit pas l'environnement de l'utilisateur ; le script hérite de l'environnement de l'agent. Utilisez des chemins absolus et définissez explicitement toutes les variables d'environnement supplémentaires dont le playbook a besoin.Comment transmettre des variables au playbook au moment de l'exécution ? Utilisez le
--extra-varsindicateur dans leansible-playbookappel. Les variables système de Level et les variables d'automatisation peuvent être transmises en utilisant le{x}sélecteur dans l'éditeur de script. Par exemple :
ansible-playbook /path/to/playbook.yml --extra-vars "hostname={{level_device_name}}"Puis-je planifier l'exécution du playbook de manière récurrente ? Oui. Associez le script à une automatisation avec un déclencheur planifié. Définissez la planification, ajoutez une action Télécharger le fichier pour le playbook s'il est stocké dans le référentiel de fichiers de Level, puis ajoutez l'action Exécuter le script. L'automatisation exécute le playbook sur chaque appareil correspondant aux conditions du déclencheur.