Dans l’article précédent, nous avons pu à partir d’une session linux exécuter à distance un show clock sur un routeur : c’est Ansible qui s’est connecté en SSH sur le routeur et a lancé la commande. Il a ensuite fermé la connexion et nous a rendu la main.

A la base, Ansible est un automate qui exécute des commandes à distance via SSH.

La commande était la suivante :

ansible all --inventory="csrv1k-230," --module-name=raw --args="show clock" \
 --extra-vars="ansible_host=10.0.0.230 ansible_user=cisco ansible_ssh_pass=cisco" \
 --ssh-extra-args="-o StrictHostKeyChecking=no"

Et maintenant, nous allons procéder au reverse engineering de cette commande pour bien la comprendre. En d’autres mots, que vient-on de faire ?

En ligne 2, nous retrouvons sans surprise les paramètres identifiés quand nous avons lancé la commande à la main. Ceux-ci sont toutefois encapsulés dans le paramètre extra-vars et sont passés à Ansible via des noms de variable pré-définis :

ansible_host10.0.0.230
ansible_usercisco
ansible_ssh_passcisco

A noter que les noms de variable ansible_ssh_pass et ansible_user ont évolué et dépendent des versions d’Ansible.

Voici la liste des autres paramètres passés :

Nom longNom courtdescription
–module name-mfonction (au sens Ansible) à exécuter
–args-aparamètres du module
–inventory-iLa liste des hosts distants
–extra-vars-einformations additionnelles
–ssh-extra-argsParamétrage de la connexion ssh
allsélections des sites

Ansible.cfg

Réglons tout de suite le sort du paramétrage de ssh. Nous avons utilisé :

–ssh-extra-args= »-o StrictHostKeyChecking=no »

Si nous enlevons ce paramètre, il est probable qu’il ne se passe rien, mais si vous supprimez le fichier des hosts SSH avec lesquels les clefs publiques ont été échangées (~/.ssh/known_hosts), Ansible refuse d’établir la connexion SSH :

screenshot003

Ce choix se défend pour la gestion de serveurs, ce qui, ne l’oublions pas, est le domaine d’Ansible, mais il est plus discutable pour gérer des équipements réseaux et, incontestablement, il va nous embarrasser dans notre environnement de lab.

Aussi nous allons configurer notre station ansible pour qu’elle accepte de se connecter à des hosts SSH quelconques.

Ansible récupère sa configuration dans le fichier

/etc/ansible/ansible.cfg

et la retouche avec le fichier du répertoire courant, s’il existe :

ansible.cfg

Ces fichiers sont organisés avec la syntaxe INI :

[section]
parameter=value

Plutôt que de modifier le fichier partagé par tous les utilisateurs, nous allons créer le fichier ansible.cfg, pour désactiver le contrôle des clefs publiques :

$ echo -e "[defaults]\nhost_key_checking = False\n" > ansible.cfg

De plus, ceux qui utilisent un terminal de fond sombre apprécieront de pouvoir remplacer la colorisation bleu foncé des logs par une couleur plus lisible avec la configuration suivante :

$ echo -e "[colors]\nverbose = bright magenta\n" >> ansible.cfg
screenshot004

Nous avons retrouvé l’environnement de lab qui nous convient et sommes enfin prêts à poursuivre notre tour d’Ansible. J’entends bien les plus râleurs dire « C’est pas trop tôt », mais ils conviendront aussi qu’on apprend mieux quand on est bien installé !

La notion de module

Ansible est développé de façon modulaire. Le moteur délègue les tâches à des modules spécialisés. A ce jour il existe plus de 3000 modules supportés par Ansible (https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html).

Dans notre exemple, nous avons utilisé le module le plus simple raw (cf https://docs.ansible.com/ansible/latest/modules/raw_module.html), qui prend un paramètre [show clock] et l’envoie à travers une session SSH.

Ou en prenant le problème à l’envers, la commande à exécuter est passée via l’argument –-arg [-a] qui sera passé par Ansible au module raw précisé par l’argument –module-name [-m].

Soit, avec les notations courtes :

module001

Notre module raw a donc :

  • établi une connexion SSH avec le routeur et envoyé la chaîne « show clock », que le routeur a interprétée
  • lu la sortie renvoyée par le routeur
  • fermé la connexion
  • retourné la sortie du routeur à Ansible

Même si d’autres modules sont plus pertinents pour l’administration réseau, on voit facilement qu’avec ce module élémentaire, on peut lancer bon nombre de commandes sans quitter son terminal linux.

Les données (nom du routeur, adresse IP, compte, …) sont passées au module directement par Ansible, car Ansible considère à raison que ces paramètres appartiennent au moteur, non au module, établissant de ce fait un cloisonnement efficace entre les données et les actions (ce qui fait ma transition vers le prochain article).

Author

Philippe est architecte réseau chez un opérateur depuis 20 ans. Il a le double rôle de concevoir des réseaux pour les clients, puis de les faire fonctionner. Bien que passionné par l'innovation, il reste un fervent supporter de la RFC 1925 et garde tout son sens critique par rapport au hype et aux promesses féeriques des constructeurs. Ancien développeur, il tente de garder la main en programmant des Arduino en C ou des utilitaires opensource en Ruby. On peut également le croiser en randonnée dans les collines ou dans un club de bridge.

Write A Comment