La prochaine version de Red Hat Ansible Engine 2.9 apporte des améliorations intéressantes, dont certaines sont abordées dans cet article. Comme toujours, nous avons développé ouvertement les améliorations d'Ansible Network, avec le soutien de la communauté. Rejoignez-nous - jetez un oeil à et étudier le plan de développement de sur la page wiki pour .
Comme nous l'avons récemment annoncé, inclut désormais Ansible Tower, Ansible Engine et tout le contenu Ansible Network. De nos jours, les 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
- Genévrier Junos
- VyOS
Pour une liste complète des plates-formes entièrement prises en charge par Red Hat via l'abonnement Ansible Automation, .
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 que comme les artefacts de plate-forme sont utilisés dans les playbooks et les rôles Ansible par les utilisateurs finaux. Et voici ce que nous avons découvert :
- Les organisations automatisent les appareils provenant non pas d’un seul, mais de plusieurs fournisseurs.
- L’automatisation n’est pas seulement un phénomène technique, mais aussi culturel.
- L'automatisation des réseaux à grande échelle est plus difficile qu'il n'y paraît en raison des principes architecturaux fondamentaux de la conception de l'automatisation.
Lorsque nous avons discuté de nos plans de croissance à long terme il y a plus d’un an, nos entreprises clientes ont demandé ce qui suit :
- La collecte d’informations doit être mieux standardisée et alignée sur les flux de travail d’automatisation sur tous les appareils.
- La mise à jour des configurations sur l'appareil doit également être standardisée et cohérente afin que les modules Ansible gèrent la seconde moitié du cycle après la collecte des 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 du périphérique réseau.
Améliorations des faits
La collecte d'informations à partir de périphériques réseau à l'aide d'Ansible se produit souvent de manière aléatoire. Les plates-formes Web ont différents degrés de capacités de collecte de données, mais elles disposent de peu ou pas de fonctionnalités pour analyser et standardiser la représentation des données dans des paires clé-valeur. Lire Ken Celenza explique à quel point il peut être difficile et pénible d'analyser et de normaliser des données factuelles.
Vous avez peut-être remarqué que nous travaillons sur le rôle Ansible Network Engine. Naturellement, 24 2.8 téléchargements plus tard, le rôle Network Engine est rapidement devenu l'un des rôles Ansible les plus populaires dans Ansible Galaxy pour les scénarios d'automatisation de réseau. Avant de déplacer une grande partie de cela dans Ansible 2.9 pour préparer ce qui serait nécessaire dans Ansible XNUMX, ce rôle Ansible fournissait le premier ensemble d'outils pour aider à analyser les commandes, à gérer les commandes et à collecter des données pour les périphériques réseau.
Si vous savez utiliser Network Engine, il s'agit d'un moyen très efficace de collecter, d'analyser et de standardiser des données factuelles à utiliser dans Ansible. L'inconvénient de ce rôle est que vous devez créer tout un tas d'analyseurs pour chaque plateforme 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, jetez un œil à des gars de Cisco.
En un mot, obtenir des informations à partir des appareils et les normaliser en paires clé-valeur est essentiel pour l'automatisation à grande échelle, mais y parvenir est difficile lorsque vous disposez de nombreux fournisseurs et plates-formes réseau.
Chaque module de faits réseau d'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.
Depuis Ansible 2.9, chaque fois qu'un module réseau mis à jour est publié, le module de faits est amélioré pour fournir des données sur cette section de la 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 récupérée et convertie en données structurées de deux manières. Dans les deux sens, vous pouvez collecter et transformer une liste spécifique de ressources à l'aide d'un nouveau mot-clé gather_network_resources. Les noms des ressources correspondent aux noms des modules, ce qui est très pratique.
En rassemblant des faits :
Utiliser un mot-clé gather_facts vous pouvez récupérer la configuration actuelle de l'appareil au début du playbook, puis l'utiliser tout au long du playbook. Spécifiez les ressources individuelles à récupérer du périphérique.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueVous avez peut-être remarqué quelque chose de nouveau dans ces exemples, à savoir : gather_facts: true est désormais disponible pour la collecte de faits native pour les périphériques réseau.
En utilisant directement le module de faits sur le réseau :
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesLe 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: Ethernet1Remarquez comment Ansible récupère la configuration native de l'appareil Arista et la transforme en données structurées à utiliser comme paires clé-valeur standard pour les tâches et opérations en aval.
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 un module de ressources eos_interfaces sans traitement ni conversion supplémentaire.
Modules de ressources
Nous avons donc extrait les faits, normalisé les données, les avons intégrés dans un diagramme de structure de données interne standardisé et avons reçu une source de vérité toute prête. Hourra! C'est bien sûr génial, mais nous devons encore reconvertir d'une manière ou d'une autre les paires clé-valeur dans la configuration spécifique attendue par la plate-forme spécifique de l'appareil. Nous avons désormais besoin de modules spécifiques à la plateforme pour répondre à ces nouvelles exigences de collecte de données et de normalisation.
Qu'est-ce qu'un module de ressources ? Vous pouvez considérer les sections de configuration d'un appareil comme des ressources fournies par cet appareil. Les modules de ressources réseau sont intentionnellement limités à une seule ressource et peuvent être empilés comme des éléments de base pour configurer des services réseau complexes. En conséquence, les exigences et les spécifications d'un module de ressources sont naturellement simplifiées, puisque le module de ressources peut lire и configurer un service réseau spécifique sur un périphérique réseau.
Pour expliquer ce que fait un module de ressources, regardons un exemple de playbook qui montre une opération idempidente utilisant de nouveaux faits et modules sur les ressources réseau. 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.changedComme vous pouvez le constater, les données collectées depuis l'appareil sont transférées directement vers le module de ressources correspondant sans conversion. Une fois lancé, le playbook récupère les valeurs de l'appareil et les compare aux valeurs attendues. Dans cet exemple, les valeurs renvoyées sont comme prévu (c'est-à-dire qu'il vérifie les écarts de configuration) et indique si la configuration a changé.
Le moyen idéal de détecter une dérive de configuration consiste à stocker les faits dans des variables stockées Ansible et à les utiliser périodiquement avec le module de ressources en mode inspection. Il s'agit d'une méthode simple pour voir si quelqu'un a modifié manuellement les valeurs. Dans la plupart des cas, les organisations autorisent les modifications et la configuration manuellement, bien que de nombreuses opérations soient effectuées via Ansible Automation.
En quoi les nouveaux modules de ressources diffèrent-ils des précédents ?
Pour un ingénieur en automatisation de réseau, il existe 3 différences principales entre les modules de ressources d'Ansible 2.9 et les versions précédentes.
1) Pour une ressource réseau donnée (qui peut également être considérée comme une section de configuration), les modules et les faits évolueront simultanément sur tous les systèmes d'exploitation réseau pris en charge. Nous pensons que si Ansible prend en charge la configuration des ressources sur une seule plate-forme réseau, nous devrions 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 (telle que LLDP) sur 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 inutiles 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 proposé) 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 test est utilisé), la configuration résultante sera renvoyée sous forme de données structurées ;commands: Toutes les commandes de configuration s'exécutent sur l'appareil pour le mettre dans l'état souhaité.
Qu'est-ce que tout cela veut dire? Pourquoi c'est important?
Cet article couvre de nombreux concepts complexes, mais nous espérons qu'à la fin, vous comprendrez mieux ce que les entreprises clientes demandent en fait, en termes de collecte, de normalisation des données et de configuration de boucles pour une plate-forme d'automatisation. Mais pourquoi ont-ils besoin de ces améliorations ? De nombreuses organisations poursuivent désormais leur transformation numérique pour rendre leurs environnements informatiques plus agiles 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 intérêt personnel, soit à la demande de la direction.
Les organisations se rendent compte que l’automatisation de modèles de réseau individuels ne résout pas le problème des silos et n’augmente l’efficacité que dans une certaine mesure. La plateforme Red Hat Ansible Automation fournit des modèles de données de ressources rigoureux et normatifs pour gérer par programmation 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 mettant l'accent sur les technologies (par exemple, les adresses IP, les VLAN, LLDP, etc.), plutôt que sur une implémentation spécifique d'un fournisseur.
Cela signifie-t-il que les jours des modules de commande et de configuration fiables et éprouvés sont comptés ? Dans aucun cas. Les modules de ressources réseau attendus ne seront pas applicables dans tous les cas ni pour tous les fournisseurs, de sorte que les modules de commande et de configuration seront toujours nécessaires aux ingénieurs réseau pour certaines implémentations. Le but des modules de ressources est de simplifier les grands modèles Jinja et de normaliser les configurations d'appareils 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 représentent une source de vérité facile à lire. En utilisant des paires clé-valeur structurées, vous pouvez passer de l'exécution de configurations sur chaque appareil à l'utilisation de données structurées indépendantes et placer les réseaux au premier plan d'une approche d'infrastructure en tant que code.
Quels modules de ressources seront disponibles dans Ansible Engine 2.9 ?
Avant de vous expliquer en détail ce qui se passera dans Ansible 2.9, rappelons comment nous avons divisé l'ensemble du travail.
Nous avons identifié 7 catégories et attribué des ressources réseau spécifiques à chacune :
Remarque : les ressources en gras ont été planifiées et implémentées dans Ansible 2.9.
Sur la base des commentaires des entreprises clientes et de la communauté, il était logique d'aborder d'abord les modules liés aux protocoles de topologie réseau, à la virtualisation et aux interfaces.
Les modules de ressources suivants ont été 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- d'Extreme Networks.nxos_bfd_interfaces- de Cisconxos_telemetry- de Cisco
Comme vous pouvez le constater, le concept de modules de ressources s'inscrit dans notre stratégie centrée sur la plateforme. Autrement dit, nous incluons les capacités et fonctions nécessaires dans Ansible lui-même pour prendre en charge la normalisation dans le développement de modules réseau, et également pour simplifier le travail des utilisateurs au niveau des rôles et des playbooks Ansible. Pour étendre le développement de modules de ressources, l'équipe Ansible a publié l'outil Module Builder.
Plans pour Ansible 2.10 et au-delà
Une fois Ansible 2.9 publié, nous travaillerons sur le prochain ensemble de modules de ressources pour Ansible 2.10, qui peuvent être utilisés pour configurer davantage la topologie et la politique du réseau, par ex. . Le plan de développement peut encore être ajusté, donc si vous avez des commentaires, veuillez le signaler à .
Ressources et démarrage
Source: habr.com