Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Utiliser Ansible pour exécuter des commandes et des RPC sur des équipements Junos

RÉSUMÉ Utilisez les modules Ansible de Juniper Networks pour exécuter des commandes en mode opérationnel et des RPC sur des équipements Junos.

Juniper Networks fournit des modules Ansible que vous pouvez utiliser pour exécuter des commandes en mode opérationnel et des appels de procédure à distance (RPC) sur des équipements Junos. Le tableau 1 présente les modules.

Tableau 1 : modules de commande et RPC

Ensemble de contenu

Nom du module

juniper.device collection

command

rpc

Les sections suivantes expliquent comment utiliser les modules, analyser la réponse du module, spécifier le format de sortie et enregistrer la sortie dans un fichier.

Note:

Pour extraire plus facilement des données ciblées à partir des résultats opérationnels, vous pouvez également utiliser le module avec des juniper.device.table tables opérationnelles Junos PyEZ personnalisées ou prédéfinies. Pour plus d’informations, reportez-vous à la section Utiliser Ansible avec des tables Junos PyEZ pour récupérer des informations opérationnelles à partir de périphériques Junos.

Exécuter des commandes avec les modules Juniper Networks

Le juniper.device.command module vous permet d’exécuter des commandes en mode opérationnel sur les équipements Junos. Le module requiert un argument, commands, qui est une liste d’une ou plusieurs commandes en mode opérationnel Junos OS à exécuter sur le périphérique.

Le playbook suivant exécute deux commandes en mode opérationnel sur chaque périphérique du groupe d’inventaire et affiche la réponse du module en sortie standard. Dans cet exemple, le module s’authentifie command auprès de l’appareil à l’aide de clés SSH à l’emplacement par défaut.

Pour plus d’informations sur la réponse du module et le format de sortie, reportez-vous à Comprendre la réponse du module et à spécifier le format de la commande ou de la sortie RPC.

Comment exécuter des RPC avec les modules Juniper Networks

L’API Junos XML est une représentation XML des instructions de configuration et des commandes en mode opérationnel de Junos OS. Il définit un équivalent XML pour toutes les instructions de la hiérarchie de configuration de Junos OS et de nombreuses commandes en mode opérationnel que vous émettez dans l’interface de ligne de commande de Junos OS. Chaque commande du mode opérationnel avec un équivalent XML Junos est mappée à un élément de balise de requête et, si nécessaire, à un élément de balise de réponse. Les balises de requête sont utilisées dans les appels de procédure à distance (RPC) au sein de sessions de protocole NETCONF ou Junos XML pour demander des informations à un équipement Junos. Le serveur renvoie la réponse à l’aide d’éléments XML Junos inclus dans l’élément de balise de réponse.

Le juniper.device.rpc module vous permet d’exécuter des RPC sur des équipements Junos. Les modules nécessitent un argument, rpcs, qui est une liste d’un ou plusieurs RPC Junos OS à exécuter sur le périphérique.

Le playbook suivant exécute le get-interface-information RPC sur chaque périphérique du groupe d’inventaire et affiche la réponse du module dans la sortie standard. , Le RPC est équivalent à la show interfaces commande du mode opérationnel. Dans cet exemple, le module s’authentifie rpc auprès de l’appareil à l’aide de clés SSH à l’emplacement par défaut.

Note:

Pour plus d’informations sur le mappage des commandes CLI aux balises de requête RPC, reportez-vous à l’explorateur d’API XML Junos pour connaître les balises opérationnelles.

Pour plus d’informations sur la réponse du module et le format de sortie, reportez-vous à Comprendre la réponse du module et à spécifier le format de la commande ou de la sortie RPC.

Le juniper.device.rpc module prend en charge l’option kwargs , qui vous permet de spécifier des arguments et des valeurs de mots-clés pour les RPC. La valeur de kwargs peut être :

  • Un dictionnaire unique de mots-clés et de valeurs

  • Liste des dictionnaires fournissant des arguments pour plusieurs RPC

Il doit y avoir une correspondance biunivoque entre les éléments de la kwargs liste et les RPC de la rpcs liste. Si vous exécutez plusieurs RPC et qu’un RPC ne nécessite aucun argument, définissez l’élément de liste correspondant kwargs sur un dictionnaire {}vide . Si un argument RPC individuel ne nécessite pas de valeur, définissez sa valeur sur true.

Note:

Vous devez utiliser des traits de soulignement dans les arguments RPC à la place des traits d’union, ce qui peut entraîner des exceptions ou des erreurs dans certaines circonstances.

Le playbook suivant exécute les RPC spécifiés sur chaque périphérique du groupe d’inventaire et affiche la réponse du module en sortie standard. Le get-interface-information RPC demande une sortie de niveau laconique pour l’interface lo0.0 et le get-lldp-interface-neighbors RPC demande des informations pour l’interface ge-0/0/0. Le get-software-information RPC utilise un dictionnaire vide pour exécuter le RPC sans arguments supplémentaires.

Comprendre la réponse du module

Les juniper.device.command modules et juniper.device.rpc stockent la réponse RPC de l’appareil dans plusieurs clés différentes dans la réponse du module. Les données de chaque clé sont structurées comme suit :

  • stdout: la réponse RPC est une chaîne unique de plusieurs lignes.

  • stdout_lines: la réponse RPC est une liste de chaînes d’une seule ligne.

  • parsed_output: la réponse RPC est analysée dans une structure de données JSON (JavaScript Object Notation). Cette clé n’est renvoyée que lorsque le format des données est XML ou JSON.

Si le module exécute une seule commande ou RPC, la réponse du module place les clés retournées au niveau supérieur. Si le module exécute plusieurs commandes ou RPC, la réponse du module inclut à la place une results clé, qui est une liste de dictionnaires. Chaque élément de la liste correspond à une seule commande ou RPC et inclut toutes les clés qui seraient renvoyées pour cette commande ou ce RPC.

Par exemple, la réponse suivante correspond à l’exécution d’un seul RPC :

Dans certains cas, la sortie de commande ou RPC peut être étendue, et il peut être nécessaire de supprimer la sortie dans la réponse du module. Pour omettre les clés de sortie dans la réponse du module, incluez-les return_output: false dans la liste d’arguments de ce module.

Spécification du format de la sortie de la commande ou du RPC

Les command modules et rpc stockent la réponse RPC de l’appareil dans plusieurs clés différentes dans la réponse du module : stdout, stdout_lines, et parsed_output. La parsed_output clé, qui n’est présente que lorsque le format de sortie de la commande ou RPC est XML ou JSON, contient des données qui sont analysées dans une structure de données JSON.

Les stdout clés et stdout_lines contiennent des données dans le format par défaut défini pour le module. Par défaut, le command module renvoie la sortie de la commande au format texte, et le rpc module renvoie la sortie RPC au format XML.

Pour spécifier un format de sortie différent, incluez l’argument formats et définissez la valeur égale au format souhaité. Les formats pris en charge sont les suivants :

  • json

  • text

  • xml

Le formats paramètre prend soit une chaîne, soit une liste de chaînes. Lorsque vous exécutez plusieurs commandes ou RPC et que vous ne spécifiez qu’un seul format, le format de sortie est le même pour toutes les commandes et RPC exécutés. Pour spécifier un format différent pour la sortie de chaque commande ou RPC, définissez l’argument formats sur une liste des formats souhaités. La liste doit spécifier le même nombre de formats qu’il y a de commandes ou de RPC.

Le playbook suivant exécute deux RPC sur chaque périphérique du groupe d’inventaire et demande le format texte pour la sortie de tous les RPC exécutés :

Lors de l’exécution du playbook, les stdout touches et stdout_lines de la réponse du module contiennent la réponse RPC au format texte.

Le playbook suivant exécute deux RPC sur chaque périphérique du groupe d’inventaire et demande la sortie du premier RPC au format texte et la sortie du second RPC au format JSON :

Enregistrement de la commande ou de la sortie RPC dans un fichier

Lorsque vous utilisez les juniper.device.command modules et juniper.device.rpc pour exécuter une commande ou un RPC sur un appareil, vous pouvez enregistrer les données renvoyées dans un fichier sur le nœud de contrôle Ansible local en incluant les dest arguments ou dest_dir module. Alors que l’option dest_dir enregistre la sortie de chaque commande ou RPC dans des fichiers distincts pour un périphérique, l’option dest enregistre la sortie de toutes les commandes et RPC dans le même fichier pour un périphérique. Si un fichier de sortie existe déjà avec le nom de la cible, le module écrase le fichier.

Si vous enregistrez les données dans un fichier et que vous ne souhaitez pas dupliquer la commande ou la sortie RPC dans la réponse du module, vous pouvez éventuellement les inclure return_output: false dans la liste des arguments du module. En réglant return_output sur false , le module omet les clés de sortie dans la réponse du module. Cela peut s’avérer nécessaire si l’appareil renvoie une quantité importante de données.

Les sections suivantes expliquent comment utiliser les dest_dir options et dest .

dest_dir

Pour spécifier le répertoire sur le nœud de contrôle Ansible local dans lequel les données récupérées sont enregistrées, incluez l’argument dest_dir et définissez le chemin d’accès au répertoire cible. Le module stocke la sortie de chaque commande ou RPC exécutée sur un périphérique dans un fichier séparé nommé hostname_name.format où :

  • hostname: nom d’hôte du périphérique sur lequel la commande ou le RPC est exécuté.

  • name: nom de la commande ou du RPC exécuté sur l’équipement géré. Le module remplace les espaces dans le nom de la commande par des traits de soulignement ( _ ).

  • format: format de la sortie, qui peut être json, texte ou xml.

Le playbook suivant exécute deux RPC sur chaque périphérique du groupe d’inventaire et enregistre la sortie de chaque RPC pour chaque périphérique dans un fichier distinct dans le répertoire playbook du nœud de contrôle Ansible :

Les fichiers de sortie résultants pour les dc1a.example.net de l’hôte sont les suivants :

  • dc1a.example.net_get-software-information.xml

  • dc1a.example.net_get-system-uptime-information.xml

De même, le playbook suivant exécute les commandes équivalentes sur chaque périphérique du groupe d’inventaire et enregistre la sortie de chaque commande pour chaque périphérique dans un fichier distinct dans le répertoire playbook du nœud de contrôle Ansible :

Les fichiers de sortie résultants pour les dc1a.example.net de l’hôte sont les suivants :

  • dc1a.example.net_show_version.texte

  • dc1a.example.net_show_system_uptime.texte

Dest

Pour spécifier le chemin d’accès et le nom de fichier dans lesquels toutes les sorties de commande ou RPC d’un noeud cible sont enregistrées sur le noeud de contrôle Ansible local, incluez l’argument dest et définissez le nom de fichier ou le chemin d’accès complet du fichier. Si vous incluez l’argument dest , mais omettez le répertoire, les fichiers sont enregistrés dans le répertoire playbook. Si vous exécutez des commandes ou des RPC sur plusieurs périphériques, l’argument dest doit inclure une variable telle que {{ inventory_hostname }} pour différencier le nom de fichier pour chaque périphérique. Si vous ne différenciez pas les noms de fichiers, le fichier de sortie de chaque périphérique écrasera le fichier de sortie des autres périphériques.

Le guide suivant exécute les RPC sur chaque appareil du groupe d’inventaire. La sortie de tous les RPC est stockée dans un fichier distinct pour chaque périphérique, et le fichier est placé dans le répertoire playbook sur le nœud de contrôle Ansible. Chaque fichier est identifié de manière unique par le nom d’hôte de l’appareil.

Par exemple, le fichier de sortie résultant pour le dc1a.example.net de l’hôte est dc1a.example.net-system-information.xml et contient la sortie de tous les RPC exécutés sur le périphérique.