Comment automatiser l’administration du réseau avec Ansible

Le principe de fonctionnement

Le premier bon réflexe consiste à construire une hiérarchie de répertoires pour séparer les différents types de données de configuration que nous allons créer, afin d’éviter un enchevêtrement de fichiers qui pourrait nuire à la compréhension de ce que nous faisons. Dans notre exemple, nous utiliserons la structure de répertoires et de fichiers suivante :

├── ansible.cfg
├── group_vars
│   ├── IOS_switches.yml
├── host_vars
│   └── test_sw.yml
├── inventory.yml
└── sh_arp.yml

Le fichier ansible.cfg contient la configuration même d’Ansible. Les valeurs par défaut, issues de l’environnement Ansible, étant souvent le meilleur choix, il n’est pas systématiquement nécessaire de recréer ici ce fichier. Sachez qu’il est au format INI, lequel utilise la syntaxe nom = valeur. Par défaut, la collecte de données depuis les périphériques est désactivée (gathering = explicit) parce qu’elle n’est pas pensée pour des équipements réseau. Le nom du fichier d’inventaire est indiqué et les tentatives supplémentaires de communication sont désactivées :

     1  [defaults]
     2  gathering = explicit
     3  inventory = inventory.yml
     4  retry_files_enabled = False

Le répertoire group_vars contient tous les fichiers qui définissent des variables pour un groupe de plusieurs équipements. Nous allons par exemple mettre dans ce répertoire un fichier IOS_switches.yml au format YAML qui contiendra des variables valables pour tous les équipements réseau fonctionnant sous IOS, le système d’exploitation de Cisco.

Dans ce fichier, nous indiquons qu’il faut utiliser le module Ansible network_cli, que le système d’exploitation cible est ios et nous précisons les identifiants de connexion. Pour la sécurité de la connexion, il est recommandé d’utiliser soit des coffres-forts Ansible, soit des clés SSH ; dans les deux cas, les informations d’identification ne doivent pas être présentées en clair dans un fichier en texte clair. Mais dans le cadre de notre initiation, il est plus simple de le faire :

     1  ---
     2  # IOS_switches variables
     3  ansible_connection: network_cli
     4  ansible_network_os: ios
     5  ansible_become: yes
     6  ansible_become_method: enable
     7  ansible_become_password: "foobar"
     8  
     9  ansible_user: tester
    10  ansible_ssh_pass: foobar

Le répertoire host_vars contient les fichiers de définition de variables spécifiques à chaque équipement (chaque « hôte »). On trouvera typiquement dans un tel fichier le nom d’hôte de cet équipement et l’adresse IP à utiliser pour son administration. Les variables présentes dans ces fichiers remplacent les variables de groupe qui portent le même nom, ce qui permet de définir une variable générique et de la remplacer au cas par cas. Voici par exemple la structure test_sw.yml :

     1  ---
     2  # test_sw variables
     3  ipaddr: 192.168.1.108
     4  hostname: test_sw

Le fichier inventory.yml est l’inventaire des équipements, rangés dans des groupes, en utilisant le format YAML. Les équipements peuvent être contenus dans plusieurs groupes. Le matériel test_sw est ainsi membre des groupes IOS_switches et access.

     1  ---
     2  all:
     3    children:
     4      IOS_switches:
     5        hosts:
     6          test_sw
     7      IOS_routers:
     8        hosts:
     9          router1
    10      access:
    11        hosts:
    12          test_sw
    13      core:
    14        hosts:
    15          router1

Enfin, le fichier sh_arp.yml, toujours au format YAML, est ce qu’on appelle un playbook Ansible. C’est lui qui contrôle l’exécution de la tâche d’automatisation. Dans notre exemple, c’est lui qui indique comment récupérer la table ARP et comment afficher le résultat (la « sortie »). Un playbook peut contenir plusieurs « jeux » (« play » en anglais), et chaque jeu peut contenir plusieurs tâches.

Ci-dessous, nous appelons notre jeu « Gather ARP data ». Les hôtes concernés sont ceux qui sont listés dans le groupe IOS_switches. Ce jeu a deux tâches, chacune avec un nom. Ces noms sont simplement des chaînes de texte qui apparaîtront telles quelles dans la sortie. Dans la tâche 1, le module ios_command est utilisé pour exécuter la commande show arp. Le registre des directives est utilisé pour stocker la sortie de ios_command dans une variable Ansible nommée cli_result.

La tâche 2 affiche simplement le résultat qui a été stocké, en se référant à la liste stdout_lines qui se trouve dans cli_result.

     1  ---
     2  - name: Gather ARP data
     3    hosts: IOS_switches
     4    tasks:
     5      - name: "Task 1: Get output of show arp on IOS"
     6        ios_command:
     7          commands: "show arp"
     8        register: cli_result
     9  
    10      - name: "Task 2: Display stdout_lines[0]"
    11        debug:
    12          msg: "{{ cli_result.stdout_lines[0] }}"

Ci-dessous, nous lançons le script Ansible.

     1     $ ansible-playbook sh_arp.yml
     2     
     3     PLAY [Gather ARP data] ***************************************************
     4     
     5     TASK [Task 1: Get output of show arp on IOS] *****************************
     6     ok: [test_sw]
     7     
     8     TASK [Task 2: Display stdout_lines[0]] ***********************************
     9     ok: [test_sw] => {
    10         "msg": [
    11             "Protocol  Address     Age (min)  Hardware Addr   Type   Interface",
    12             "Internet  192.168.1.108      -   bcc4.933e.49c0  ARPA   Vlan1",
    13             "Internet  192.168.1.126      5   f894.c220.2177  ARPA   Vlan1",
    14             "Internet  192.168.1.133      1   88c2.55fb.9ce7  ARPA   Vlan1",
    15             "Internet  192.168.1.138      0   a860.b60a.7a3a  ARPA   Vlan1"
    16         ]
    17     }
    18     
    19     PLAY RECAP ***************************************************************
    20     test_sw                    : ok=2    changed=0    unreachable=0    failed=0   
    21    

Ansible sur plusieurs appareils

Automatiser le réseau avec Ansible ne consiste bien évidemment pas à exécuter une seule commande sur un seul appareil, mais des jeux de commandes sur plusieurs. Ainsi, utilisez l’exemple ci-dessus afin d’exécuter sur votre réseau plusieurs commandes show et stockez les résultats dans des fichiers. Cela vous permettra ensuite d’utiliser de simples expressions de recherche grep pour trouver des modèles spécifiques parmi des centaines de fichiers.

Par exemple, vous conserverez des copies du résultat de show version sur chaque équipement afin de documenter les appareils de votre réseau et leurs numéros de série. Vous pouvez aussi sauvegarder le résultat des commandes show arp et show mac address dynamic pour, ultérieurement, retrouver simplement où un périphérique est connecté dans votre réseau.

Avec ces jeux de commandes, Ansible permet aussi de sauvegarder dynamiquement les configurations de nombreux appareils. Ensuite, vous pourrez vous en servir pour les redéployer, pour les industrialiser sur plusieurs équipements afin de maintenir une qualité de service et un routage précis, ou pour les comparer avec celles en production, afin de vérifier que les configurations de votre réseau restent conformes à votre design, qu’elles ont été rechargées correctement.

Les playbooks font d’excellentes tâches préétablies, mais il existe aussi un mode ad hoc pour automatiser l’exécution d’une même commande sur de nombreux appareils. Des filtres, des analyseurs et des plugins sont par ailleurs disponibles pour affiner les traitements.

Pour aller plus loin, nous vous conseillons de suivre les cours (en anglais) Automating Networks with Ansible the Right Way de Nick Russo.