Le Guide Pratique. Fonctionnalités réseau dans le nouveau Ansible Engine 2.9

La prochaine version de Red Hat Ansible Engine 2.9 vous apportera des améliorations impressionnantes, dont certaines sont décrites dans cet article. Comme d'habitude, nous avons développé les améliorations d'Ansible Network de manière ouverte, avec le soutien de la communauté. Rejoignez-nous — jetez un œil à la planche de travail sur GitHub et explorez le plan de développement pour la sortie de Red Hat Ansible Engine 2.9 sur la page wiki pour Ansible Network.

Comme nous l'avons récemment annoncé, la Red Hat Ansible Automation Platform comprend désormais Ansible Tower, Ansible Engine et tout le contenu d'Ansible Network. Actuellement, la plupart des principales plateformes réseau sont mises en œuvre via des modules Ansible. Par exemple :

• Arista EOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

La liste complète des plateformes entièrement supportées par Red Hat via un abonnement à Ansible Automation est publiée ici.

Ce que nous avons appris

Au cours des quatre dernières années, nous avons beaucoup appris sur le développement d'une plateforme d'automatisation réseau. Nous avons également appris que comment les artefacts de la plateforme sont utilisés dans des playbooks et des rôles Ansible du point de vue des utilisateurs finaux. Voici ce que nous avons découvert :

• Les organisations automatisent les appareils de plusieurs fournisseurs, et non d'un seul.
• L'automatisation n'est pas uniquement un phénomène technique, mais aussi culturel.
• L'automatisation à grande échelle des réseaux est plus complexe 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 développement à long terme il y a plus d'un an, nos clients corporate ont demandé ce qui suit :

• La collecte de faits doit être mieux standardisée et alignée sur le flux de travail d'automatisation pour tous les dispositifs.
• La mise à jour des configurations sur l'appareil doit également être standardisée et alignée, afin que les modules Ansible traitent la deuxième partie du cycle après la collecte des faits.
• Des méthodes strictes et maintenues sont nécessaires pour transformer la configuration de l'appareil en données structurées. Sur cette base, la source de vérité pourra être déplacée depuis l'appareil réseau.

Améliorations des faits

La collecte des faits à partir des appareils réseau avec Ansible se fait souvent de manière aléatoire. Les plateformes réseau sont équipées de capacités de collecte de faits à des degrés divers, mais elles ont très peu – voire pas du tout – de fonctionnalités pour analyser et normaliser la présentation des données sous forme de paires clé-valeur. Lisez post Ken Celenza parle de la difficulté et de la douleur d'analyser et de standardiser les données des faits.

Vous avez peut-être remarqué comment nous avons travaillé sur le rôle Ansible Network Engine. Naturellement, après 24 000 téléchargements, le rôle Network Engine est rapidement devenu l'un des rôles les plus populaires d'Ansible dans Ansible Galaxy pour les scripts d'automatisation réseau. Avant de transférer beaucoup de cela dans Ansible 2.8, pour nous préparer à ce dont nous aurons besoin dans Ansible 2.9, ce rôle Ansible a fourni le premier ensemble d'outils pour aider à parser les commandes, gérer les équipes et collecter des données pour les appareils réseau.

Si vous utilisez le Network Engine, c'est un moyen très efficace de collecter, analyser et standardiser les données des faits pour utilisation dans Ansible. Le point négatif de ce rôle est qu’il faut créer un grand nombre de parseurs pour chaque plateforme et pour toute l'activité réseau. Pour comprendre à quel point il est difficile de créer, distribuer et maintenir des parseurs, jetez un œil à plus de 1200 parseurs des gars de Cisco.

En résumé, pour une automatisation à grande échelle, il est très important d'obtenir des faits des appareils et de les normaliser en paires clé-valeur, mais cela devient compliqué quand on a de nombreux fournisseurs et plateformes réseau.

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

À partir d'Ansible 2.9, à chaque mise à jour d'un module réseau, le module de faits est amélioré pour fournir des données sur cette section de la configuration. Cela signifie que le développement des faits et des modules se fait à un rythme commun, et qu'ils auront toujours une structure de données partagée.

La configuration des ressources sur un appareil réseau peut être extraite et transformée en données structurées de deux manières. Les deux méthodes permettent de collecter et de transformer une liste spécifique de ressources à l'aide du nouveau mot-clé gather_network_resources. Les noms des ressources correspondent aux noms des modules, ce qui est très pratique.

Lors de la collecte des faits :

À l'aide du mot-clé gather_facts vous pouvez extraire la configuration actuelle de l'appareil au début du playbook, puis l'utiliser tout au long de celui-ci. Indiquez les ressources spécifiques à extraire de l'appareil.

- hôtes : arista
  module_defaults:
    eos_facts:
      gather_subset : min
      gather_network_resources :
      - interfaces
  gather_facts : True

Vous avez peut-être remarqué quelque chose de nouveau dans ces exemples, à savoir — gather_facts : true maintenant disponible pour la collecte native de faits pour les dispositifs réseau.

Utilisation directe du module des faits réseau :

- nom : collecter les faits de configuration des interfaces
  eos_facts:
    gather_subset : min
    gather_network_resources :
    - interfaces

Le playbook retourne 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

Notez comment Ansible extrait la configuration native de l'appareil Arista et la transforme en données structurées à utiliser sous forme de paires clé-valeur standard pour les tâches et opérations ultérieures.

Les faits d'interface peuvent être ajoutés aux variables stockées d'Ansible et utilisées immédiatement ou plus tard comme entrée pour le module de ressource eos_interfaces sans traitement ni transformation supplémentaires.

Modules de ressources

Ainsi, nous avons extrait des faits, normalisé les données, les avons intégrées dans un schéma de structure de données interne standardisé et disposons maintenant d'une source de vérité prête à l'emploi. Hourra ! C'est bien sûr formidable, mais nous devons toujours transformer les paires clé-valeur en une configuration spécifique que la plateforme de l'appareil attend. Nous avons maintenant besoin de modules pour des plateformes spécifiques afin de répondre à ces nouvelles exigences de collecte de faits et de normalisation.

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

Pour expliquer ce que fait un module de ressource, examinons un exemple de playbook qui montre une opération idempotente utilisant les nouveaux faits du ressource réseau et le module eos_l3_interface.

- nom : exemple de faits renvoyés directement à l'appareil.
  hôtes : arista
  collecter_faits : faux
  tâches :
  - nom : récupérer les faits eos d'arista
    eos_facts :
      gather_subset : min
      gather_network_resources : l3_interfaces

  - nom : s'assurer que les informations d'adresse IP sont exactes
    eos_l3_interfaces :
      config : "{{ ansible_network_resources['l3_interfaces'] }}"
      register : result

  - nom : s'assurer que la configuration n'a pas changé
    assert :
      that : not result.changed

Comme vous pouvez le voir, les données recueillies depuis l'appareil sont transmises directement au module de ressources concerné sans transformation. Lors de l'exécution du playbook, les valeurs sont extraites de l'appareil et comparées aux valeurs attendues. Dans cet exemple, les valeurs récupérées correspondent à celles attendues (c'est-à-dire que la vérification des écarts de configuration est effectuée) et un message est affiché indiquant si la configuration a changé.

La meilleure façon de détecter un écart de configuration est de stocker les faits dans des variables Ansible et de les utiliser périodiquement avec le module de ressources en mode de vérification. C'est 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.

Qu'est-ce qui différencie les nouveaux modules de ressources des précédents ?

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

1) Pour une ressource réseau spécifique (qui peut aussi être considérée comme une section de configuration), les modules et les faits se développeront sur tous les systèmes d'exploitation réseau pris en charge simultanément. Nous croyons que si Ansible prend en charge la configuration de la ressource sur une plateforme réseau, nous devons le prendre en charge partout. Cela facilite l'utilisation des modules de ressources, car l'ingénieur en automatisation des réseaux peut maintenant configurer une ressource (comme 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.

• fusionné: la configuration est fusionnée avec la configuration fournie (par défaut);
• remplacé: la configuration de la ressource sera remplacée par la configuration fournie;
• remplacé: la configuration de la ressource sera remplacée par la configuration fournie ; les instances de ressources superflues seront supprimées ;
• supprimé: la configuration de la ressource sera supprimée/restaurée par défaut.

3) Les modules de ressource incluent désormais des valeurs de retour stables. Lorsqu'un module de ressource réseau effectue (ou propose) les modifications nécessaires sur un appareil réseau, il renvoie les mêmes paires clé-valeur dans le playbook.

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

Que signifie tout cela ? Pourquoi est-ce important ?

Cet article décrit de nombreux concepts complexes, mais nous espérons qu'à la fin, vous comprendrez mieux ce que les clients d'entreprise demandent en termes de collecte de faits, de normalisation des données et de configuration de boucle pour une plateforme d'automatisation. Mais pourquoi ont-ils besoin de ces améliorations ? De nombreuses organisations s'engagent actuellement dans une transformation numérique pour rendre leurs environnements IT plus flexibles et compétitifs. Que ce soit bon ou mauvais, de nombreux ingénieurs réseaux deviennent développeurs réseaux - par intérêt personnel ou sur ordre de leurs dirigeants.

Les organisations comprennent que l'automatisation de modèles de réseau individuels ne résout pas le problème de la fragmentation et n'améliore l'efficacité que jusqu'à un certain point. La plateforme Red Hat Ansible Automation Platform fournit des modèles de données de ressources stricts et normalisés pour gérer programmatique les données de base sur un appareil réseau. Cela signifie que les utilisateurs abandonnent progressivement les méthodes de configuration individuelles au profit de méthodes plus modernes axées sur la technologie (par exemple, adresses IP, VLAN, LLDP, etc.), plutôt que sur une implémentation spécifique du fournisseur.

Cela signifie-t-il que les jours des modules de commande et de configuration fiables et éprouvés sont comptés ? Pas du tout. Les modules de ressources attendus ne seront pas applicables dans tous les cas et pour chaque fournisseur, donc les modules de commande et de configuration seront encore nécessaires pour certaines réalisations. L'objectif des modules de ressource est de simplifier des modèles Jinja volumineux et de normaliser des configurations d'appareil non structurées en un format JSON structuré. Avec les modules de ressources, les réseaux existants pourront plus facilement convertir leur configuration en paires clé-valeur structurées, qui constitueront une source de vérité lisible. En utilisant des paires clé-valeur structurées, il sera possible de passer d'exécuter des configurations sur chaque appareil à travailler avec des données structurées indépendantes et de mettre les réseaux au premier plan dans une approche « infrastructure en tant que code ».

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

Avant de détailler ce qu'il y aura dans Ansible 2.9, rappelons-nous 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 mises en gras ont été planifiées et mises en œuvre dans Ansible 2.9.
Sur la base des retours d'expérience des clients d'entreprise et de la communauté, il était logique de s'attaquer d'abord à ces 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 ont été développés par la communauté Ansible :

• exos_lldp_global — d'Extreme Networks.
• nxos_bfd_interfaces — de Cisco
• nxos_telemetry — de Cisco

Comme vous pouvez le voir, le concept des modules de ressources s'inscrit dans notre stratégie d'orientation vers les plateformes. En d'autres termes, nous incluons les capacités et les fonctions nécessaires directement dans Ansible, afin de soutenir la normalisation lors du développement des modules réseau, tout en simplifiant le travail des utilisateurs au niveau des rôles et des playbooks Ansible. Pour étendre le développement des modules de ressources, l'équipe Ansible a publié l'outil Module Builder.

Plans pour Ansible 2.10 et au-delà

Après le lancement d'Ansible 2.9, nous travaillerons sur le prochain ensemble de modules de ressources pour Ansible 2.10, qui pourront être utilisés pour une configuration supplémentaire de la topologie et des politiques réseau, par exemple ACL, OSPF et BGPLe plan de développement peut encore être ajusté, donc si vous avez des commentaires, faites-le nous savoir dans la communauté Ansible Network.

Ressources et démarrage

Communiqué de presse sur la plateforme d'automatisation Ansible
Blog de la plateforme d'automatisation Ansible
L'avenir de la livraison de contenu dans Ansible
Réflexions sur la modification de la structure du projet Ansible

Source : habr.com