Si vous écrivez ou utilisez des playbooks Ansible, vous avez l'habitude de lire les fichiers de configuration YAML. YAML peut être d'une simplicité trompeuse et pourtant étrangement écrasante à la fois, surtout si l'on considère les innombrables modules Ansible possibles à votre disposition. Il semble qu'il devrait être facile de noter quelques options dans un fichier YAML, puis d'exécuter Ansible, mais de quelles options votre module préféré a-t-il besoin ? Et pourquoi certaines paires clé-valeur sont-elles alors que d'autres sont des listes ?
YAML pour Ansible peut devenir complexe, donc comprendre comment les modules Ansible se traduisent en YAML est un élément important pour s'améliorer dans les deux cas. Avant de pouvoir comprendre comment YAML fonctionne pour les modules Ansible, vous devez comprendre les bases de YAML.
Si vous ne connaissez pas la différence entre un bloc de mappage et un bloc de séquence dans YAML, lisez cet article d'introduction rapide aux bases de YAML.
Syntaxe de la commande
En plus d'une utilisation ad hoc, Ansible est utilisé via des playbooks . Un playbook est composé d'un ou plusieurs plays dans une liste ordonnée (une séquence YAML ). Chaque jeu peut exécuter une ou plusieurs tâches , et chaque tâche appelle un module Ansible.
Les modules Ansible sont essentiellement des interfaces pour les commandes. Si vous connaissez le terminal Linux ou le Powershell de Microsoft, vous savez comment construire une commande à l'aide d'options (telles que --long ou -s ) avec des arguments (également appelés paramètres ).
Voici un exemple simple :
$ mkdir foo
Cette commande utilise le mkdir commande pour créer un répertoire appelé foo .
Un playbook Ansible construit également des commandes. Ce sont les mêmes commandes, mais elles sont appelées en utilisant une syntaxe différente de celle à laquelle vous êtes habitué dans un terminal.
[ Vous pourriez également apprécier : Mise en route avec Ansible ]
Modules Ansible et YAML
En tant que tâche dans un playbook Ansible, cependant, la syntaxe est très différente. Tout d'abord, la pièce reçoit un nom, qui est une description lisible par l'homme de ce qui est joué. Un jeu accepte de nombreux mots clés, y compris hosts pour limiter les hôtes sur lesquels il est censé s'exécuter et remote_user pour définir le nom d'utilisateur qu'Ansible doit utiliser pour accéder aux hôtes distants.
Les mots-clés pour les lectures sont définis par Ansible lui-même, et une liste de clés (et les types d'informations que chacune attend comme valeur) est disponible dans la documentation des mots-clés Ansible Play.
Ces clés ne sont pas des éléments de liste distincts. Dans la terminologie YAML, ce sont des mappages intégré dans la séquence de jeu .
Voici une simple déclaration de jeu :
---
- name: “Create a directory”
hosts: localhost
Le dernier bloc de mappage dans une déclaration de lecture est le tasks mot-clé, qui ouvre une nouvelle séquence pour définir quel module Ansible le jeu va exécuter, et avec quels arguments. C'est ici que vous utilisez des commandes familières d'une manière inhabituelle et YAML-ifiée. En fait, il vous est si peu familier que vous devez probablement vous renseigner sur le module afin de découvrir les arguments qu'il attend de vous.
Dans cet exemple, j'utilise le module de fichier intégré. Dans la documentation du module, vous pouvez voir que le paramètre requis est path , qui attend un chemin de fichier POSIX valide. Fort de ces informations, vous pouvez générer un playbook Ansible très simple qui ressemble à ceci :
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
Si vous vous habituez encore à la signification de l'indentation de YAML, notez que le nom de la tâche n'est pas mis en retrait par rapport aux tasks car name est le début d'un nouveau bloc de séquence YAML (qui, en l'occurrence, sert de valeur pour les tasks clé). Le mot file identifie le module utilisé, qui fait partie de la définition de la tâche, et path est un paramètre obligatoire du file module.
En d'autres termes, la tâche d'un jeu est un bloc de séquence YAML (c'est-à-dire une liste ordonnée) de définitions invoquant un module et ses paramètres.
Vous pouvez tester cette lecture pour vérifier qu'elle fonctionne comme prévu, mais commencez par exécuter yamllint dessus pour éviter toute surprise syntaxique :
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
TASK [Instantiate] ******************
fatal: [localhost]:
FAILED! => {“changed”: false,
“msg”: “file (foo) is absent, cannot continue” …
Le playbook a été traité, mais la tâche a échoué. Lecture de la liste des paramètres du file module révèle que son comportement dépend largement de la valeur de state . Plus précisément, l'action par défaut consiste à renvoyer l'état de path .
Modifiez votre exemple de fichier YAML pour inclure un state mappage :
---
- name: "Create a directory"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "foo"
state: directory Exécutez-le à nouveau pour réussir :
$ yamllint folder.yaml || echo “fail”
$ ansible-playbook folder.yaml
[…]
$ ls
foo Modules de contrôle
Tous les modules Ansible ne correspondent pas directement à une seule commande. Certains modules modifient la façon dont Ansible traite votre playbook. Par exemple, le with_items module énumère les éléments sur lesquels vous souhaitez qu'un autre module opère. Vous pourriez le considérer comme une sorte de do while ou for boucle.
Sa documentation indique qu'il n'accepte qu'un seul paramètre :une liste d'éléments. Une "liste" dans la terminologie YAML est une séquence , vous savez donc sans même regarder l'exemple de code dans la documentation que chaque élément doit commencer par un tiret (- ).
Voici une nouvelle itération de création de dossier, cette fois avec plusieurs sous-dossiers (en utilisant le recurse paramètre dans le file module) et un paramètre supplémentaire pour définir les autorisations de fichiers. Ne laissez pas les lignes supplémentaires vous tromper. C'est essentiellement le même code qu'avant, seulement avec des paramètres supplémentaires comme décrit dans le file documentation du module, plus le with_items module pour activer l'itération :
---
- name: "Create directory structure"
hosts: localhost
tasks:
- name: "Instantiate"
file:
path: "{{ item }}"
recurse: true
mode: "u=rwx,g=rwx,o=r"
state: directory
with_items:
- "foo/src"
- "foo/dist"
- "foo/doc" Exécutez le playbook pour voir les résultats :
$ yamllint folder.yaml
$ ansible-playbook folder.yaml
[…]
$ ls foo
dist doc src [ Besoin d'en savoir plus sur Ansible ? Suivez un cours de présentation technique gratuit de Red Hat. Ansible Essentials :Présentation technique de la simplicité dans l'automatisation. ]
Principes Ansible
Un playbook Ansible est une séquence YAML , qui se compose lui-même de mappages et séquences .
Les playbooks contiennent également des modules Ansible, chacun acceptant les paramètres définis par son développeur. Les paramètres obligatoires et facultatifs sont répertoriés dans la documentation d'un module.
Pour construire un playbook Ansible, démarrez une séquence YAML qui nomme le jeu, puis répertorie (dans une séquence) une ou plusieurs tâches. Dans chaque tâche, un ou plusieurs modules peuvent être invoqués.
Portez une attention particulière à l'indentation en comprenant le type de données que vous entrez dans votre fichier YAML. Cela pourrait aider à éviter considérer l'indentation comme une indication d'héritage logique et, à la place, voir chaque ligne comme son type de données YAML (c'est-à-dire une séquence ou un mappage).
Utilisez yamllint pour vérifier vos fichiers YAML.
Une fois que vous avez compris la structure d'un playbook, il vous suffit de suivre la documentation du module pour exécuter les tâches que vous souhaitez que votre playbook exécute. Il existe des centaines de modules disponibles, alors commencez à les explorer et voyez les choses incroyables que vous pouvez faire avec cet outil incroyable.