Forum Français

Reply
Highlighted

ArubaOS-CX et Ansible - Part 1 : 1ère utilisation

Ansible prend une part importante dans le monde de l'automatisation réseau, et ce pour plusieurs raisons :

- Ansible est connu pour être une technologie très facile à prendre en main, car basé sur YAML, reconnu comme un formatage des données extrêmement simple à lire et comprendre.

- De nombreuses entreprises utilisent déjà Ansible pour le Compute, le Storage ou les environnements virtuels. L'utilisation d'Ansible pour le réseau est donc une capitalisation d'un outil dèjà utilisé, et une extension de l'usage actuel dans un contexte client.

- Le caractère "idempotent" d'Ansible, permettant de ne faire le changement qu'une seule fois, et uniquement s'il doit être fait, même si Ansible réalise plusieurs fois l'action. Ce qui est différent d'une script de commandes CLI (je ne parle pas de REST) qui, quoiqu'il arrive, poussera toujours les lignes de commandes, même si elles sont déjà existantes sur l'équipement cible.

- La possibilité d'utiliser Ansible avec Ansible Tower ou Ansible AWX, qui permet de gérer ces worflows Ansible de manière graphique.

- Le très grand nombre d'options et modules disponibles, permettant de répondre à de très nombreux besoins.

 

Ansible représente donc un bon tremplin pour entrer dans le monde de l'automatisation du réseau.

 

Dans ce sens, Aruba publie depuis maintenant plusieurs mois des modules, librairies et playbook afin de vous aider à prendre la main sur cette technologie.

La dernière publication en date est la publication d'un rôle Ansible pour ArubaOS-CX dans Ansible Galaxy.

 

Nous allons dans ce post voir comment mettre en place Ansible et le rôle AOS-CX.

 

1. Mise en place de l'environnement de travail

 

Il faut tout d'abord savoir qu'Ansible n'est disponible que sur Linux ou MacOS. 

Il n'existe pas de version Windows.

Vous devez donc soit utiliser une VM Linux sur votre poste Windows, soit un serveur dédié.

 

Une fois que vous environnement de base est monté, vous devez réaliser les opérations suivantes :

 

sudo apt install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt update
sudo apt install ansible

Vous venez tout simplement d'installer Ansible sur votre poste/serveur.

L'installation de cet outil est donc extrêmement aisée.

 

Afin de vérifier la version Ansible installée, vous pouvez tout simplement utiliser la commande suivante :

 

root@ansible-srv:/home/ansible# ansible --version
ansible 2.8.6
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.15+ (default, Oct  7 2019, 17:39:04) [GCC 7.4.0]

Nous sommes ici en version 2.8.6, qui est la dernière version disponible.

 

Ce point est important car la notion de rôle a été implémentée à partir de la version 2.7.

Il est donc important de vérifier que vous soyez dans une version >= 2.7, car de nombreuses installations par défaut se font en version 2.5.

En sachant que le role Ansible AOS-CX, que nous allons utiliser dans ce post, nécessite, à minima, la version 2.8.4 d'Ansible.

 

Si vous devez mettre à jour, vous pouvez utilisez la commande :

sudo apt upgrade ansible

Une fois qu'Ansible est installé, et dans la bonne version, il nous faut maintenant installer le rôle AOS-CX.

Dans le monde Ansible, et plus particulièrement Ansible Galaxy, un Role est un ensemble de variables, tâches, etc... facilitant la réutilisation de méthodes ou fonctionnalités. Pourquoi réécrire des choses alors que d'autres l'ont déjà fait ? C'est le principe d'Ansible Galaxy et des Roles.

Dans ce sens, Aruba publie et maintient un Role AOS-CX, afin de faire gagner du temps aux administrateurs, en offrant tout un ensemble d'instructions et d'éléments de configuration.

Nous pourrions comparer cela à un module Python, qui permet de bénéficier de fonctions déjà écrites pour réaliser certaines actions.

 

Nous allons donc nous baser sur ce Role AOS-CX, et pour cela nous installons ce dernier tout simplement au travers de la commande :

 

ansible-galaxy install arubanetworks.aoscx_role

Ce qui donne :

Screenshot 2019-10-18 at 09.26.18.png

 

Pour vérifier que le rôle est bien installé, vous pouvez tout simplement taper la commande "ansible-galaxy list" :

 

root@ansible-srv:/home/ansible# ansible-galaxy list
# /root/.ansible/roles
- arubanetworks.aoscx_role, 1.0.4

Pour information, vous pouvez également faire une recherche dans le repository Ansible Galaxy avec la commande "ansible-galaxy search". Par exemple :

 

root@ansible-srv:/home/ansible# ansible-galaxy search aruba

Found 2 roles matching your search:

 Name                     Description
 ----                     -----------
 arubanetworks.aoscx_role Ansible modules for configuring AOS-CX switches. (github repo - https://github.com/aruba/aoscx-ansible-role)

Voilà notre environnement de travail avec Ansible est maintenant mis en place.

 

Nous allons donc passer à l'utilisation de cet outil.

 

2. Inventory et premières actions

 

Le concept principal d'Ansible est de se baser sur 2 éléments fondamentaux :

- L'inventaire, qui regroupe les éléments/équipements sur lesquels nous souhaitons faire des actions via Ansible, avec les informations relatives, comme l'adressage IP, les credentials si nécessaires, ainsi que d'autres éléments comme par exemple certaines variables.Il est possible d'utiliser celui par défaut, qui est le fichier "hosts", contenu dans /etc/ansible, soit un personnalisé, que vous pouvez positionneer là où vous le souhaitez.

- Les Playbooks, qui représentent globalement le contenu du workflow que l'on souhaite sur tout ou partie des équipements contenus dans l'inventaire.

 

Commencons par créer un fichier inventaire.

Dans cet example, nous allons créer un fichier "inventory.ini", dans lequel nous positionnons notre équipement, un 8320, avec les différentes informations de connexion :

 

8320-lab ansible_host=<ip> ansible_user=<user> ansible_password=<password> ansible_connection=httpapi ansible_network_os=aoscx ansible_httpapi_validate_certs=False ansible_httpapi_use_ssl=True ansible_acx_no_proxy=True

Pour une brève explication, nous indiquons ici que nous souhaitons utiliser le module de connexion "httpapi", en SSL/HTTPS, sans validation de certificat, vers un équipement de type AOS-CX. C'est donc ce qui nous permet de pouvoir indiquer comment nous connecter à l'équipement et comment ouvrir une session REST.

Le module de connexion "httpapi" est un module natif d'Ansible disponible depuis la version 2.6, qui permet de pouvoir interagir avec un équipement via les API en HTTP/HTTPS.

En effet, le rôle AOS-CX est basé sur les APIs, donc sur HTTP/HTTPS, et non sur SSH, comme traidtionnellement avec Ansible.

Notre fichier inventaire est donc prêt.

 

Passons maintenant au Playbook.

Pour notre premier exemple, nous allons juste tester la création d'un VLAN.

Pour cela nous allons créer le fichier "create-vlan.yml", et positionner le contenu suivant :

- hosts: all
  roles:
    - role: arubanetworks.aoscx_role
  tasks:
    - name: Create VLAN 300
      aoscx_vlan:
        vlan_id: "300"
        description: "Through_Ansible"

Un peu d'explications :

- "hosts" : indique vers quels équipements nous souhaitons dérouler le playbook. Ici nous utilisons le mot-clé "all", ce qui indique que nous le faisons vers tous les équipements contenus dans l'inventaire.

- "roles": indique quel role nous souhaitons utiliser, afin de bénéficier des jeux d'instructions déjà créés et récupérés lors de l'installation du rôle.

- "tasks": représente le jeu d'actions que nous allons dérouler. Ici, nous indiquons que nous avons une tâche "Create VLAN 300", qui utiliser l'instruction "aoscx_vlan", contenu dans le rôle AOS-CX, et que nous lui passons les valeurs "vlan_id" et "name".

 

YAML est très sensible aux indentations, et par conséquent Ansible également. Faites donc très attention à cela lorsque vous créer/modifier vos playbooks, en n'utilisant pas de tabulations, uniquement des espaces.

Une fois que nous avons nos deux fichiers, il suffit alors de taper la commande suivante pour lancer le workflow :

ansible-playbook create-vlan.yml -i inventory.ini

Et voilà le résultat :

Screenshot 2019-10-18 at 09.37.39.png

 

Si nous décryptons un peu ce qui est affiché :

- "PLAY [all]" : indique que le Playbook va être lancé sur tous les équipements contenus dans l'inventaire.

- "TASK [Gathering Facts]" : Cette partie est inhérente au fonctionnement d'Ansible, et lui permet de récupérer des informations sur les équipements auxquels il doit se connecter. Cette étape peut être retirée en spécifiant "gather_facts: no" dans votre playbook.

- "TASK ['Create VLAN']" : Execution de la tâche que nous avons mis dans notre playbook. Ici "Create VLAN".

- "PLAY RECAP" : Récapitulatif du fonctionnement du workflow sur les différents équipements.

 

Sur ce dernier point, plusieurs statuts sont disponibles. Notamment, dans notre cas :

- "ok" : La configuration sur l'équipement est déjà celle attendue, donc pas d'action prise. C'est le caractère "idempotent" d'Ansible.

- "changed" : La configuration que l'on souhaite appliquer n'existe pas sur l'équipement, donc on l'applique.

 

Voici un résumé complet des différents status disponibles :

- "Changed" : L'équipement n'a pas la configuration, Ansible l'applique. Si la configuration cible est déjà présente, mais de manière plus évoluée, alors Ansible n'applique les changement que sur la partie ciblée de la configuration.

- "Skipped", ou "Ok" : La configuration cible est déjà sur l'équipement, Ansible ne fait rien.

- "Unreachable" : Ansible ne peut se connecter à l'équipement cible.

- "Failed" : Le module utilisé dans le playbook n'a pas réussi à s'exécuter. Ansible arrête alors l'éxecution du Playbook.

 

Il est à noter que pour avoir des éléments de debug plus avancés, vous pouvez utiliser les extensions "-v" lorsque vous lancer votre playbook.

Plus vous utilisez de "v" dans l'extension, plus le debug sera verbeux - Par exemple, avec 

ansible-playbook create-vlan.yml -i inventory.ini -vv

Screenshot 2019-10-18 at 09.38.06.png

 

Nous venons donc de créer le VLAN 300 sur notre 8320, sans avoir à gérer les ouvertures de sessions, et le remplissage du JSON.

Si nous contrôlons sur l'équipement :

Screenshot 2019-10-18 at 09.42.17.png

 

3. Allons un peu plus loin

 

a. Faire plusieurs tâches dans un même workflow/playbook.

 

Augmentons un peu plus la complexité de notre workflow en ajoutant les étapes suivantes :

- Création de la VRF "test"

- Création du VLAN 301

- Création de l'interface VLAN 301, avec son adresse IP, et rattachement de cette nouvelle interface à la VRF "test".

 

Pour cela, modifions notre playbook de la manière suivante :

 

- hosts: all
  roles:
    - role: arubanetworks.aoscx_role
  tasks:
    - name: Create VRF Test
      aoscx_vrf:
        name: test
    - name: Create VLAN 301
      aoscx_vlan:
        vlan_id: "301"
        name: "Through_Ansible_vrf_test"
    - name: Create Int VLAN 301 and put it in VRF Test
      aoscx_vlan_interface:
        vlan_id: "301"
        admin_state: up
        ipv4: ["10.2.3.254/24"]
        vrf: test

Que faisons-nous ici :

Nous rajoutons 2 tâches, permettant de répondre au besoin de créations de la VRF test et de l'interface VLAN 301. Pour cela, nous utilisons les instructions "aoscx_vrf" et "aoscx_vlan_interface", et nous leur positionnons les valeurs que nous souhaitons.

 

Si on lance de nouveau le playbook :

 

ansible-playbook create-vlan-vrf.yml -i inventory.ini

Voici le résultat :

Screenshot 2019-10-18 at 09.51.19.png

 

Nous venons donc de créer de manière extrêmement simple un VLAN, une interface VLAN, une VRF et attaché ces deux derniers éléments, sans risque d'erreur.

 

Si on contrôle sur l'équipement :

Screenshot 2019-10-18 at 17.32.30.png

b. Multiple équipements

 

Mais le but d'Ansible n'est bien entendu pas de faire des actions sur un seul équipement. Nous allons donc en intégrer 2 de plus :

 

[lab]
8320-lab ansible_host=<ip> ansible_user=admin ansible_password=<password> ansible_connection=httpapi ansible_network_os=aoscx ansible_httpapi_validate_certs=False ansible_httpapi_use_ssl=True ansible_acx_no_proxy=True ip=10.2.3.254/24

[showroom]
8320-Primary ansible_host=<ip> ansible_user=admin ansible_password=<password> ansible_connection=httpapi ansible_network_os=aoscx ansible_httpapi_validate_certs=False ansible_httpapi_use_ssl=True ansible_acx_no_proxy=True ip=10.2.3.2/24
8320-Secondary ansible_host=<ip> ansible_user=admin ansible_password=<password> ansible_connection=httpapi ansible_network_os=aoscx ansible_httpapi_validate_certs=False ansible_httpapi_use_ssl=True ansible_acx_no_proxy=True ip=10.2.3.3/24

Vous remarquerez que :

- Nous avons categoriser nos équipements, en positionnant certains équipements dans une categorie "[lab]" et d'autres dans une categorie "[showroom]". Ces catégories sont appelées des groupes.

Cela représente bien entendu un intérêt que nous allons voir dans quelques secondes.

- Nous avons ajouter la variable "ip", avec des valeurs associées. Ces valeurs seront utilisées dans notre nouveau playbook. En effet, puisque nous avons plusieurs équipements, la valeur "ip" ne peut être identique pour tout le monde. Nous créons donc cette variable pour chaque équipement, et le playbook ira automatiquement la chercher dans le fichier inventaire.

 

Modifions donc notre playbook de manière à réaliser notre workflow uniquement sur les 2 équipements que nous venons de rajouter :

 

- hosts:
    8320-Primary
    8320-Secondary
  roles:
    - role: arubanetworks.aoscx_role
  tasks:
    - name: Create VRF Test
      aoscx_vrf:
        name: test
    - name: Create VLAN 301
      aoscx_vlan:
        vlan_id: "301"
        name: "Through_Ansible_vrf_test"
    - name: Create Int VLAN 301 and put it in VRF Test
      aoscx_vlan_interface:
        vlan_id: "301"
        admin_state: up
        ipv4: ["{{ip}}"]
        vrf: test

 

ici :

- Nous spécifions nos 2 équipements à prendre en compte dans l'inventaire.

- Nous indiquons que la variable "ip" doit être prise en compte, en utilisant le formalisme suivante : {{ <variable> }}

 

Si nous lancons de nouveau notre playbook :

Screenshot 2019-10-18 at 11.07.15.png

 

Et si nous contrôlons sur les équipements :

Screenshot 2019-10-18 at 17.37.49.png

 

Si nous modifions très légèrement notre playbook de la manière suivante :

- hosts: showroom

Alors le playbook ira automatiquement prendre l'ensemble des équipements compris dans la catégorie "showroom", que nous avons créée dans notre fichier inventaire.

 

4. Ressources

 

De très nombreuse ressources sur l'utilisation d'Ansible avec les solutions Aruba sont disponibles :

- Github Aruba 

- Chaîne Youtube ABC - Playlist Ansible 

- Forum Airheads "Developer Community" 

- Replay de la session de Tiffany Chiapuzio-Wong (TME Automation chez Aruba) sur Ansible et Aruba à l'AnsibleFest 2019 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: