Quoi qu’on puisse en penser, l’automatisation n’a pas pour seul objectif de faire les choses plus rapidement. Bien qu’il y ait un réel avantage à pouvoir effectuer des modifications et des déploiements plus rapidement et avec un minimum d’impact sur l’exploitation, l’automatisation permet, également, de simplifier l’architecture. En effet, en intégrant l’automatisation tout le long du cycle de vie d’un réseau, on maintient une logique de simplification, de répétitivité et de maintenabilité sur l’ensemble des équipements. De plus, l’utilisation d’outils et de scripts d’automatisation expérimentés et validés est un gage de réussite dans les actions menées, quel que soit le niveau de l’intervenant appelé à réaliser la mission.

Comme vu précédemment, l’automatisation commence dès le provisionnement des nouveaux équipements afin d’obtenir une architecture opérationnelle en maquette et sur laquelle il sera possible de déployer progressivement les fonctionnalités attendues. Ce sujet est couvert, dans la littérature, sous le terme de ZTP (Zero Touch Provisioning) ou de ZTD (Zero Touch Deployment).

Bien qu’il soit possible de développer soi-même les programmes permettant d’effectuer ces tâches en utilisant le langage Python, le système de « templates Jinja2 » et la librairie Python Paramiko à laquelle il convient d’adjoindre les librairies Netmiko et éventuellement NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support), l’utilisation d’Ansible s’impose assez  naturellement. Il existe, également, des outils comme Puppet, Chef et Salt, mais Ansible est utilisable avec seulement la présence d’un interpréteur Python et d’un accès SSH sur la cible. Or, les équipements réseaux sont généralement sur une base Unix et plus particulièrement Linux sur laquelle la présence d’un interpréteur Python est simple à envisager. Ansible permet, même, d’intervenir en mode « Raw » sur des équipements qui ne possèdent pas d’interpréteur Python.

Le principe de base d’Ansible est de créer un script Python à partir des instructions fournies en langage YAML dans un « Playbook » et d’envoyer le script aux cibles indiquées dans un fichier « Inventory », au travers de l’établissement d’une session SSH. Le script est exécuté sur chaque cible et le résultat est renvoyé, au format JSON (JavaScript Object Notation), à Ansible qui synthétise le résultat. Certains équipements supportent les sessions NETCONF sur SSH pour configurer le matériel. Dans ce cas, les échanges NETCONF sont au format YANG (Yet Another Next Generation), qui est une représentation des données au format XML.

La propriété d’idempotence d’Ansible sécurise les actions en assurant l’exécution d’une tâche que si elle apporte une modification par rapport à la situation existante. Les tâches sont décrites en langage YAML dans des fichiers appelés « Playbooks » et l’automatisation de l’ensemble est d’autant plus facilité quand les répertoires sont organisés dans une logique de « Roles » Ansible.

Avec l’intensification de l’utilisation des outils Ansible, un besoin de gestion de versions de scripts s’impose rapidement. Un outil, tel que Git, mis au point par Linus Torvalds, créateur du noyau Linux, permet de gérer efficacement des trains de version avec des capacités de retour arrière extrêmement souples et adaptées. La problématique de gestion de version s’applique également aux configurations des équipements, et bien qu’il existe des outils « Open Source » spécifiques comme RANCID ou Oxidized, Git peut parfaitement être utilisé, également, avec pertinence sur ce domaine.

Dès la réalisation de la phase ZTP ou ZTD, des tests de bon fonctionnement sont réalisés avec l’aide de scripts automatisant au maximum ces tâches. Réalisées dans une logique Agile, les phases suivantes doivent être vues comme une implémentation par couches. Si nous comparons à la façon de travailler d’un artiste qui réalise un tableau, nous pouvons imaginer passer par des étapes d’esquisse, de mise en couleur et enfin de mise en peinture. Chacune des couches est représentée sur un schéma permettant de synthétiser la logique d’implémentation et les paramètres importants. Cette planche est traduite en scripts qui seront poussés de façon automatique sur l’ensemble des équipements de l’architecture, rendus accessibles dès le départ par le premier démarrage. Un ensemble de tests sont réalisés lors de l’implémentation de chacune des couches en n’oubliant pas de repasser les tests précédents afin de vérifier la non-régression.