Geekly articles weekly

Nouvelles fonctionnalités d'automatisation réseau dans Red Hat Ansible

À la lumière des améliorations significatives mises en œuvre dans Ansible Engine 2.6, ainsi que de la prise en compte de la sortie d'Ansible Tower 3.3 et de la récente version d'Ansible Engine 2.7, examinons de plus près les perspectives d'automatisation du réseau.



Dans cet article:

  • Plugin de connexion Httpapi.
    • Prise en charge d'Arista eAPI et de Cisco NX-API.
  • Nouveaux modules d'automatisation de réseau.
    • net_get et net_put.
    • netconf_get, netconf_rpc et netconf_config.
    • cli_command et cli_config.
  • Amélioration de l'interface Web d'Ansible Tower.
  • Gérez les informations d'identification dans Ansible Tower lorsque vous travaillez avec des périphériques réseau.
  • Utilisation de différentes versions d'Ansible dans Tower en même temps

N'oubliez pas que la sortie de chaque nouvelle version d'Ansible est accompagnée d'une mise à jour du guide de portage , ce qui facilitera grandement la transition vers la nouvelle version.

Plugin de connexion HTTPAPI


Les plugins de connexion permettent à Ansible de se connecter aux hôtes cibles, puis d'effectuer des tâches sur eux. Depuis Ansible 2.5, un nouveau plugin de ce type appelé network_cli est apparu. Il élimine le besoin d'utiliser le paramètre du fournisseur et standardise l'ordre d'exécution des modules réseau, à la suite de quoi les playbooks pour les périphériques réseau sont maintenant exécutés, exécutés et fonctionnent de la même manière que les playbooks pour les hôtes Linux. À son tour, pour Ansible Tower, la différence entre les périphériques réseau et les hôtes disparaît et il n'est plus nécessaire de faire la distinction entre les noms d'utilisateur et les mots de passe pour les périphériques réseau et pour les machines. Cela a été discuté plus en détail ici , mais en bref, les mots de passe de connexion pour le serveur Linux et le commutateur Arista EOS ou routeur Cisco peuvent maintenant être utilisés et stockés de manière similaire.

Dans Ansible 2.5, la connexion via les méthodes eAPI et NX-API n'était possible qu'en utilisant l'ancienne méthode du fournisseur. Ansible 2.6 n'a plus cette limitation et vous pouvez utiliser librement la méthode de connexion httpapi de haut niveau. Voyons comment cela se fait.

Vous devez d'abord activer l'eAPI ou l'API NX sur le périphérique réseau pour pouvoir ensuite utiliser la méthode httpapi. Cela se fait facilement avec la commande Ansible appropriée, par exemple, voici comment activer eAPI sur un commutateur Arista EOS.

[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] }

Lorsqu'elle est connectée à un véritable commutateur EOS Arista, la commande show management api http-commandes montrera que l'API est activée:

 leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>>

Le script Ansible Playbook ci-dessous exécute simplement la commande show version, puis dans la section de débogage renvoie uniquement la version à partir de la sortie JSON de la tâche.

 --- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]

L'exécution de ce script entraînera le résultat suivant:

 [user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0

REMARQUE: Arista eAPI ne prend pas en charge les versions raccourcies des commandes (telles que «show ver» au lieu de «show version2), vous devez donc toutes les écrire. Pour plus d'informations sur le plug-in de connexion httpapi, consultez la documentation.

Nouveaux modules d'automatisation de réseau


Ansible 2.6 et la version 2.7 lancée en octobre offrent sept nouveaux modules pour l'automatisation du réseau.

  • net_get - Copie un fichier d'un périphérique réseau vers Ansible Controller.
  • net_put - Copie un fichier d'Ansible Controller sur un périphérique réseau.
  • netconf_get - Récupère les données de configuration / état d'un périphérique réseau avec NETCONF activé.
  • netconf_rpc - Effectue des opérations sur un périphérique réseau avec NETCONF activé.
  • netconf_config - configuration du périphérique netconf , le module permet à l'utilisateur d'envoyer un fichier XML aux périphériques netconf et de vérifier si la configuration a changé.
  • cli_command - exécute la commande cli sur les périphériques réseau qui ont une interface de commande (cli).
  • cli_config - Envoie (push) la configuration du texte aux périphériques réseau via network_cli.

net_get et net_put


  • net_get - Copie un fichier d'un périphérique réseau vers Ansible Controller.
  • net_put - Copie un fichier d'Ansible Controller sur un périphérique réseau.

Les modules net_get et net_put ne sont liés à l'équipement d'aucun fabricant particulier et copient simplement les fichiers du périphérique réseau vers des périphériques utilisant des protocoles de transfert SCP ou SFTP standard (spécifiés par le paramètre de protocole). Ces deux modules nécessitent l'utilisation de la méthode de connexion network_cli et ne fonctionnent également que si scp (pip install scp) est installé sur le contrôleur et SCP ou SFTP est activé sur le périphérique réseau.

Nous supposons que dans l'exemple de notre playbook, nous avons déjà exécuté la commande suivante sur le périphérique Leaf01:

 leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.

Voici à quoi ressemble un playbook avec deux tâches (le premier copie le fichier du périphérique Leaf01 et le second copie le fichier sur le périphérique Leaf01):

 --- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt

netconf_get, netconf_rpc et netconf_config



  • netconf_get - Récupère les données de configuration / état d'un périphérique réseau avec NETCONF activé.
  • netconf_rpc - Effectue des opérations sur un périphérique réseau avec NETCONF activé.
  • netconf_config - configuration du périphérique netconf , le module permet à l'utilisateur d'envoyer un fichier XML aux périphériques netconf et de vérifier si la configuration a changé.

Le protocole de gestion de réseau NETCONF (Network Configuration Protocol) est développé et normalisé par l'IETF. Selon la RFC 6241, NETCONF peut être utilisé pour installer, manipuler et supprimer des configurations de périphériques réseau. NETCONF est une alternative à la ligne de commande SSH (network_cli) et aux API comme Cisco NX-API ou Arista eAPI (httpapi).

Pour illustrer les nouveaux modules netconf, nous activons d'abord netconf sur les routeurs Juniper en utilisant le module junos_netconf . Netconf n'est pas pris en charge sur tous les modèles d'équipement réseau, vérifiez donc votre documentation avant de l'utiliser.

 [user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] }

Juniper Networks propose l'explorateur d'API XML Junos pour les balises opérationnelles et les balises de configuration . Prenons l'exemple de la demande opérationnelle que Juniper Networks utilise dans sa documentation pour illustrer la demande RPC pour une interface spécifique.

 <rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>

Il est facilement traduit en Ansible Playbook. get-interface-information est un appel RPC et des paramètres supplémentaires sont spécifiés sous forme de paires clé-valeur. Dans cet exemple, il n'y a qu'un seul paramètre - nom-interface - et sur notre périphérique réseau, nous voulons simplement regarder em1.0. Nous utilisons le paramètre de registre qui a été défini pour la tâche, juste pour enregistrer les résultats, nous utilisons donc le module de débogage et affichons les résultats sur l'écran du terminal. Le module netconf_rpc vous permet également de traduire la sortie XML directement en JSON.

 --- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info

Après avoir démarré le playbook, nous obtenons ceci:

 ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>>

Pour plus d'informations, consultez le Juniper Platform Guide et la documentation NETCONF .

cli_command et cli_config


  • cli_command - exécute une commande sur les périphériques réseau en utilisant leur interface de ligne de commande (s'il y en a une).
  • cli_config - Envoie (push) la configuration du texte aux périphériques réseau via network_cli.

Les modules cli_command et cli_config qui sont apparus dans Ansible Engine 2.7 ne sont pas non plus liés à l'équipement d'un fabricant particulier et peuvent être utilisés pour automatiser diverses plates-formes réseau. Ils sont basés sur la valeur de la variable ansible_network_os (définie dans le fichier d'inventaire ou dans le dossier group_vars) pour utiliser le plugin cliconf souhaité. Une liste de toutes les valeurs de la variable ansible_network_os est fournie dans la documentation . Dans cette version d'Ansible, vous pouvez toujours utiliser les anciens modules pour des plateformes spécifiques, alors prenez votre temps pour réécrire les playbooks existants. Pour plus d'informations, consultez les guides de portage officiels .



Voyons comment ces modules sont utilisés dans Ansible Playbook. Ce playbook s'exécutera sur deux systèmes Cisco Cloud Services Routers (CSR) exécutant IOS-XE. La variable ansible_network_os dans le fichier d'inventaire est définie sur ios.

 <config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios

Voici comment cli_config et cli_command sont utilisés:

 --- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout

Et voici la sortie de ce playbook:

 [user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0

Veuillez noter que ces modules sont idempotents tant que vous utilisez la syntaxe appropriée pour les périphériques réseau correspondants.

Interface de tour Ansible améliorée


L'interface Web de Red Hat Ansible Tower 3.3 est devenue plus pratique et fonctionnelle, permettant moins de clics lors de l'exécution de diverses tâches.



La gestion des informations d'identification, le planificateur de tâches, les scripts d'inventaire, le contrôle d'accès basé sur les rôles, les notifications et bien plus sont désormais collectés dans le menu principal sur le côté gauche de l'écran et sont disponibles en un clic. L'écran d'affichage des travaux d'affichage des travaux affiche immédiatement des informations supplémentaires importantes: qui a commencé la tâche et quand; quel inventaire a été élaboré au cours de sa mise en œuvre; de quel projet le livre de jeu est-il tiré?



Gérer les informations d'identification pour les périphériques réseau dans Ansible Tower


Red Hat Ansible Tower 3.3 facilite la gestion des mots de passe de connexion pour les périphériques réseau. Dans la nouvelle interface Web, la commande Credentials se trouve immédiatement dans le menu principal, dans le groupe Resources.



Ansible Tower 3.3 a laissé un type d'informations d'identification appelé «réseau» spécial (réseau), qui définit les variables d'environnement ANSIBLE_NET_USERNAME et ANSIBLE_NET_PASSWORD utilisées dans l'ancienne méthode du fournisseur. Tout cela fonctionne toujours, comme indiqué dans la documentation , afin que vous puissiez utiliser les scripts Ansible Playbooks existants. Cependant, pour les nouvelles méthodes de haut niveau de connexion de httpapi et network_cli, le type d'informations d'identification réseau n'est plus nécessaire, car désormais Ansible fonctionne de la même manière avec les connexions par mot de passe qu'avec connexion aux périphériques réseau, et donc lors de la connexion aux hôtes Linxu. Par conséquent, pour les périphériques réseau, vous devez maintenant sélectionner le type d'informations d'identification de la machine - il suffit de le sélectionner et d'entrer votre mot de passe de connexion ou de fournir une clé SSH.



REMARQUE: Ansible Tower crypte le mot de passe immédiatement après avoir enregistré les informations d'identification.



Grâce au chiffrement, les informations d'identification peuvent être déléguées en toute sécurité à d'autres utilisateurs et groupes - ils ne verront ou ne reconnaîtront tout simplement pas le mot de passe. Pour plus d'informations sur le fonctionnement des informations d'identification, le chiffrement utilisé et les autres types d'informations d'identification (tels qu'Amazon AWS, Microsoft Azure et Google GCE) se trouvent dans la documentation Ansible Tower .

Une description plus détaillée de Red Hat Ansible Tower 3.3 peut être trouvée ici .

Utilisation de différentes versions d'Ansible dans Tower en même temps


Supposons que nous souhaitons que certains playbooks s'exécutent via Ansible Engine 2.4.2 et d'autres via Ansible Engine 2.6.4. Tower dispose d'un outil virtualenv spécial pour créer des sandbox Python afin d'éviter les conflits avec les dépendances conflictuelles et les différentes versions. Ansible Tower 3.3 vous permet de définir virtualenv à différents niveaux: organisation, projet ou modèle de tâche. Voici à quoi ressemble le modèle de tâche que nous avons créé dans Ansible Tower pour sauvegarder notre réseau.



Lorsque vous disposez d'au moins deux environnements virtuels, le menu déroulant Environnement Ansible apparaît dans le menu principal d'Ansible Tower, où vous pouvez facilement spécifier la version d'Ansible à utiliser lors de l'exécution de la tâche.



Par conséquent, si vous disposez d'un mélange de playbooks pour automatiser le réseau, dont certains utilisent l'ancienne méthode du fournisseur (Ansible 2.4 et versions précédentes), et certains utilisent de nouveaux plugins httpapi ou network_cli (Ansible 2.5 et supérieur), vous pouvez facilement affecter chaque tâche Version ansible. De plus, cette fonctionnalité sera utile si les développeurs et la production utilisent des versions différentes d'Ansible. En d'autres termes, vous pouvez mettre à jour Tower en toute sécurité, sans vous soucier qu'après cela, vous devrez passer à n'importe quelle version d'Ansible Engine, ce qui augmente considérablement la flexibilité dans l'automatisation de divers types d'équipements et d'environnements réseau, ainsi que des scénarios d'utilisation.

Pour plus d'informations sur l'utilisation de virtualenv, consultez la documentation .

Source: https://habr.com/ru/post/fr436318/

More articles:


All Articles