Dans le dernier article, nous avons discuté des commandes ad hoc Ansible . Tout ce que nous y avons appris sera appliqué dans cet article mais d'une manière différente. Ce tutoriel explique ce qu'est un Playbook dans Ansible et comment travailler avec des Playbooks Ansible avec des exemples.
Qu'est-ce qu'Ansible Playbook ?
Le playbook est un YAML fichier utilisé pour exécuter une ou plusieurs tâches sur les hôtes gérés de l'environnement.
La principale différence entre les commandes ad hoc et les playbooks est qu'avec les commandes ad hoc, vous pouvez créer des lignes simples ou utiliser la commande ad hoc dans des scripts shell pour exécuter des tâches simples. Lorsque vous souhaitez effectuer des opérations répétitives complexes, vous devez écrire des playbooks et les stocker dans un référentiel central et les utiliser chaque fois que nécessaire.
Supposons que vous faites partie de l'équipe d'administration système. Chaque fois qu'un nouveau serveur est construit, votre équipe est responsable du renforcement du serveur conformément à la politique de votre entreprise.
Dans ce cas, vous pouvez créer un playbook et renforcer le serveur. Désormais, le même playbook peut être utilisé contre le nombre N de nouveaux hôtes qui doivent être renforcés.
Structure de mon laboratoire Ansible
Je vais utiliser le laboratoire ansible qui a été créé avec deux nœuds Ubuntu 20.04LTS. Vous pouvez vous référer à l'article suivant pour reproduire la même configuration de laboratoire si nécessaire.
Créez votre premier playbook Ansible
Comme je l'ai dit plus tôt, les Playbooks sont écrits en YAML format. Le playbook doit avoir un .yml ou .yaml extension. Consultez le lien ci-dessous si vous souhaitez en savoir plus sur YAML.
Vous trouverez ci-dessous l'exemple de playbook que je vais utiliser pour montrer comment le playbook fonctionne. Il s'agit d'un playbook simple qui se chargera de configurer un message de bannière personnalisé lorsque je me connecterai au nœud.
- name: First Play - Modify banner message
hosts: ubuntu2
gather_facts: false
become: yes
tasks:
- name: Remove Execute Permission from /etc/update-motd.d/*
file:
path: /etc/update-motd.d/
mode: u=rw,g=rw,o=rw
recurse: yes
- name: ADD BANNER MESSAGE
copy:
content: "Welcome to OSTechnix"
dest: /etc/motd Examinons chaque section de ce playbook. Le playbook est divisé en deux sections. La première section contient des définitions de lecture telles que le nom de la lecture, les hôtes cibles et l'élévation des privilèges.
- nom - Le playbook doit avoir un nom de jeu qui n'est rien d'autre qu'un regroupement logique de l'hôte cible, des paramètres et des tâches. Vous pouvez avoir plus d'un jeu dans le playbook. Donnez un nom descriptif à la pièce.
- hôtes - Hôtes cibles. Ansible vérifiera le fichier d'inventaire et vérifiera si la valeur donnée dans les hôtes est disponible dans le fichier d'inventaire.
- devenir - Lorsqu'il est défini sur 'oui' exécutera la tâche avec le privilège sudo. Depuis que je modifie l'autorisation sous le
/etc/répertoire, la tâche doit être soumise avec des privilèges élevés.
Jetez un œil à notre article complet sur l'élévation des privilèges pour le comprendre en détail.
Dans la deuxième section, les tâches sont définies. Vous devez utiliser le mot-clé "tâches" pour définir la tâche. Ici, j'ai créé deux tâches. Chaque tâche doit recevoir un nom en utilisant le mot-clé "nom" .
- La première tâche supprimera l'autorisation d'exécution de
/etc/update-motd.d/*annuaire. J'utilise le fichier module pour cela. - La deuxième tâche écrira la chaîne "Bienvenue dans OSTechnix" au
/etc/motdfichier en utilisant la copie module.
Avant d'exécuter le playbook, permettez-moi de vérifier l'état de mon nœud cible (managed2.anslab.com ) en vous connectant au nœud. Vous pouvez voir que lorsque je me connecte au nœud, je reçois le message de bannière par défaut et l'autorisation d'exécution est définie pour tous les fichiers.
$ ssh [email protected]
Pour exécuter le playbook, exécutez la commande suivante depuis le terminal.
$ ansible-playbook <playbook-name> # SYNTAX $ ansible-playbook banner_mod.yml
Essayons de comprendre le résultat.
1. Lorsque vous lancez le playbook, la première chose que vous verrez est le nom de la pièce.
PLAY [Modify banner message] *
2. La première exécution possible de la tâche est "Gathering Facts" . Nous n'avons pas défini cette tâche dans notre playbook, mais elle fonctionnera à moins que vous ne la désactiviez.
TASK [Gathering Facts] *
ok: [managed2]
3. Maintenant, la tâche que vous avez définie dans le fichier YAML dans le cadre de la lecture commencera à s'exécuter une par une. Ansible lira le playbook de haut en bas afin que les tâches soient exécutées dans l'ordre défini dans le playbook.
TASK [Remove Execute Permission from /etc/update-motd.d/*] ******************************************************************************************* changed: [managed2] TASK [ADD BANNER MESSAGE] **************************************************************************************************************************** changed: [managed2]
4. Une fois toutes les tâches terminées, vous aurez un récapitulatif de jeu qui vous donnera le nombre total de statuts des différentes tâches. Dans notre cas, un total de trois tâches (ok=3) ont été exécutées, y compris la collecte de faits, et seules deux tâches (changed=2) ont apporté les modifications au nœud géré.
PLAY RECAP ****************************************** managed2 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Je peux maintenant valider le nœud géré pour voir si les modifications sont appliquées avec succès.
Désactiver la collecte des faits
Comme prévu dans la section précédente lorsque vous exécutez le playbook, ansible collectera des informations sur les nœuds gérés en exécutant le module de configuration . Vous pouvez désactiver la collecte de faits en ajoutant la ligne suivante dans le playbook.
gather_facts : false
Désormais, lorsque vous exécuterez à nouveau le playbook, vous ne verrez que deux tâches définies dans le playbook. Comme Ansible est idempotent, ansible n'essaiera pas de modifier l'état de l'objet s'il est déjà modifié. Ainsi, vous verrez la sortie comme OK .
La collecte de faits ralentira les jeux lorsque vous devrez exécuter le livre de jeu contre un grand nombre d'hôtes. En effet, ansible doit se connecter au nœud géré et collecter de nombreuses données sur le nœud, ce qui n'est pas nécessaire dans tous les cas.
Vous pouvez vérifier la différence de temps d'exécution avec et sans faits ci-dessous.
$ time ansible-playbook banner_mod.yml # WITHOUT FACTS real 0m1.642s user 0m0.731s sys 0m0.220s $ time ansible-playbook banner_mod.yml # WITH FACTS real 0m2.547s user 0m1.139s sys 0m0.187s
Exécuter plusieurs lectures
Vous pouvez avoir plus d'un jeu dans le playbook. Comme vous pouvez le voir dans l'image ci-dessous, mon deuxième jeu a une tâche qui va redémarrer le sshd service utilisant le service module dans un autre hôte.
- name: Second Play - Restart SSHD service
hosts: ubuntu1
gather_facts: false
become: yes
tasks:
- name: Restart SSHD in managed1.anslab.com
service:
name: sshd
state: restarted Exécutons à nouveau le playbook et vous pouvez voir à partir de la sortie que les deux jeux sont exécutés avec succès.
$ ansible-playbook banner_mod.yml
Vous devriez maintenant avoir une bonne compréhension de la façon d'écrire un playbook et de l'exécuter. Playbook prend en charge des fonctionnalités utiles supplémentaires que nous verrons dans la section suivante.
Valider la syntaxe du Playbook
Vous pouvez utiliser le --syntax-check flag pour vérifier les éventuelles erreurs de syntaxe dans votre playbook. J'ai volontairement fait une erreur de syntaxe dans le "gather_facts" ligne dans mon playbook.
$ ansible-playbook --syntax-check banner_mod.yml
Demande de confirmation
Lorsque vous utilisez le --step drapeau, pour chaque tâche de votre jeu, il vous demandera de confirmer la poursuite de la tâche.
$ ansible-playbook --step banner_mod.yml
Exécuter une simulation
Au lieu d'exécuter les tâches dans des nœuds gérés, vous pouvez simuler l'exécution en utilisant -C ou --check drapeau.
$ ansible-playbook -C banner_mod.yml
Commencer à partir d'une tâche particulière
Vous avez la possibilité de lancer l'exécution du playbook à partir d'une tâche particulière. Vous pouvez voir sur l'image ci-dessous que j'ai commencé à partir de Play2 (task1), donc la tâche dans play1 est ignorée. Utilisez le drapeau --start-at-task et passez le nom de la tâche comme argument.
$ ansible-playbook banner_mod.yml --start-at-task "Restart SSHD in managed1.anslab.com"
Exécuter la tâche à l'aide de balises
Vous pouvez regrouper les jeux et les tâches avec des tags . À l'aide de balises, vous pouvez exécuter uniquement les tâches avec des balises particulières ou ignorer les tâches.
Vous pouvez jeter un oeil à l'image ci-dessous où j'ai utilisé les "tags" mot-clé et définissez-lui des valeurs. Vous pouvez également ajouter plusieurs valeurs à une seule balise.
Vous pouvez exécuter la commande suivante pour obtenir la liste des tâches avec ses balises.
$ ansible-playbook banner_mod.yml --list-tasks
$ ansible-playbook banner_mod.yml --list-tags
Utilisez -t flag et transmettez les noms des balises comme argument. Vous pouvez soit exécuter une tâche spécifique basée sur des balises, soit plusieurs balises, comme indiqué ci-dessous. Dans l'exemple ci-dessous, j'utilise deux balises différentes de deux lectures différentes.
$ ansible-playbook -t "set_perm","restart service" banner_mod.yml
Vous pouvez également ignorer une tâche et exécuter toutes les autres tâches en utilisant --skip-tags drapeau.
$ ansible-playbook -t "set_perm","restart service" --skip-tags "set_perm" banner_mod.yml
Augmenter la verbosité
Parfois, le playbook ne se comportera pas comme vous l'attendez. Il peut s'agir de quelque chose qui se passe en arrière-plan ou de différentes erreurs.
Pour déboguer le problème, vous pouvez augmenter la verbosité (-v) lors de l'exécution du playbook. Il existe quatre niveaux de verbosité. Vous pouvez soit définir la verbosité dans le ansible.cfg fichier en ajoutant la propriété "verbosity=<level " ou depuis le terminal en utilisant -v ou variable d'environnement ANSIBLE_VERBOSITY.
$ ansible-playbook -vvvv -t "set_perm","restart service" --skip-tags "set_perm" banner_mod.yml # VERBOSE LEVEL SET TO 4(-vvvv)
[OU]
$ ANSIBLE_VERBOSITY=4 ansible-playbook -vvvv -t "set_perm","restart service" --skip-tags "set_perm" banner_mod.yml # VERBOSE LEVEL SET TO 4(ENV VARIABLE)
Contrôler le parallélisme
Lorsque vous exécutez le playbook, ansible exécutera la tâche par lots. Par défaut, ansible exécutera une tâche dans 5 nœuds en parallèle et une fois que toutes les tâches seront terminées dans les 5 nœuds, il passera à l'ensemble suivant de 5 nœuds.
De même, il exécutera une tâche par lots de 5 jusqu'à ce que la tâche soit terminée dans tous les nœuds, puis passera à la tâche suivante et répétera la même étape.
Vous pouvez contrôler le parallélisme et définir le nombre de nœuds à traiter en parallèle en définissant les "forks" paramètre dans le ansible.cfg fichier.
[defaults]
inventory = inventory
host_key_checking = False
forks=20
J'ai défini la valeur de forks sur 20. Il traitera désormais une tâche sur 20 nœuds en parallèle. De même, vous pouvez augmenter/diminuer le nombre en fonction de vos besoins.
Vous pouvez remplacer la valeur définie dans ansible.cfg fichier en passant -f ou --forks drapeau. Lorsque j'exécute la commande suivante, la valeur de fourches de 20 sera remplacée par 15.
$ ansible-playbook banner_mod.yml -f 15
Conclusion
Dans cet article, nous avons vu comment écrire des playbooks Ansible et les différents paramètres et options pris en charge dans les playbooks. Il existe des tonnes d'autres fonctionnalités comme les variables, les conditions, les boucles, etc. qui peuvent être utilisées dans les playbooks que nous aborderons dans nos prochains articles.