Forum Français

Reply
Highlighted
Aruba Employee

ArubaOS-CX et l'automatisation - Part 1 : Les APIs et le Swagger

Toujours dans cette volonté de rendre ses solutions le plus programmable possible, et donc automatisables et integrables facilement dans des solutions tierces, afin d'obtenir une infrastructure encore plus agile, Aruba a, au travers du nouvel OS ArubaOS-CX, permis d'aller encore plus loin dans cette stratégie, en permettant d'avoir un OS rendant les équipements totalement programmables, aussi bien d'un point de vue Software que Hardware.

 

Screen Shot 2018-11-30 at 16.13.45.png

 

Cette capacité se traduit par plusieurs aspects, comme :

  • Les API REST embarquées
  • Le Network Analytics Engine
  • Les Websockets

Nous allons donc, au travers de plusieurs posts, découvrir ces fonctionnalités, en commençant ici par la découverte des API REST, et leur puissance.

 

1. Comment activer l'accès aux APIs d'ArubaOS-CX

 

Par défaut, l'accès aux APIs d'ArubaOS-CX n'est pas autorisé.

Pour l'activer, il est nécessaire de réaliser/valider certains aspects de configuration.

3 choses sont obligatoires :

  • Le HTTPS-Server doit être activé
  • L'acces aux REST API doit être activé
  • Un utilisateur doitêtre présent (Soit via une authentification locale ou une authentification via TACACS ou RADIUS)

Mais ces 3 éléments sont extrêmement simples à mettre en place :

 

Switch(config)# user <votre_user> password plaintext <votre_password>
Switch(config)# https-server vrf default
Switch(config)# https-server rest access-mode read-write

Pour vérifier la bonne activation, vous pouvez utiliser la commande suivante :

 

Switch# show https-server

HTTPS Server Configuration
----------------------------
 VRF               : mgmt, default

 REST Access Mode  : read-write

Attention : Le nombre de sessions simultanées sur ArubaOS-CX est limité à 2.

 

Si ces deux sessions sont prises, par exemple parce que des sessions précédentes ont été mal fermées, il est possible de détruire les sessions en cours, en utilisant la commande suivante :

 

Switch# https-server session close all

2. Acces aux APIs via WebUI

 

L'accès aux APIs via WebUI se fait de manière extrêmement simple.

A partir de maintenant, vous pouvez prendre la main sur votre équipement via l’interface HTTPS, et de fait accéder à l’interface Swagger :Screen Shot 2018-11-30 at 14.32.35.pngLorsque vous avez cliqué sur ce lien, vous aurez alors accès au Swagger d'ArubaOS-CX :Screen Shot 2018-11-30 at 14.32.45.png

ArubaOS-CX utilise un mode d’authentification pour l’accès aux APIs basé sur la création d’un cookie persistant.

 

Cette méthode implique qu’un cookie est généré lorsque l’authentification est réussie, et que ce dernier est alors géré par le navigateur.

 

Cela implique que lorsque vous accédez au Swagger après avoir ouvert une session sur l’interface web de management, vous n’avez pas besoin de vous réauthentifier, puisque le cookie est déjà présent dans le navigateur.

 

Cependant, si au contraire vous accédez au Swagger sans être passé par l’interface web de management (ce qui est possible, en tapant : https://<votre _switch>/api/), vous devez ouvrir une session, au travers de l’URI “login” :

Screen Shot 2018-11-30 at 14.33.39.png

Si l’authentification est réussie, vous obtenez alors un « Response Code » de 200, qui indique que l’objet session a bien été créé – Vous observerez que le « Response Body » ne possède aucun contenu.

Screen Shot 2018-11-30 at 14.39.09.png

 

Vous avez maintenant accès aux API d’ArubaOS-CX.

 

Au travers du Swagger d’ArubaOS-CX, vous avez accès à l’ensemble des API disponibles.

Afin de manipuler les APIs, 3 notions sont importantes à connaitre :

  • Attributes : Cette option de requête permet de sélectionner les valeurs que l’on souhaite récupérer au travers de la requête. Par défaut, toutes les valeurs de la ressource seront renvoyées.
  • Filters : Cette option de requête permet d’intégrer des notions de filtre sur des attributs. Par défaut, aucun filtre n’est appliqué.
  • Depth : Cette option permet de déterminer la profondeur des résultats renvoyés. Plus la profondeur est élevée, plus il y aura d’informations renvoyées. Par défaut fixée à 0 – Seule le nom du dictionnaire est renvoyé.

Prenons un exemple :

Sélectionnons l’API VLAN, méthode GET :Screen Shot 2018-11-30 at 14.40.27.png

Si on clique sur "Submit" en laissant tout par défaut, vous observerez qu'il y a assez peu d'informations remontées :Screen Shot 2018-11-30 at 16.02.02.png

 Maintenant, mettons 1 comme valeur dans le champs “depth”.

 

Screen Shot 2018-11-30 at 15.11.36.png

 

Nous avons maintenant de quoi exploiter plus précisément cette API.

Vous pouvez modifier cette valeur, jusqu’à 3, pour voir la différence.

 

Maintenant, en laissant la valeur “depth” sur 1, sélectionnons les attributs “id”, “name” et “type” :Screen Shot 2018-11-30 at 16.04.59.png

 Maintenant, appliquons un filtre, en mettant le VLAN_ID que nous recherchons sur notre équipement, comme “id”.

 

Screen Shot 2018-11-30 at 14.40.45.png

Voici ce que nous devons obtenir :Screen Shot 2018-11-30 at 14.40.49.png

Il est également important de voir que ces options sont disponibles au travers des URI que vous utiliserez dans vos différentes requêtes :

Screen Shot 2018-11-30 at 14.40.54.png

 

Lorsque vous utilisez lez API d’ArubaOS-CX, l’ensemble des informations liées à la ressource recherchée sont retournées.

Par exemple, lorsque l’on fait une requête pour un VLAN, vous obtenez les informations de configuration, mais également les informations de statut et les statistiques – Ce qui explique le côté extrêmement complet des JSON retournés.

 

Vous avez la possibilité de sélectionner le type, ou catégorie, d’informations que vous souhaitez obtenir, en utilisant le champs « selector ».

Remettons à zéro les filtres et attributs que nous avions sélectionnés, et remplissons le champs « selector » avec « configuration », comme par exemple ici un VLAN particulier :

Screen Shot 2018-11-30 at 14.41.02.png

Vous devez alors obtenir un résultat équivalent à ce qui suit :Screen Shot 2018-11-30 at 14.41.09.png

 

Vous obtenez alors une information complète sur la façon dont est configuré le VLAN.

Si vous modifiez « selector » par « status », vous aurez le résultat suivant, relatif au statut réel de la ressource VLAN :Screen Shot 2018-11-30 at 14.41.16.png

 

En enfin, en modifiant « selector » par « statistics », vous obtiendrez des informations uniquement sur les statistiques liées au VLAN :

Screen Shot 2018-11-30 at 14.41.23.png

La notion de « selector » est exclusive : Vous ne pouvez utiliser d’attributs, sous peine d’obtenir une erreur de type 500. Il en est de même avec notion de « depth » - Que vous sélectionniez 0, 1, 2 ou 3, cela n’aura aucun impact sur la profondeur des informations renvoyées.

 

Pour finir, une dernière option intéressante dans le filtrage ou la qualification des résultats renvoyés par votre équipement : l'argument count.

Cet argument sert tout simplement à vous renvoyer le nombre d'éléments retournés par équipement.

Par exemple, vous souhaitez uniquement savoir le nombre de VLAN existants sur votre équipement. Il suffit alors juste de mettre le filtre "Count" a True :Screen Shot 2018-11-30 at 15.22.05.png

et vous obtenez tres simplement la reponse :

Screen Shot 2018-11-30 at 15.22.19.png

 

L'argument "Count" est bien entendu utilisable avec des attributs autres. Comme par exemple si nous souhaitons savoir le nombre de VLAN avec un "oper_state" à "up" uniquement.

 

Nous en avons terminé avec cette première découverte des APIs d'ArubaOS-CX, qui permet de bien voir toute la puissance de ces dernières.

Si vous souhaitez en savoir plus :

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