Introduction
Si vous avez entendu parler de la possibilité de manager des équipements Cisco via Ansible, et que vous souhaitez le mettre en place dans votre infrastructure, on vous explique comment dans cet article !
Tâches
- Installer Ansible sur la machine de management
- Créer l’inventaire qui décrira les équipements à manager
- Créer un playbook qui exécutera des commandes
Prérequis
- Avoir un équipement Cisco avec un Serveur SSH correctement configuré (tutoriel)
- Avoir une machine (physique ou virtuelle) permettant d’héberger Ansible (Windows, MacOS ou Linux)
Architecture
Voici l’architecture du lab de démonstration mis en place pour cet article :
La machine Ansible (192.168.1.75) est connectée au routeur Cisco (192.168.1.125) via le modem d’un FIA (192.168.1.1). Notez que l’on peut ajouter autant d’équipements Cisco que nécessaire. Dans le contexte d’une démonstration, un seul équipement suffit.
Le routeur sélectionné pour ce lab est un CSR1000V (précédemment Catalyst 8000 Edge), qui a l’avantage d’être virtualisé. Néanmoins tout équipement Cisco supportant SSH peut être utilisé avec Ansible.
Installer Ansible
Cette section décrit brièvement la logique d’Ansible ainsi que de son installation.
Architecture
- Ansible lit les “hosts” dans l’inventaire spécifié.
- Ansible lit les tâches à exécuter dans le “playbook” spécifié.
- Ansible se connecte aux “hosts” et exécute les tâches.
Installer les packages requis
Ci-dessous, un script permettant d’installer tout ce dont Ansible a besoin pour ce lab sur une machine Linux:
# Ansible core
sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible
# Cisco IOS collection
ansible-galaxy collection install cisco.ios
# Python SSHv2 client
pip install paramikoⓘ Pour plus d’information au sujet de l’installation d’Ansible, je vous invite à consulter la documentation officielle Ansible.
Spécifier le chemin de l’inventaire par défaut (optionnel)
Afin d’éviter de spécifier le fichier d’inventaire lors de l’appel d’un “playbook”, l’utilisateur peut configurer l’inventaire par défaut dans le fichier de configuration Ansible “/etc/ansible/ansible.cfg” :
inventory=/home/devnet/Projects/devnet/ansible/inventory/hosts.yaml
Créer l’inventaire
L’inventaire Ansible nous permet de référencer les équipements que l’on souhaite manager via ce dernier.
Cet inventaire peut prendre différents formats (INI, YAML, …). Etant donné que YAML est souvent utilisé pour configurations réseaux, l’inventaire sera spécifié en YAML :
Inventaire: hosts.yaml
---
csrs:
hosts:
csr1:
ansible_port: 22
ansible_host: 192.168.1.125
ansible_ssh_user: devnet
ansible_ssh_pass: devnet
ansible_network_os: ios
...⚠️ L’inventaire contient des informations sensibles au sujet de votre parc informatique (noms d’équipements, noms d’utilisateurs, mots de passe, ports, adresses IP/MAC, …). Si vous souhaitez partager vos inventaires (comme sur GitHub), une bonne méthode est d’utiliser des variables d’environnements, ce qui permet de masquer partiellement ou totalement les informations concernant vos équipements.
Inventaire (avec variables d’environnements) : hosts.yaml
---
csrs:
hosts:
csr1:
ansible_port: "{{ lookup('env', 'CSR1_SSH_PORT') }}"
ansible_host: "{{ lookup('env', 'CSR1_HOST') | ipaddr }}"
ansible_ssh_user: "{{ lookup('env', 'CSR1_SSH_USER') }}"
ansible_ssh_pass: "{{ lookup('env', 'CSR1_SSH_PASS') }}"
ansible_network_os: "{{ lookup('env', 'CSR1_OS') }}"
...
Créer un playbook
C’est dans le “playbook” que nous allons spécifier les tâches à exécuter sur les équipements de notre inventaire.
Prenons un cas d’usage simple, NETCONF.
Si nous tentons de récupérer les capacités NETCONF de l’équipement Cisco (pour ce faire, IOS-XE 16.3.3 ou supérieur est requis), nous remarquons que l’équipement Cisco refuse la connexion :
devnet@devnet:~/Ansible$ ssh -p 830 -s devnet@192.168.1.125 netconf
kex_exchange_identification: read: Connection reset by peer
X Le service NETCONF n’est pas activé par défaut sur les CSR1000V.
Malgré le fait que NETCONF repose sur SSH pour le transport de ses messages, cela ne signifie par qu’il opère sur le port 22. En effet, NETCONF utilise le port 830 par défaut, qui n’est par conséquent pas accessible puisque le service NETCONF n’est pas démarré.
Ainsi, le cas d’usage de notre “playbook” sera d’activer NETCONF sur le CSR1000V, via la commande “netconf-yang“, puis de vérifier le bon fonctionnement du service NETCONF via la commande ‘show netconf-yang status” :
Playbook : enableNetconf.yml
---
- name: enable netconf-yang on csr1
hosts: csr1
connection: network_cli
tasks:
- name: configuration commands
ios_config:
lines:
- netconf-yang
- name: show commands
ios_command:
commands:
- show netconf-yang status
...Exécutons maintenant le “playbook”:
devnet@devnet:~/Ansible$ ansible-playbook enableNetconf.yml -v
Using /etc/ansible/ansible.cfg as config file
PLAY [enable netconf-yang on csr1]
*********************************************
TASK [Gathering Facts]
*********************************************
ok: [csr1]
TASK [configuration commands]
*********************************************
changed: [csr1] =>
{
"changed":true,
"commands":[
"netconf-yang"
],
"updates":[
"netconf-yang"
]
}
TASK [show commands]
*********************************************
ok: [csr1] =>
{
"changed":false,
"stdout":[
"netconf-yang: enabled\nnetconf-yang ssh port: 830\nnetconf-yang candidate-datastore: disabled"
],
"stdout_lines":[
[
"netconf-yang: enabled",
"netconf-yang ssh port: 830",
"netconf-yang candidate-datastore: disabled"
]
]
}
PLAY RECAP
*********************************************
csr1: ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Maintenant nous pouvons tenter une nouvelle fois d’obtenir les capacités NETCONF de notre équipement:
devnet@devnet:~/Ansible$ ssh -p 830 -s devnet@192.168.1.125 netconf
devnet@192.168.1.125's password:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
--- OMITTED OUTPUT ---
NETCONF est maintenant correctement configuré.
ⓘ Une bonne pratique est de sauvegarder tout changement de configuration. Un exemple de “playbook” sauvegardant la “running configuration” est disponible ici.
Conclusion
A travers ce cas d’usage très simple, vous avez vu les bases de l’automatisation d’équipements Cisco, comme un Cloud Services Router 1000V (CSR1000V), via Ansible. Vous pouvez maintenant imaginer des cas d’usages plus complexes, comme une configuration DMVPN, la mise en place d’ACL et de QoS, … le tout sur un plus grand nombre d’équipements.
Limites d’Ansible
Bien qu’Ansible nous permette d’automatiser certaines tâches sur certains équipements, il présente cependant certaines limites :
- Ansible ne propose pas d’interface utilisateur graphique.
- Ansible ne se base pas sur un modèle de données standardisé (tel que YANG pour le réseau).
- Ansible ne propose pas de support (Open Source)
- Ansible ne propose pas de haute-disponibilité (HA) par défaut
Impact des limites d’Ansible sur les opérations de l’infrastructure utilisateur
Prenons l’exemple d’un réseau entreprise typique, avec des équipements hétérogènes.
L’administrateur de ce réseau devra donc créer et maintenir manuellement autant d’inventaires et de playbooks qu’il possède d’équipements différents (multi-vendeurs, multi-pateformes, multi-images).
Ainsi, le risque d’erreurs devient non-négligeable. Notons que la propagation de ces erreurs peut se faire très facilement, puisqu’Ansible a pour rôle d’automatiser le déploiement de configurations. De cette manière, le réseau de l’entreprise sera inopérant, dans un état méconnu voir inconnu.
Qu’en est-il du “rollback”? Une fois encore, l’administrateur aura la responsabilité d’implémenter autant de “playbooks” de “rollbacks” qu’il y a d’équipements différents.
Et si le rollback ne fonctionne pas? Et si le troubleshooting du réseau devient trop complexe? Les conséquences sur l’entreprise peuvent être significatives, et cette dernière se retrouvera sans support constructeur.
De ces exemples, nous comprenons que le coût opérationnel (OpEx) d’Ansible peut très vite défavorablement contrebalancer son faible coût d’acquisition (CapEx).
Solutions Cisco
Les solutions Cisco, quant à elles, vous permettent de vous affranchir de ces complexités, en vous donnant une très large gamme d’outils clés en main, pour manager et assurer votre réseau.
Pour plus d’information, je vous invite à vous renseigner sur Catalyst Center, l’outil “Intent-Based Networking” Cisco pour les réseaux d’entreprises.
Note: DNA Center s’intègre maintenant avec Ansible, ce qui rend les deux solution complémentaire! Un article sur l’intégration de DNA Center avec Ansible est en cours. Si vous souhaitez plus d’information à ce sujet, je vous invite a consulter l’article sur Ansiblefest: Do I choose Ansible, DNA Center, or both? Both!
Authors
1 commentaires