9

Ansible est un outil puissant permettant d’automatiser de nombreuses tâches. Ce qui le différencie des produits tels que Puppet ou Chef, c’est qu’il est, tout d’abord, Agent-Less, c’est-à-dire que les cibles n’ont pas d’agent pour remonter des informations et qu’il travaille en mode « Push », par opposition au mode « Pull » de la plupart de ses concurrents. Il utilise uniquement la connexion SSH avec un échange préalable de clé.

Génération d’une clé SSH (type RSA – 4096 bits) :

ssh-keygen -t rsa -b 4096

On lui renseigne un passphrase et il nous génère un fichier id_rsa => clef privé & id_rsa.pub => clef publique.

Une fois le couple de clés généré sur le serveur Ansible, nous allons procéder au transfert de la clé publique sur les cibles :

ssh-copy-id -i .ssh/id_rsa.pub user@serveur_distant

Une fois la clé publique copiée sur chaque cible, nous pouvons utiliser un agent SSH pour ne pas avoir à retaper systématiquement le passphrase :

eval `ssh-agent -s`
ssh-add ~/.ssh/id_rsa

Ansible peut être utilisé pour gérer à la fois des serveurs, des switchs, des routeurs, où tous les équipements permettant au moins une connexion SSH et possédant un interpréteur Python.

Sa syntaxe est assez simple et sommaire, mais nécessite une certaine rigueur au risque de générer des erreurs lors de l’exécution d’un « Playbook ». Il utilise la syntaxe YAML pour fonctionner.

Pour débuter rapidement avec Ansible, il faut configurer un fichier « Inventory ». Le plus simple est de prendre le nom par défaut « hosts ». Ce fichier peut se trouver dans le répertoire de travail ou on peut utiliser /etc/ansible/hosts fourni dans le package d’installation. La meilleure pratique étant de ne pas modifier les fichiers livrés dans l’installation, les fichiers ansible.cfg et hosts sont créés dans le répertoire de travail. Si on ne possède pas de serveur DNS, idéalement géré par Ansible, on peut renseigner le fichier /etc/hosts.

Exemple de contenu du fichier local ansible.cfg :

[defaults]
inventory = ./hosts
host_key_checking = false
timeout = 5

Exemple de contenu du fichier local hosts :

[Ansible]
overwatch

[Apache]
overwatch

[ios_switch]
192.168.122.10

Exemple de contenu du fichier /etc/hosts :

127.0.0.1 localhost
192.168.1.50 overwatch

Note : Dans notre exemple, il n’y a pas de domaine configuré sur la VM de test.

On note que le fichier local hosts fait apparaître un groupe Ansible contenant la machine overwatch, qui est à la fois en charge d’être le serveur Ansible et le serveur Web (Apache).

Ansible peut être utilisé de plusieurs manières, la méthode basique étant le mode commande, pour tester que tous les serveurs répondent.

ansible Apache -m ping

overwatch | SUCCESS => {
 "changed": false,
 "ping": "pong"
 }

Il faut noter que la fonction ping d’Ansible n’a pas de rapport avec la fonction réseau ping. En effet, son utilisation implique la présence d’un interpréteur Python sur la cible, présence qui est contrôlée avant de générer un pong en réponse favorable.

Pour tester le bon fonctionnement face à un commutateur, le plus simple est d’utiliser les commandes « Ad-Hoc » qui s’écrivent directement en une ligne. En supposant que le commutateur a bien été configuré pour un accès SSH, la commande suivante permet de récupérer sa configuration avec un accès par utilisateur/mot de passe et non par clé :

ansible ios_switch -m raw -a "show run" -u myuser -k | grep "hostname\|username\|address"

Une fois vérifié le bon fonctionnement de l’ensemble, l’étape suivante consiste à s’intéresser à la constitution des « Playbooks ».