Le livre de jeu intérieur. Fonctionnalités réseau dans le nouveau moteur Ansible 2.9

La prochaine version de Red Hat Ansible Engine 2.9 vous attend avec des améliorations impressionnantes, dont certaines sont décrites dans cet article. Comme d'habitude, nous avons ouvertement développé les améliorations du réseau Ansible, avec le soutien de la communauté. Rejoignez - Jetez un œil au tableau des tâches sur GitHub et étudiez le plan de développement pour la sortie de Red Hat Ansible Engine 2.9 sur la page wiki d' Ansible Network .

Comme nous l'avons récemment annoncé, Red Hat Ansible Automation Platform inclut désormais Ansible Tower, Ansible Engine et tout le contenu du réseau Ansible. Désormais, la plupart des plateformes réseau les plus populaires sont implémentées via des modules Ansible. Par exemple:

• Arista eos
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• Vyos

Une liste complète des plates-formes entièrement prises en charge par Red Hat via Ansible Automation est disponible ici .

Qu'avons-nous appris

Au cours des quatre dernières années, nous avons beaucoup appris sur le développement d'une plateforme d'automatisation de réseau. Nous avons également appris comment les utilisateurs finaux jouent des artefacts de plate-forme dans les livres de jeu et les rôles Ansible. Et voici ce que nous avons découvert:

• Les organisations automatisent les appareils non seulement un, mais de nombreux fournisseurs.
• L'automatisation n'est pas seulement un phénomène technique, mais aussi culturel.
• L'automatisation à grande échelle des réseaux est plus compliquée qu'il n'y paraît, en raison des principes architecturaux fondamentaux de la conception d'automatisation.

Lorsque nous avons discuté de nos plans de développement à long terme il y a plus d'un an, nos entreprises clientes ont demandé ce qui suit:

• La collecte des faits doit être mieux standardisée et alignée avec le flux de travail d'automatisation pour n'importe quel appareil.
• La mise à jour des configurations sur l'appareil doit également être standardisée et harmonisée afin que les modules Ansible traitent la seconde moitié du cycle après avoir collecté les faits.
• Nous avons besoin de méthodes rigoureuses et prises en charge pour convertir la configuration des appareils en données structurées. Sur cette base, la source de vérité peut être déplacée d'un périphérique réseau.

Améliorations des faits

La collecte de faits à partir de périphériques réseau à l'aide d'Ansible est souvent aléatoire. Les plates-formes réseau sont équipées à des degrés divers de la capacité de collecter des faits, mais elles n'ont presque pas - ou même pas du tout - de fonctions pour analyser et standardiser la présentation des données dans des paires clé-valeur. Lisez le post de Ken Celenza sur la difficulté et la douleur d'analyser et de normaliser les données factuelles.

Vous avez peut-être remarqué comment nous avons travaillé sur le rôle Ansible Network Engine. Naturellement, 24 000 téléchargements plus tard, le rôle Network Engine est rapidement devenu l'un des rôles les plus populaires d'Ansible dans Ansible Galaxy pour les scénarios d'automatisation de réseau. Avant de migrer une grande partie de cela vers Ansible 2.8 pour préparer ce dont Ansible 2.9 avait besoin, ce rôle Ansible fournissait le premier ensemble d'outils pour aider à l'analyse des commandes, à la gestion des commandes et à la collecte de données pour les périphériques réseau.

Si vous êtes doué pour utiliser Network Engine, il s'agit d'un moyen très efficace de collecter, d'analyser et de normaliser les données de fait à utiliser avec Ansible. L'inconvénient de ce rôle est que vous devez créer tout un tas d'analyseurs pour chaque plate-forme et pour toutes les activités du réseau. Pour comprendre à quel point il est difficile de créer, d'expédier et de maintenir des analyseurs, regardez les 1200+ analyseurs des gars de Cisco.

En un mot, pour l'automatisation à grande échelle, il est très important de recevoir les faits des appareils et de les normaliser en paires clé-valeur, mais cela est difficile à réaliser lorsque vous avez de nombreux fournisseurs et plates-formes réseau.

Chaque module de faits de réseau dans Ansible 2.9 peut désormais analyser la configuration d'un périphérique réseau et renvoyer des données structurées - sans bibliothèques supplémentaires, rôles Ansible ou analyseurs personnalisés.

À partir d'Ansible 2.9, à chaque version du module réseau mis à jour, le module fact est amélioré pour fournir des informations sur cette section de configuration. Autrement dit, le développement des faits et des modules se déroule désormais au même rythme, et ils auront toujours une structure de données commune.

La configuration des ressources sur un périphérique réseau peut être extraite et convertie en données structurées de deux manières. Dans les deux cas, vous pouvez compiler et convertir une liste spécifique de ressources à l'aide du nouveau gather_network_resources . Les noms de ressources correspondent aux noms de modules, ce qui est très pratique.

Au moment de la collecte des faits:

À l'aide du gather_facts vous pouvez extraire la configuration actuelle de l'appareil au début du playbook, puis l'utiliser dans tout le playbook. Spécifiez les ressources individuelles à récupérer à partir du périphérique.

 - hosts: arista module_defaults: eos_facts: gather_subset: min gather_network_resources: - interfaces gather_facts: True 

Vous remarquerez peut-être quelque chose de nouveau dans ces exemples, à savoir gather_facts: true désormais disponible pour la recherche de faits native pour les périphériques réseau.

Utilisation directe du module de faits sur le réseau:

 - name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces 

Le playbook renvoie les faits suivants sur l'interface:

 ansible_facts: ansible_network_resources: interfaces: - enabled: true name: Ethernet1 mtu: '1476' - enabled: true name: Loopback0 - enabled: true name: Loopback1 - enabled: true mtu: '1476' name: Tunnel0 - enabled: true name: Ethernet1 - enabled: true name: Tunnel1 - enabled: true name: Ethernet1 

Remarquez comment Ansible récupère la configuration native de l'appareil Arista et la convertit en données structurées à utiliser comme paires clé-valeur standard pour les tâches et opérations suivantes.

Les faits d'interface peuvent être ajoutés aux variables stockées Ansible et utilisés immédiatement ou ultérieurement comme entrée dans le eos_interfaces ressources eos_interfaces sans traitement ni conversion supplémentaires.

Modules de ressources

Nous avons donc extrait les faits, normalisé les données, les avons entrées dans un schéma interne normalisé de la structure des données et obtenu une source de vérité toute prête. Hourra! Bien sûr, c'est génial, mais nous devons toujours reconvertir les paires clé-valeur en une configuration spécifique attendue par une plate-forme de périphérique spécifique. Nous avons maintenant besoin de modules pour des plates-formes spécifiques pour satisfaire ces nouvelles exigences de collecte de faits et de normalisation.

Qu'est-ce qu'un module de ressources? Les sections de configuration de l'appareil peuvent être considérées comme les ressources fournies par cet appareil. Les modules de ressources réseau sont intentionnellement limités à une seule ressource, et ils peuvent être empilés comme des briques pour configurer des services réseau complexes. En conséquence, les exigences et les spécifications du module de ressources sont naturellement simplifiées, car le module de ressources peut lire et configurer un service réseau spécifique sur un périphérique réseau.

Pour expliquer ce que fait le module de ressources, regardons un exemple de playbook qui montre une opération idempoent utilisant de nouveaux faits à partir d'une ressource réseau et le module eos_l3_interface .

 - name: example of facts being pushed right back to device. hosts: arista gather_facts: false tasks: - name: grab arista eos facts eos_facts: gather_subset: min gather_network_resources: l3_interfaces - name: ensure that the IP address information is accurate eos_l3_interfaces: config: "{{ ansible_network_resources['l3_interfaces'] }}" register: result - name: ensure config did not change assert: that: not result.changed 

Comme vous pouvez le voir, les données collectées de l'appareil sont transférées directement vers le module de ressources correspondant sans conversion. Au démarrage, le playbook récupère les valeurs de l'appareil et les compare avec celles attendues. Dans cet exemple, les valeurs obtenues correspondent aux valeurs attendues (c'est-à-dire que les écarts de configuration sont vérifiés) et un message s'affiche si la configuration a changé.

Un moyen idéal pour détecter les écarts de configuration consiste à stocker les faits dans des variables stockées Ansible et à les utiliser périodiquement avec le module de ressources en mode vérification. Il s'agit d'une méthode simple pour voir si quelqu'un a modifié les valeurs manuellement. Dans la plupart des cas, les organisations autorisent les modifications et la configuration manuelles, bien que de nombreuses opérations soient effectuées via Ansible Automation.

En quoi les nouveaux modules de ressources sont-ils différents des précédents?

Pour un ingénieur en automatisation de réseau, il existe 3 différences principales entre les modules de ressources dans Ansible 2.9 des versions précédentes.

1) Pour une ressource réseau spécifique (qui peut également être considérée comme une section de configuration), les modules et les faits se développeront dans tous les systèmes d'exploitation réseau pris en charge en même temps. Nous pensons que si Ansible prend en charge la configuration des ressources sur une seule plate-forme réseau, nous devons la prendre en charge partout. Cela simplifie l'utilisation des modules de ressources, car un ingénieur en automatisation réseau peut désormais configurer une ressource (par exemple, LLDP) dans tous les systèmes d'exploitation réseau avec des modules natifs et pris en charge.

2) Les modules de ressources incluent désormais une valeur d'état.

• merged : la configuration est fusionnée avec la configuration fournie (par défaut);
• replaced : la configuration des ressources sera remplacée par la configuration fournie;
• overridden : la configuration des ressources sera remplacée par la configuration fournie; les instances de ressources en excès seront supprimées;
• deleted : la configuration des ressources sera supprimée / restaurée par défaut.

3) Les modules de ressources incluent désormais des valeurs de retour stables. Lorsque le module de ressources réseau a apporté (ou suggéré) les modifications nécessaires au périphérique réseau, il renvoie les mêmes paires clé-valeur au playbook.

• before : configuration sur l'appareil sous forme de données structurées avant la tâche;
• after : si l'appareil a changé (ou peut changer si le mode de vérification est utilisé), la configuration résultante sera retournée sous forme de données structurées;
• commands : toutes les commandes de configuration s'exécutant sur l'appareil pour l'amener à l'état souhaité.

Qu'est-ce que tout cela signifie? Pourquoi est-ce important?

Cet article décrit de nombreux concepts complexes, mais nous espérons qu'à la fin vous comprendrez mieux que les entreprises clientes demandent des faits, une normalisation des données et une configuration de boucle pour la plate-forme d'automatisation. Mais pourquoi ont-ils besoin de ces améliorations? De nombreuses organisations sont désormais engagées dans la transformation numérique pour rendre leurs environnements informatiques plus flexibles et compétitifs. Pour le meilleur ou pour le pire, de nombreux ingénieurs réseau deviennent des développeurs de réseaux, soit par leur propre intérêt, soit à la demande des gestionnaires.

Les organisations comprennent que l'automatisation de modèles de réseau individuels ne résout pas le problème de fragmentation et n'augmente l'efficacité que dans une certaine limite. La plate-forme d'automatisation Red Hat Ansible fournit des modèles de données de ressources rigoureux et normatifs pour gérer par programme les données sous-jacentes sur un périphérique réseau. Autrement dit, les utilisateurs abandonnent progressivement les méthodes de configuration individuelles au profit de méthodes plus modernes en mettant l'accent sur les technologies (par exemple, les adresses IP, les VLAN, LLDP, etc.), et non sur une implémentation de fournisseur spécifique.

Est-ce à dire que les jours de configuration et de modules de commande fiables et éprouvés sont comptés? Pas question. Les modules de ressources réseau attendus ne seront pas applicables dans tous les cas et pas pour chaque fournisseur, de sorte que les ingénieurs réseau auront toujours besoin de modules de commande et de configuration pour certaines implémentations. Le but des modules de ressources est de simplifier les grands modèles Jinja et de normaliser les configurations de périphériques non structurées dans un format JSON structuré. Avec les modules de ressources, il sera plus facile pour les réseaux existants de transformer leur configuration en paires clé-valeur structurées qui seront une source de vérité facile à lire. Si vous utilisez des paires clé-valeur structurées, vous pouvez passer des configurations en cours d'exécution sur chaque périphérique à l'utilisation de données structurées indépendantes et mettre les réseaux au premier plan avec l'approche «infrastructure en tant que code».

Quels modules de ressources apparaîtront dans Ansible Engine 2.9?

Avant de dire en détail ce qui se passera dans Ansible 2.9, rappelons comment nous avons divisé la totalité du travail.

Nous avons identifié 7 catégories et chacune a attribué des ressources réseau spécifiques:

Remarque: des ressources audacieuses ont été planifiées et mises en œuvre dans Ansible 2.9.
Sur la base des commentaires des clients d'entreprise et de la communauté, il était logique de traiter d'abord les modules liés aux protocoles de topologie réseau, à la virtualisation et aux interfaces.
Les modules de ressources suivants sont développés par l'équipe Ansible Network et correspondent aux plateformes prises en charge par Red Hat:

Les modules suivants sont développés par la communauté Ansible:

• exos_lldp_global - de Extreme Networks.
• nxos_bfd_interfaces - de Cisco
• nxos_telemetry - de Cisco

Comme vous pouvez le voir, le concept de modules de ressources s'intègre dans notre stratégie d'orientation de plateforme. Autrement dit, nous incluons les capacités et fonctions nécessaires dans Ansible lui-même, afin de prendre en charge la normalisation dans le développement des modules réseau, ainsi que de simplifier le travail des utilisateurs au niveau du rôle et du playbook Ansible. Pour étendre le développement des modules de ressources, l'équipe Ansible a publié l'outil Module Builder.

Plans pour Ansible 2.10 partir

Après la sortie d'Ansible 2.9, nous traiterons l'ensemble suivant de modules de ressources pour Ansible 2.10, qui peuvent être utilisés pour configurer davantage la topologie et la stratégie réseau, par exemple, ACL, OSPF et BGP . Le plan de développement peut encore être ajusté, donc si vous avez des commentaires, signalez-le à la communauté Ansible Network .

Ressources et mise en route

Communiqué de presse de la plate-forme Ansible Automation
Blog de la plate-forme d'automatisation Ansible
L'avenir de la livraison de contenu chez Ansible
Réflexions sur la modification de la structure du projet Ansible