Le voyage d’un ingénieur réseau vers l’automatisation n’est pas quelque chose de nouveau, mais se prépare depuis pratiquement l’émergence des technologies networking. Dans certains environnements, l’automatisation est désormais perçue comme une menace pour l’ingénieur réseau alors que c’est le contraire, une aide dans son quotidien.
Ces derniers temps, l’acronyme SDN (Software Defined Networking) est devenu le mot magique qui inonde les portefeuilles de tous les fabricants d’équipements de communications. L’une des raisons est d’automatiser les infrastructures de communications. Passez d’un paradigme de plan de contrôle distribué à un plan de contrôle centralisé qui orchestre les infrastructures de communications.
L’une des motivations de l’utilisation de ce type de technologies est d’automatiser les opérations sur le réseau : approvisionnement sur le réseau, obtention des données d’utilisation, déploiement de nouveaux équipements. À tel point que dans certains environnements, l’automatisation est identifiée à ces technologies, alors que la réalité est que la relation entre les deux n’est pas bijective: les technologies SDN utilisent l’automatisation, mais l’automatisation n’a pas à aller de pair avec le SDN.
La RAE (Real Academia Española, de la langue) définit l’automatisation comme « la conversion de certains mouvements en mouvements automatiques ou non intentionnels ». Dans l’environnement des communications, cela se traduit par l’identification des tâches répétitives et l’application des mécanismes et outils qui permettent une exécution mécanique de celles-ci.
Bien qu’il existe et ait existé des outils commerciaux pour l’industrialisation et l’automatisation des tâches dans les réseaux de communications, ils conviennent à des environnements de production stables ou à faible variabilité. Dans les projets d’ingénierie dans lesquels l’efficacité dans l’exécution des changements prévaut, qu’il s’agisse du remplacement d’équipement, de la conception et du déploiement de nouveaux équipements, ou de la preuve à la réception de l’équipement qu’il fonctionne correctement, etc. l’utilisation d’outils traditionnels n’est ni efficace ni efficiente.
C’est à ce moment que les compétences de l’ingénieur réseau sont mises en valeur afin de minimiser le temps nécessaire à l’exécution des différentes tâches.
L’acquisition de compétences en automatisation chez les ingénieurs réseau n’est pas née avant tout comme un besoin du marché, mais plutôt comme une préoccupation des ingénieurs eux-mêmes. Cette situation est bien reflétée dans ce graphique Internet classique:
Les ingénieurs sont motivés pour accomplir des tâches différentes et stimulantes. Vous pouvez même dire que ces types de tâches les amusent. Lorsqu’un ingénieur doit effectuer des tâches répétitives, il cherche des moyens de minimiser le temps dont il a besoin pour effectuer ces tâches. Et nous devons reconnaître que l’automatisation est un défi amusant : réaliser une tâche fastidieuse et ennuyeuse peut être effectuée rapidement et en un seul clic.
Pour cela, il utilisera les outils à portée de main. Ici, le plus gros problème pour l’ingénieur réseau est le manque de connaissance des outils existants. L’interrelation croissante avec les départements de systèmes et développement, le paradigme DevOps, a facilité la découverte de ce type d’outils.
Exemples concrets réseau vers l’automatisation
Si nous nous concentrons sur des exemples spécifiques, dans le monde des communications, un cas typique est la création de modèles pour le déploiement d’équipements. La manière dont cette tâche est effectuée a changé au fil du temps :
- Au départ, les modèles étaient créés avec des variables qui étaient remplacées manuellement ou avec le connu « rechercher et remplacer ».
- Ensuite, la fonctionnalité de publipostage de MS Word est utilisée. Parfois, cette approche posait des problèmes en raison de la conversion automatique des caractères spéciaux.
- Dans certains cas, cette fusion de correspondance était programmée dans un langage (Visual Basic, Perl, etc. …), ce qui permettait une plus grande flexibilité dans cette tâche.
Cependant, cette approche ne fonctionne bien que lorsque tous ou presque tous les équipements et configurations sont identiques ou presque identiques. Au moment où la variabilité est introduite dans ces modèles, il n’y a pas d’autre choix que l’intervention manuelle ou la programmation ad hoc du script qui fait les modèles.
Pour résoudre ce problème particulier, des outils de développement Web tels que les langages de programmation de modèles viennent à l’aide de l’ingénieur réseau. En particulier le langage Jinja2, conçu pour créer des modèles Web dans des environnements Python.
Este lenguaje permite diseñar una plantilla que se comporte de manera diferente en función de los datos que se le proporcionen. Añade el concepto de modularidad a las plantillas. Ya no es necesario tener una plantilla monolítica, sino que podemos tener pequeñas plantillas que se apliquen o no en función de los datos con los que queramos construir nuestra configuración.
Ce langage vous permet de concevoir un modèle qui se comporte différemment en fonction des données fournies. Il ajoute le concept de modularité aux modèles. Il n’est plus nécessaire d’avoir un modèle monolithique, mais nous pouvons avoir de petits modèles qui sont appliqués ou non en fonction des données avec lesquelles nous voulons construire notre configuration.
La courbe d’apprentissage de ce langage de modèles pour un ingénieur réseau est très faible. Des modèles très élaborés peuvent être créés sans aller trop loin dans les complexités d’un langage de programmation. Bien que Jinja2 soit un langage très puissant qui vous permet de faire des merveilles, ce dont un ingénieur réseau a vraiment besoin est beaucoup moins : être capable de configurer un nombre variable d’éléments, comme les interfaces réseau ; être capable d’appliquer ou non une configuration basée sur un ou plusieurs paramètres, comme l’application ou non d’une configuration de BGP à un équipement en fonction de son rôle dans le réseau ; etc.
L’utilisation de Jinja2 suppose une amélioration de la fabrication des modèles, car elle permet leur industrialisation et leur automatisation.
Cependant, l’utilisation de ces modèles, comme avec les modèles traditionnels, mais dans une plus large mesure, pose un autre problème : la gestion de leurs versions.
Il est maintenant essentiel de garder une trace de ces versions: quelle est la dernière version, quels sont les changements par rapport à la version précédente, qui a fait les derniers changements, quelle en est la raison, etc.
La méthode traditionnelle consiste à utiliser un critère de dénomination manuel pour les fichiers de modèle, mais cette approche a toujours apporté de mauvaises expériences: des versions avec des noms incohérents, qui n’a pas vu de modèles avec des noms de type « définitif », « dernier » ou « final » dans le même répertoire. Il n’est pas rare qu’un fichier soit remplacé par un autre par erreur, perdant tout ou partie des informations. Sans parler des conflits lorsque deux personnes ont simultanément modifié le même modèle.
Au secours de l’ingénieur réseau, le monde du développement revient à nouveau. Le contrôle de versions est essentiel dans cet environnement et de nombreux outils de ce type ont été utilisés. Depuis des années, l’outil prédominant est Git, un outil développé par le célèbre Linus Torvald pour gérer les versions du noyau Linux.
Cet outil résoudra les deux problèmes principaux :
- Cela nous permet d’avoir un contrôle de versions. Il n’est plus nécessaire de changer le nom des fichiers, c’est l’outil lui-même qui se charge de créer les versions et de contrôler les différences entre elles.
- Travail de groupe: cela permet à plus d’une personne de travailler sur une copie d’un fichier en même temps et il fusionne automatiquement toutes les modifications. Ce n’est que dans le cas où deux personnes ont touché les mêmes lignes d’un fichier qu’une intervention manuelle sera nécessaire pour résoudre le conflit.
La prochaine étape de notre voyage est de savoir comment obtenir les données nécessaires pour alimenter notre modèle et générer notre configuration.
Un type de projet courant dans les environnements de communication est le remplacement ou la migration d’équipement. Parfois cet équipement est du même fabricant et dans d’autres non, mais dans tous les cas il est nécessaire d’obtenir les données des services dans l’équipement actuel afin de pouvoir les migrer vers les nouveaux.
Si jusqu’à présent il avait été possible d’éviter l’utilisation des langages de programmation, à ce stade, il est difficile de ne pas avoir à acquérir un minimum de compétences. La plupart des équipements actuels permettent déjà de fournir des données dans des formats structurés (principalement xml ou json), mais ce n’est pas aussi courant dans les équipements moins récents. Ces équipes livrent du texte brut, donc dans de nombreux cas, il est nécessaire de devoir « to parse » la configuration : analyser la configuration pour obtenir les données nécessaires dans un format avec lequel nous pouvons alimenter notre modèle de configuration.
Parmi les langages de programmation utilisables, Python se démarque. Les principales raisons sont sa simplicité et la quantité de ressources et d’exemples disponibles en ligne. Il s’agit actuellement du langage de facto utilisé dans la plupart des outils d’automatisation de réseau. En fait, un interprète de ce langage est déjà inclus dans l’équipement des principaux fabricants de réseaux, tels que Cisco, Juniper ou Nokia.
Sur la base de tout ce qui précède, nous serions déjà en mesure d’analyser et de traiter automatiquement les informations sur nos PC. Il reste à voir comment obtenir ces informations de manière dynamique et comment transférer la configuration dans le réseau de la même manière.
Nous avons ici trois grands groupes d’options :
- Utilisation d’outils imbibés dans des gestionnaires de connexions tels que secureCRT. Le gros problème avec cette approche est généralement double:
- Ces outils sont souvent propriétaires et coûteux.
- Le partage des scripts nécessite l’utilisation du même gestionnaire de connexions par toute l’équipe, ce qui n’est généralement pas le cas.
- Utilisation d’outils développés par les fabricants : les principaux acteurs du secteur ont développé des bibliothèques Python open source qui peuvent être utilisées pour mener à bien cette tâche. Des exemples seraient pyATS de Cisco ou pyEZ de Juniper.
- Utilisation d’outils développés par la communauté et indépendants des fabricants. Ici, nous aurions à notre tour deux aspects principaux :
- Ansible: outil d’automatisation généraliste du monde DevOps.
- Outils orientés réseau tels que napalm, nornir ou salt.
Parmi tous, Ansible se démarque pour les raisons suivantes :
- On n’a pas besoin de compétences en programmation pour l’utiliser. Le reste des outils sont des bibliothèques Python qui peuvent être utilisées dans nos scripts.
- Il dispose d’un grand nombre de modules spécifiques pour chaque fabricant, développés dans la plupart des cas par ces mêmes fabricants.
- Il est relativement facile de créer de nouveaux modules, avec de la programmation, bien sûr. Mais une fois le module programmé, n’importe qui peut l’utiliser sans avoir ces connaissances en programmation.
Ansible permet une grande flexibilité dans l’automatisation des tâches. Il permet par exemple :
- Se connecter à une équipe et découvrir les équipes avec lesquelles elle établi des sessions de transport.
- Se connecter à ces équipes et découvrir quel est l’état du service en fonction des paramètres que nous déterminons.
- Mettre sur disque les informations obtenues dans le format qui nous intéresse le plus.
Jusqu’à présent, nous effectuions ce type de tâches de manière relativement manuelle, autant l’obtention de l’information que la corrélation elle-même.
L’utilisation d’Ansible comme outil d’automatisation nous permet de pouvoir répliquer facilement une tâche à tout moment (par exemple : avant et après la réalisation d’une intervention sur le réseau), et réduit également les risques d’erreurs qui se produisent entre la chaise et le clavier de l’ordinateur.
La façon dont Ansible est « programmé » est avec les soi-disant playbooks : des fichiers au format yaml dans lesquels nous indiquons les actions que nous voulons qu’il effectue. Intégré dans Ansible, Jinja2 est utilisé comme langage de modèles. Par conséquent, ces playbooks peuvent (et devraient) également être gérés à l’aide de Git.
Il faut ne pas oublier de mettre également en évidence un méta-outil qui survole tous les précédents: GNU Linux. Ce système d’exploitation permet de grandes capacités d’automatisation depuis sa création, certaines qui ont donné d’aussi bons résultats que Expect, qui permet de dialoguer avec un appareil: je t’envoie une information et en fonction de ce que tu réponds, je t’envoie une autre information, et ainsi de suite. Certains outils comme Ansible ne fonctionnent que sur un noyau Linux. Depuis l’introduction du sous-système Windows pour Linux (WSL), Ansible peut également être exécuté sous Windows, il n’y a donc plus d’excuse pour apprendre un minimum de ce système d’exploitation.
Enfin, il convient de se rappeler que l’automatisation n’est pas une fin, mais un moyen. Dans notre quotidien, avant de commencer à exécuter une nouvelle tâche, nous devons analyser si cela vaut la peine de l’automatiser.
Illustration 1 : Source www.xkcd.com
Nous devons également garder à l’esprit que la courbe idéale du temps que nous gagnons avec les automatisations ne correspond pas toujours au graphique ci-dessus des « geeks and repetitive tasks ». Si nous perdons de vue le fait que l’automatisation est un moyen et non une fin, cette courbe peut se transformer en le suivant cauchemar :
Illustration 2 : Source www.xkcd.com
Mais la seule façon, en tant qu’ingénieur réseau, d’atteindre l’efficacité de l’automatisation est de commencer le voyage… et de commencer à s’amuser.
Cet article a été publié le mois d´octobre par le magazine « A NOSA REDE” del Colegio Oficial Enxeñeiros de Telecomunicación de Galicia ».