Paradigme Infrastructure as Code (IaC)

Le paradigme Infrastructure as Code repose sur la gestion et le provisionnement de l’infrastructure par le biais du code au lieu d’utiliser des processus manuels.

L’état de l’infrastructure est stocké dans des fichiers contenant la représentation de sa configuration. Il ne doit pas s’agir de la configuration exacte, mais d’un modèle de données permettant de générer la configuration ou l’état final de l’équipement cible.

L’utilisation de ce type de représentation permet, entre autres:

• Suivre facilement les modifications apportées à l’infrastructure. Ce type de suivi peut être effectué avec un système de contrôle de version, tel que git.
• Déployer et reproduire facilement la configuration sur le réseau à l’aide d’outils d’automatisation.
• Intégrer l’infrastructure dans les pipelines CI/CD (Continuous Integration/Continuous Delivery).

Le concept d’Infrastructure as Code est né avec l’explosion exponentielle des centres de données. Le nombre de machines physiques ou virtuelles qu’il fallait gérer a augmenté de plusieurs ordres de grandeur. L’approche traditionnelle consistant à configurer manuellement les équipements n’était plus valable. Il était essentiel de pouvoir automatiser les déploiements de masse et de connaître l’état souhaité dans lequel devait se trouver chacun des services. L’utilisation du paradigme IaC permet de stocker ces informations d’état afin que les outils d’automatisation puissent ensuite déployer ou mettre à jour les services.

Grâce à l’utilisation de l’automatisation et de l’IaC, la gestion de grands centres de données comprenant des centaines ou des milliers de serveurs physiques et des centaines de milliers de serveurs virtuels est devenue gérable.

On tente de transposer le même paradigme au monde des réseaux de communication. L’objectif est de pouvoir profiter des avantages qu’elle apporte, par exemple :

• Réduction des coûts d’exploitation, de maintenance et de déploiement : un provisionnement automatisé, déterministe et simplifié a des coûts inférieurs à un provisionnement manuel.
• Flexibilité et rapidité de déploiement accrues.
• Configurations déterministes : la configuration déployée ne sera jamais affectée par une erreur humaine. S’il y a une erreur dans la configuration, elle est déterministe, et donc traçable pour être corrigée.
• Utilisation de pipelines CI/CD pour tester la nouvelle configuration avant le déploiement.
• Informations sur la configuration du réseau facilement traçables et modifiables.

Toutefois, la mise en œuvre de ce paradigme dans les réseaux de communication se heurte à des difficultés :

• Hétérogénéité des équipements de réseau : chaque fabricant a une manière différente de configurer ses équipements, et même au sein d’un même fabricant il peut y avoir des modèles avec des manières différentes de configuration (voir Cisco avec IOS, IOS-XR, NX-OS).
• Fonctionnalités propriétaires : bien que tous les fabricants prétendent défendre les normes, ils ont presque tous tendance à apporter des « améliorations » propriétaires.
• Manque de documentation : de nombreux réseaux ne sont pas documentés ; d’autres disposent d’une documentation, mais elle est complètement dépassée ; d’autres encore ont une documentation fragmentée et non indexée, de sorte qu’il est assez difficile de trouver les bonnes informations.
• Modèles : dans de nombreux réseaux, il n’existe pas de modèles de configuration officiels, de sorte que le déploiement d’un nouveau service suit souvent un modèle de « copie d’un autre endroit où cela fonctionne », ce qui entraîne une « dérive » des configurations appliquées dans le réseau.
• Modèle d’exploitation : en cas de problèmes de réseau, la configuration nécessaire est appliquée pour résoudre le problème et rétablir le service. Ces configurations ne sont pas toujours ramenées à une configuration standard et sont rarement documentées.
• Manque de connaissances : bien que l’automatisation des réseaux existe depuis des années, la norme est un manque de connaissances de ces techniques dans les départements d’ingénierie et d’exploitation des réseaux.

Passons sur les complications opérationnelles de la mise en œuvre d’un modèle Network Infrastructure as Code et concentrons-nous sur les complications techniques.

La première et la plus importante pierre d’achoppement est de savoir comment représenter notre configuration sous forme de code. Nous avons ici deux modèles clairs :

• Déclarative : avec cette approche, notre configuration définit comment nous voulons que l’équipement réseau se comporte, quel est l’état souhaité (j’ai besoin d’une adjacence ISIS sur l’interface Ethernet0).
• Impératif : Dans ce modèle, les commandes exactes à appliquer et dans quel ordre sur l’ordinateur cible sont stockées.

Le modèle impératif est assez simple, et peut résoudre notre problème à court terme. Mais elle n’est pas utile à moyen ou long terme. Il n’est pas indépendant des fournisseurs, car chacun a sa propre ligne de commandes.

Le modèle déclaratif a aussi ses problèmes dans les équipements de réseau. Dans ce type d’équipement, l’ordre dans lequel les commandes sont appliquées est souvent critique, et un ordre d’application différent peut entraîner une perte de service ou de gestion.

L’idéal serait d’utiliser un modèle déclaratif, mais l’automatisation qui déverse les informations dans le réseau devrait être capable de discerner si certaines commandes doivent être exécutées avant d’autres. Avec les outils d’automatisation actuels, cette approche ne devrait pas poser de problème.

À ce stade, il est nécessaire de disposer d’une abstraction qui nous permette de modéliser la configuration d’un équipement indépendamment du fabricant auquel il appartient.

Le langage de modélisation dominant, et utilisé avec les protocoles de gestion de réseau tels que NETCONF, est le YANG (Yet Another Next Generation).

Ce langage permet de modéliser la configuration d’un appareil à l’aide de fichiers YAML, JSON ou XML. Il existe des modèles YANG standard qui peuvent être utilisés par presque tous les fabricants. En outre, chaque fabricant définit ses propres modèles pour pouvoir modéliser ses particularités.

Le problème de l’abstraction complète ne se pose pas dans les configurations simples, comme l’application d’une adresse IP à une interface, mais dans les structures complexes comme les politiques de routage. La manière dont ces politiques sont mises en œuvre par chaque fournisseur est assez différente, mais tous les fournisseurs utilisent généralement plusieurs objets de configuration pour définir ces politiques :

• Objets à filtrer par préfixe.
• Divers objets pour filtrer par attributs BGP.
• ..

Il n’est pas facile de modéliser une politique de routage de manière déclarative. Il est encore plus complexe d’abstraire cette politique du fabricant pour qu’elle puisse être transférée à l’un ou l’autre. Mais cet écueil peut être surmonté avec une bonne définition du modèle de données et des modèles de configuration. Ces modèles permettraient à la même entrée (données) de générer des configurations en fonction du type d’équipement.

Une fois que nous avons constaté qu’il est possible, bien qu’avec un certain effort, de modéliser le réseau, nous devons examiner comment obtenir des données sur l’état actuel du réseau. Dans un green field, cela ne serait pas un problème, car la modélisation serait antérieure à la mise en œuvre du réseau. Mais ce n’est pas le cas habituel. Il existe des équipements qui permettent l’exportation de leur configuration au format YANG, mais pas tous. Pour le reste, il serait nécessaire de traiter la configuration pour générer le modèle de données. Il existe des outils capables d’analyser les configurations de certains fabricants et de modéliser leur configuration (comme napalm). Pour les fabricants pour lesquels cela n’est pas possible, il sera nécessaire de mettre en œuvre un analyseur de configuration afin d’extraire les données vers le modèle commun.

Ces informations obtenues sont celles qui seront stockées dans le système de contrôle de version, et celles qui seront utilisées pour déployer la configuration sur le réseau.

À partir de ce moment, ces informations doivent être considérées comme représentant la Single Source of Truth, source unique de vérité. Cela a des conséquences sur le fonctionnement du réseau :

• Désormais, toutes les modifications du réseau doivent être effectuées sur la base des modifications apportées aux fichiers de configuration de notre modèle de données.
• Ces changements sont déployés dans le réseau par le biais des automatismes correspondants.
• Aucune modification ne doit être apportée au réseau manuellement, car cela pourrait entraîner une dérive des configurations.

Le maintien de la source unique de vérité est fondamental dans le paradigme IaC, sinon la gestion de l’infrastructure est irréalisable s’il existe des divergences entre les données stockées dans l’infrastructure et la configuration réelle du réseau.

Pour les raisons susmentionnées, l’établissement complet du paradigme IaC dans une infrastructure de communication complexe est pratiquement une chimère aujourd’hui. C’est tout à fait possible dans les infrastructures orientées SDN, comme l’ACI de Cisco, qui a même passé un accord avec Hashicorp, une entreprise leader en matière d’IaC avec son outil Terraform. Dans ce type de réseau, il existe des éléments centralisés (contrôleurs) qui connaissent l’état complet du réseau et disposent d’API qui permettent d’interagir facilement avec eux.

Alors, est-il possible d’utiliser le paradigme IaC dans les réseaux de communication complexes ? La réponse est qu’il est très complexe de changer complètement le modèle d’exploitation, mais qu’il est possible de s’en rapprocher.

La stratégie de mise en œuvre de l’IaC dans les réseaux de communication consisterait à sélectionner des parties de la configuration à inclure dans le paradigme. Les premières parties qui peuvent être incluses, et qui constituent un véritable quick win, sont celles liées à la gestion des équipements :

• Configuration SNMP.
• Configuration NTP
• Configuration de SYSLOG,
• Configuration de l’accès à l’équipement lui-même.
• ..

Ce type de configuration est généralement commun à tous les équipements, et il est relativement facile de centraliser ces informations afin que le réseau soit toujours dans l’état souhaité.

À partir de là, d’autres parties de la configuration peuvent être ajoutées à notre infrastructure IaC, par exemple :

• Configuration des interfaces du backbone du réseau : le nombre de ces interfaces est généralement faible et leur configuration plus ou moins homogène.
• Politiques de QoS : elles sont généralement définies une fois et ensuite appliquées par type d’interface.
• Politiques de routage communes : lorsque les services sont normalisés, on définit généralement des politiques qui peuvent être réutilisées par tous les clients d’un même service. Ces politiques peuvent être modifiées au fil du temps pour s’adapter aux nouvelles caractéristiques du service. Si ces politiques se trouvent dans notre infrastructure IaC, le déploiement de la modification à l’échelle du réseau est trivial.

La dernière partie qui pourrait être ajoutée à l’infrastructure IaC dans un réseau déjà déployé serait les clients qui y sont connectés. C’est la partie qui contient le plus de variabilité et qui est souvent liée à d’autres systèmes, comme le propre CRM d’un opérateur. Avoir ces informations dans l’IaC simplifierait deux des processus les plus négligés d’un opérateur :

• Déclassement de services : il est courant pour de nombreux réseaux d’opérateurs d’avoir des restes de configurations de services déclassés. Dans un modèle IaC déclaratif, lorsque le service est mis hors service à la source unique de vérité, les automatismes suppriment la configuration associée.
• Modifications du service : il n’est pas rare que les modifications d’un service existant soient traitées comme des radiations et des enregistrements, car il est généralement plus facile de mener à bien ce processus que les modifications. Si le modèle IaC est déclaratif, les automatismes se chargeront de ces modifications.

En conclusion, la mise en œuvre complète du paradigme IaC dans un réseau de communication traditionnel est très complexe, mais il est possible de tirer parti de ce paradigme pour simplifier de nombreuses opérations de réseau. En fait, la tendance est d’étudier l’application possible de ce modèle dans les réseaux d’opérateurs.