Playbooks simples 1

Cet article a été initialement écrit sur le blog-libre aujourd’hui fermé, certains liens dans l’article peuvent donc être morts.


On rentre dans le vif du sujet. Je vous ai quasi-exclusivement présenté la seule commande ansible mais celle qui fait toute la force d’Ansible, c’est la commande ansible-playbook.

Un playbook, c’est un livre de recettes en bon Français, ça utilise la syntaxe YAML dont le but est d’être simple et le plus lisible possible par des humains. On va commencer par des playbooks simples, je ne rentrerai volontairement pas dans toute la puissance des playbooks. Mon but c’est de vous donner les bases pour vous simplifier l’administration de vos postes et on va voir des exemples pour essayer d’être le plus didactique possible.

Voici déjà quelques commandes de base.

Pour toutes les commandes ci-dessous, on se place dans le dossier /etc/ansible.

Utilisation du playbook : ansible-playbook script.yml
Utilité du playbook : Lancer un script sur le(s) client(s), le module script fourni par Ansible copie le script sur la machine distante et l’exécute
Playbook script.yml

Explications : Un fichier YAML (extension yml) débute toujours par trois tirets, c’est une convention. On voit ensuite qu’on nomme la tâche (vous pouvez évidemment écrire un truc en Français), on renseigne le host sur lequel on souhaite que s’exécute le playbook. Enfin, on définit la tâche à accomplir. Comme on peut le voir, la syntaxe est très simple et très claire. Méfiez-vous surtout des espaces et saut de lignes, ça peut mettre votre playbook en erreur. Il faut évidemment que vous ayez un script nommé script.sh et étant donné qu’on lance la commande dans le dossier /etc/ansible alors vous devez avoir créé un dossier files dans lequel se trouve un fichier script.sh (en deux mots vous devez avoir : /etc/ansible/files/script.sh)

Utilisation du playbook : ansible-playbook apt_key.yml
Utilité du playbook : Ajouter la clé d’un dépôt sur le(s) client(s), le module apt-key fourni par Ansible fait cela
Playbook apt_key.yml

Explications : Cette fois-ci, notre playbook concerne non pas un seul host mais un groupe (server), on peut mettre un host, un groupe (ou sous-groupe), all pour tous les hosts. Précédemment nous avions script: et là nous avons apt_key:, c’est à chaque fois le module que nous utilisons. Avec la commande ansible, cela donnerait ansible server -m script etc. et ansible server -m apt_key etc.

Vous remarquerez le state=present et là on va sortir le terme magique Idempotence. D’après Wikipédia, le concept d?’idempotence signifie essentiellement qu’une opération a le même effet qu’on l’applique une ou plusieurs fois, ou encore qu’en la réappliquant on ne modifiera pas le résultat. Ansible est idempotent càd que si vous lancez votre playbook apt_key.yml une première fois, les hosts du groupe server vont récupérer la clé du dépôt Dotdeb. Si vous relancez le playbook apt_key.yml, les hosts du groupe server ne feront rien, la clé est déjà installée càd que le déroulement du playbook sera immédiat. Pour faire simple, la tâche d’ajouter la clé du dépôt Dotdeb n’est faite qu’une seule et unique fois. Ansible est intelligent.

Utilisation du playbook : ansible-playbook clamscan.yml -e host=SRV-WEB
Utilité du playbook : Lancer un scan clamav sur le(s) client(s)
Playbook clamav.yml

Explications : Comme on peut le voir on utilise le module command pour lancer la commande clamscan. Il est de bon ton de préciser le chemin complet de l’exécutable. La nouveauté c’est bien évidemment « {{ host }} » qui est une variable, elle sera remplacée par SRV-WEB car on a utilisé -e host=SRV-WEB.

Utilisation du playbook : ansible-playbook reboot.yml -e host=all
Utilité du playbook : Rebooter le(s) client(s)
Playbook reboot.yml

Explications : Je pense que ça se passe de commentaires, c’est simple, clair, aisément compréhensible.

Utilisation du playbook :

Utilité du playbook : Copier un fichier (de configuration par exemple) sur le(s) client(s)
Playbook copy.yml

Explications : On a maintenant 3 variables, il est à noter qu’on pourrait évidemment rajouter des variables pour le owner, group et mode mais la plupart du temps ça ne bouge pas beaucoup pour les fichiers de configuration. Remarquez le src=files/, n’oubliez pas de mettre le fichier (ici ntp.conf) dans /etc/ansible/files. L’option backup=yes est une merveille, on comprend tout de suite la puissance de l’idempotence avec. Le fichier ntp.conf n’est pas identique lors du premier lancement du playbook, une sauvegarde de l’ancien fichier est faite puis le nouveau ntp.conf remplace l’ancien. On relance notre playbook, aucune sauvegarde ne sera faite car aucun changement sur le fichier est nécessaire.

Utilisation du playbook : ansible-playbook copy_bash.yml -e host=home
Utilité du playbook : Copier les fichiers de configuration bash pour root
Playbook copy_bash.yml

Explications : On voit ici comment gérer une liste avec la variable {{ item }}.

Utilisation du playbook : ansible-playbook install_packages.yml -e host=all
Utilité du playbook : Installer des packages (on fait un update suivi d’un upgrade auparavant)
Playbook install_packages.yml

Explications : Ansible va installer tous ces packages et une fois fait, il ne le refera plus (–> Idempotence). Le playbook idéal pour avoir vos paquets (de base) sur tous vos postes. L’option cache_valid_time=7200 permet d’éviter de mettre à jour le cache si il est plus récent que 2h (7200 secondes).

Utilisation du playbook : ansible-playbook ssh.yml -e host=PC-PUPUCE
Utilité du playbook : Mettre à jour le fichier sshd_config, en faire une sauvegarde si modification il y a puis redémarrer le service SSH
Playbook ssh.yml

Explications : On voit ici les handlers, une action qui ne sera exécutée que sur notification d’une autre action. Bien-sûr si le fichier sshd_config ne nécessite aucune modification, il n’y a pas de sauvegarde faite et le service SSH n’est pas redémarré. Si le sshd_config nécessite une modification, Ansible fait une sauvegarde de l’ancien sshd_config puis redémarre le service SSH. Attention concernant notify : restart ssh et name: restart ssh, il faut évidemment que ce soit identique. Si vous avez notify : restart ssh et name: restart, ça ne fonctionnera pas.

Utilisation du playbook : ansible-playbook webmin.yml
Utilité du playbook : Installer Webmin
Playbook webmin.yml

Pour clôturer cet article (il serait temps ha ha ha), une synthèse de tout ce qu’on a vu. On verra dans un prochain article des playbooks plus complexes avec Globbing et variables proposées par Ansible.

Sources : http://lesaventuresdeyannigdanslemondeit.blogspot.fr/2014/10/comparaison-de-la-gestion-des-fs-avec.html
https://blog.deimos.fr/category/hi-tech/ansible/

Aucun avis pertinent dans Playbooks simples 1

Laisser un commentaire

indique des champs obligatoire.