Passer au contenu principal

Guide de Script Ansible

Exécuter les playbooks Ansible sur les appareils gérés en utilisant Level

Mis à jour aujourd’hui

Level peut exécuter des playbooks Ansible sur les appareils gérés via son moteur de script. La différence clé par rapport à une configuration Ansible typique: 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, comment créer un script Level qui appelle ansible-playbook, et comment préparer les points de terminaison Windows qui ont besoin d'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: ansible et ansible-playbook disponibles dans PATH

  • Pour 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 SSH dans les hôtes cibles et exécuter les 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 une commande ansible-playbook s'exécute sur un appareil:

  1. Le script (et les fichiers de playbook joints) sont téléchargés sur l'appareil.

  2. L'appareil exécute ansible-playbook localement en utilisant sa propre installation Ansible.

  3. L'agent Level capture stdout/stderr et le diffuse vers la console Level à mesure que le playbook s'exécute.

Cela signifie que chaque appareil a besoin d'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 de Level.

ℹ️ REMARQUE: Les playbooks qui ciblent des hôtes distants via SSH fonctionnent toujours — l'appareil agit comme le nœud de contrôle Ansible pour ces connexions distantes. Ceci est utile dans les cas où un appareil géré doit en atteindre d'autres sur son réseau local.


Création d'un Script Level pour Ansible

Le script Level est un wrapper shell qui appelle ansible-playbook. Le fichier 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. Allez à Automations → 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 playbook au script ou téléchargez-le sur Automations → Fichiers et utilisez une action Télécharger le fichier pour le placer sur l'appareil avant l'exécution du script.

💡 CONSEIL: Utilisez ansible-playbook --check lors du développement pour effectuer une exécution à blanc qui valide la syntaxe et la connectivité sans apporter de modifications.

Pour Windows (via WSL)

  1. Définissez l'interpréteur sur PowerShell.

  2. 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

Parce que chaque appareil exécute le playbook localement, les points de terminaison Windows ont besoin d'un shell compatible POSIX avec Python et Ansible installés. Deux options:

Option A: Windows Subsystem for Linux (WSL)

1. Dans PowerShell en tant qu'administrateur, exécutez:

PowerShell

wsl --install

Redémarrez lorsque vous y êtes invité.

2. À partir du 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. À partir du 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 Ansible sur tous les points de terminaison Windows. Les incompatibilités de version entre les points de terminaison causent un comportement incohérent qui est difficile à diagnostiquer.


Configuration du Playbook pour l'Exécution Locale

Lorsque les playbooks s'exécutent localement sur chaque appareil plutôt que depuis un nœud de contrôle central, quelques ajustements de configuration aident:

Utilisez hosts: localhost avec 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:

Ajoutez des drapeaux verbeux lors du 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 verbose affiche les détails de la tâche en ligne.


Meilleures Pratiques

  • Validez localement avant de déployer via Level. Exécutez ansible-playbook playbook.yml --check d'abord sur un appareil de test. Les erreurs de syntaxe dans le playbook apparaissent immédiatement plutôt qu'au milieu d'une exécution de production.

  • Quittez avec un code différent de zéro en cas d'échec. Level marque une exécution de script comme échouée uniquement si le script quitte avec un code différent de zéro. La vérification if [ $? -ne 0 ] ci-dessus le fait automatiquement. Sans cela, un playbook échoué 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 fois ou dix fois. Cela les rend sûrs à réexécuter via Level sans effets secondaires involontaires.

  • Utilisez le dépôt de fichiers de Level pour les playbooks. Téléchargez les fichiers playbook .yml sur Automations → Fichiers, puis utilisez une action Télécharger le fichier avant l'étape de script pour les placer sur chaque appareil. Cela garde vos playbooks contrôlés par version dans Level et assure que chaque appareil obtient la version actuelle.


FAQ

  • Ai-je besoin d'Ansible sur chaque appareil géré, ou juste un serveur central? Chaque appareil sur lequel vous souhaitez exécuter un playbook a besoin d'Ansible installé localement. Level ne SSH pas à partir d'un nœud de contrôle central — il distribue et exécute le playbook sur chaque appareil indépendamment.

  • Le playbook peut-il cibler d'autres hôtes via SSH à partir de l'appareil géré? Oui. L'appareil géré agit comme le nœud de contrôle Ansible pour toute connexion distante définie dans le playbook. Les clés SSH et les credentials doivent être présentes sur l'appareil géré lui-même.

  • Mon playbook s'exécute correctement localement mais échoue dans Level. Qu'est-ce que je dois vérifier en premier? Vérifiez le contexte de l'utilisateur. Level exécute les scripts en tant que root sur Linux/macOS et en tant que SYSTEM sur Windows. Si le playbook dépend d'un répertoire personnel de l'utilisateur, PATH ou une variable d'environnement qui n'est définie que pour un utilisateur spécifique, il ne trouvera pas ces ressources. Utilisez des chemins absolus et une configuration d'environnement explicite dans le playbook.

  • Comment puis-je transmettre des variables dans le playbook au moment de l'exécution? Utilisez le drapeau --extra-vars dans l'appel ansible-playbook. Les variables système de Level et les variables d'automatisation peuvent être transmises en utilisant le sélecteur {x} dans l'éditeur de script. Par exemple:
    ansible-playbook /path/to/playbook.yml --extra-vars "hostname=##{{level_device_name}}"

  • Puis-je planifier le playbook pour qu'il s'exécute régulièrement? Oui. Attachez le script à une automatisation avec un déclencheur planifié. Définissez l'horaire, ajoutez une action Télécharger le fichier pour le playbook s'il est stocké dans le dépôt de fichiers de Level, puis ajoutez l'action Exécuter le script. L'automatisation exécute le playbook sur chaque appareil qui correspond aux conditions du déclencheur.

Avez-vous trouvé la réponse à votre question ?