Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Utilisation de Junos Snapshot Administrator dans Python (JSNAPy) dans les guides stratégiques Ansible

RÉSUMÉ  Exécutez les tests JSNAPy dans le cadre d’un guide stratégique Ansible pour capturer et auditer les instantanés de l’environnement d’exécution des équipements exécutant Junos OS.

Junos® Snapshot Administrator in Python (JSNAPy) vous permet de capturer et d’auditer des instantanés de l’environnement d’exécution de vos équipements réseau exécutant Junos OS. Vous pouvez capturer et vérifier la configuration et l’état opérationnel d’un équipement et vérifier les modifications apportées à un équipement. Juniper Networks fournit des modules Ansible qui vous permettent d’exécuter des tests JSNAPy sur les équipements exécutant Junos OS dans le cadre d’un guide stratégique Ansible. Le tableau 1 présente les modules disponibles.

Tableau 1 : Modules JSNAPy

Ensemble de contenus

Nom du module

juniper.device Collection

jsnapy

Juniper.junos Rôle

juniper_junos_jsnapy

Pour utiliser les modules, vous devez installer Junos Snapshot Administrator en Python sur le nœud de contrôle Ansible. Pour obtenir des instructions d’installation et des informations sur la création de fichiers de configuration JSNAPy et de test, reportez-vous à la documentation Python de Junos Snapshot Administrator.

Note:

Juniper.junos À partir de la version 2.0.0, le juniper_junos_jsnapy module remplace les fonctionnalités du junos_jsnapy module.

Les sections suivantes décrivent comment utiliser les modules dans les guides stratégiques Ansible.

Présentation du module

Les jsnapy modules vous juniper_junos_jsnapy permettent d’exécuter un grand nombre des mêmes fonctions JSNAPy à partir d’un guide stratégique Ansible que vous pouvez exécuter à l’aide de JSNAPy en ligne de commande, notamment :

  • capture et enregistrement d’un instantané d’environnement d’exécution

  • en comparant deux instantanés

  • en capturant un instantané et en l’évaluant immédiatement

Les modules nécessitent de préciser l’argument action et le config_file ou l’argument test_files . L’argument action spécifie l’action JSNAPy à exécuter. Le tableau 2 présente les valeurs valides action et les commandes JSNAPy équivalentes.

Tableau 2 : Valeurs d’argument d’action jsnapy et juniper_junos_jsnapy

valeur de l’action

Description

Commande JSNAPy équivalente 

check

Comparez deux instantanés existants basés sur les cas de test donnés, ou si aucun cas de test n’est fourni, comparez les instantanés nœud par nœud.

jsnapy --check

snap_post

Prenez des instantanés pour les commandes ou LES RPC spécifiées dans les fichiers de test après avoir apporté des modifications sur les équipements donnés.

jsnapy --snap

snap_pre

Prenez des instantanés pour les commandes ou les RPC spécifiées dans les fichiers de test avant d’apporter des modifications sur les équipements donnés.

jsnapy --snap

snapcheck

Prenez des instantanés des commandes ou des RPC spécifiés dans les fichiers de test et évaluez immédiatement les instantanés en se rapportant à des critères prédéfinis dans les cas de test.

jsnapy --snapcheck

Lorsque vous exécutez JSNAPy sur la ligne de commande, JSNAPy exécute l’action demandée sur les hôtes spécifiés dans la hosts section du fichier de configuration. En revanche, les modules Ansible exécutent l’action demandée sur les hôtes du groupe d’inventaire Ansible défini dans le manuel. En conséquence, le module peut soit faire référence à un fichier de configuration, ignorer la hosts section, soit faire directement référence à un ou plusieurs fichiers de test.

Ainsi, en plus de l’argumentaction, les modules et juniper_junos_jsnapy les jsnapy modules nécessitent également le config_file ou l’argument test_files pour spécifier le fichier de configuration JSNAPy ou les fichiers de test JSNAPy à utiliser pour l’action donnée. Le tableau 3 présente les arguments et test_files les config_file détails.

Tableau 3 : Arguments de fichiers jsnapy et juniper_junos_jsnapy

Argument du module

Valeur

Informations supplémentaires

config_file

Chemin du fichier absolu ou relatif vers un fichier de configuration JSNAPy.

Si le chemin est relatif, le module recherche le fichier de configuration dans les emplacements suivants et dans l’ordre indiqué :

  • Répertoire du guide stratégique Ansible

  • dir argument directory, si fourni

  • Répertoire /etc/jsnapy/testfiles (uniquement si l’argument dir est omis)

Si le fichier de configuration fait référence aux fichiers de test à l’aide d’un chemin de fichier relatif, le module recherche d’abord les fichiers de test dans le répertoire du guide stratégique, puis recherche les fichiers de test dans le répertoire par défaut testfiles , qui varie en fonction de la version JSNAPy et de votre environnement.

test_files

Chemin du fichier absolu ou relatif vers un fichier de test JSNAPy. Il peut s’agir d’un chemin de fichier unique ou d’une liste de chemins de fichiers.

Pour chaque fichier test qui spécifie un chemin relatif, le module recherche le fichier dans les emplacements suivants et dans l’ordre indiqué :

  • Répertoire du guide stratégique Ansible

  • dir argument directory, si fourni

  • Répertoire /etc/jsnapy/testfiles (uniquement si l’argument dir est omis)

Les config_file arguments peuvent test_files prendre un chemin de fichier absolu ou relatif. Si vous utilisez un chemin de fichier relatif, vous pouvez éventuellement inclure l’argument du dir module pour spécifier le répertoire dans lequel se trouvent les fichiers. Si un config_file argument utilise test_files un chemin de fichier relatif, le module recherche d’abord le fichier dans le répertoire du guide stratégique Ansible, même si l’argument dir est présent. Si le fichier n’existe pas dans le répertoire playbook, le module vérifie sous le dir répertoire des arguments, s’il est spécifié, ou dans le répertoire /etc/jsnapy/testfiles , si l’argument dir est omis. Le guide stratégique génère un message d’erreur si le fichier n’est pas trouvé.

L’exemple de guide stratégique suivant exécute l’action à l’aide snap_pre du fichier de configuration configuration_interface_status.yaml . Si le fichier de configuration n’existe pas dans le répertoire du guide stratégique, le module recherche le fichier dans le répertoire personnel de l’utilisateur sous le sous-fichier jsnapy/testfiles .

Note:

À partir de Junos Snapshot Administrator dans Python Version 1.3.0, l’emplacement par défaut pour les fichiers de configuration et de test est ~/jsnapy/testfiles. Toutefois, l’emplacement par défaut dans un environnement virtuel ou pour les versions antérieures est /etc/jsnapy/testfiles.

Le module exécute l’action demandée sur les hôtes spécifiés dans le guide stratégique Ansible, même si le module fait référence à un fichier de configuration qui comprend une hosts section. Le module signale un échec s’il rencontre une erreur et ne parvient pas à exécuter les tests JSNAPy. Il ne rapporte pas d’échec si un ou plusieurs des tests JSNAPy échouent. Pour vérifier les résultats du test JSNAPy, enregistrez la réponse du module et utilisez le assert module pour vérifier le résultat attendu dans la réponse.

Junos Snapshot Administrator dans Python consigne les informations relatives à ses opérations au fichier /var/log/jsnapy/jsnapy.log par défaut. Les jsnapy modules et juniper_junos_jsnapy les modules peuvent inclure l’argument logfile , qui spécifie le chemin d’accès à un fichier en écriture sur le nœud de contrôle Ansible où les informations de la tâche particulière sont enregistrées. Le niveau d’information enregistré dans le fichier est déterminé par le niveau de verbosité d’Ansible et les options de débogage. Par défaut, seuls les messages de niveau de gravité AVERTISSEMENT ou supérieur sont enregistrés. Pour consigner des messages d’un niveau de gravité supérieur ou égal à l’INFO ou au niveau de gravité DEBUG, exécutez le guide stratégique avec l’option -v de -vv ligne de commande, respectivement.

Lorsque vous exécutez des tests JSNAPy dans un guide stratégique Ansible, vous pouvez activer le jsnapy plug-in de rappel pour capturer et synthétiser les informations relatives aux tests JSNAPy défectueux. Pour activer le plug-in de rappel, ajoutez l’instruction callback_whitelist = jsnapy au fichier de configuration Ansible. Pour plus d’informations, voir Activation du plug-in jsnapy Callback.

Prise et comparaison d’instantanés

JSNAPy vous permet de capturer des instantanés d’environnement d’exécution de vos équipements réseau exécutant Junos OS avant et après une modification, puis de comparer les instantanés pour vérifier les modifications attendues ou identifier les problèmes inattendus. juniper_junos_jsnapy Les jsnapy modules Ansible vous permettent de prendre et de comparer les instantanés JSNAPy dans le cadre d’un guide stratégique Ansible. Les modules enregistrent chaque instantané pour chaque hôte dans un fichier distinct dans le répertoire de snapshot JSNAPy par défaut à l’aide d’un nom de fichier prédéfini. Pour plus d’informations sur les fichiers de sortie, consultez Understanding the jsnapy and juniper_junos_jsnapy Module Output.

Pour prendre des instantanés de base d’un ou plusieurs équipements avant d’apporter des modifications, définissez l’argument du action module sur snap_pre, et spécifiez un fichier de configuration ou un ou plusieurs fichiers de test.

Le guide stratégique suivant enregistre les instantanés PRE pour chaque équipement du groupe d’inventaire Ansible. La tâche fait référence au fichier de configuration configuration_interface_status.yaml du répertoire ~/jsnapy/testfiles et consigne les messages au fichier jsnapy_tests.journal dans le répertoire du guide stratégique.

Pour prendre un instantané d’un ou plusieurs équipements après avoir effectué des modifications, définissez l’argument snap_postdu action module sur , et spécifiez un fichier de configuration ou un ou plusieurs fichiers de test.

Le manuel suivant enregistre les instantanés POST pour chaque équipement du groupe d’inventaire Ansible. La tâche fait référence au même fichier de configuration configuration_interface_status.yaml dans le répertoire ~/jsnapy/testfiles et consigne les messages au fichier jsnapy_tests.journal dans le répertoire du guide stratégique.

Lorsque le module juniper_junos_jsnapy exécute une snap_pre action ou une snap_post action, il enregistre chaque instantané pour chaque hôte dans un fichier distinct à l’aide jsnapy de noms de fichier générés automatiquement qui contiennent respectivement une balise « PRE » ou « POST ». Pour comparer les PRE instantanés et POST vérifier rapidement les mises à jour ou identifier les problèmes découlant des modifications, définissez l’argument checkdu action module sur , et spécifiez le même fichier de configuration ou fichier de test utilisé pour prendre les instantanés.

Lorsque le module effectue une check action, les instantanés PRE et POST préexistants pour chaque test sur chaque équipement sont comparés et évalués en fonction des critères définis dans la tests: section des fichiers de test. Si les fichiers de test ne définissent aucun cas de test, JSNAPy compare les instantanés nœud par nœud. Pour vérifier les résultats des tests, enregistrez la réponse du module et utilisez le assert module pour vérifier le résultat attendu dans la réponse.

Le guide stratégique suivant compare les instantanés précédemment exécutés snap_pre et snap_post les actions réalisées pour chaque équipement du groupe d’inventaire Ansible. Les résultats sont évalués à l’aide des critères indiqués dans les fichiers de test référencés dans le fichier de configuration. Le manuel enregistre la réponse du module sous le nom de «test_result » et l’utilise assert pour vérifier que tous les tests ont été réussis sur l’équipement donné.

Lorsque vous exécutez le guide stratégique, les affirmations identifient rapidement les équipements qui ont échoué aux tests.

Exécution des opérations Snapcheck

JSNAPy vous permet de prendre des instantanés des commandes ou des RPC spécifiées dans les fichiers de test JSNAPy et d’évaluer immédiatement les instantanés en fonction de critères prédéfinis dans les cas de test. juniper_junos_jsnapy Les jsnapy modules Ansible vous permettent d’effectuer une opération de contrôle instantané JSNAPy dans le cadre d’un guide stratégique Ansible.

Pour prendre un instantané et l’évaluer immédiatement en fonction de l’ensemble prédéfini de critères dans la tests: section des fichiers de test, définissez l’argument snapcheckdu action module sur , et spécifiez un fichier de configuration ou un ou plusieurs fichiers de test. Pour vérifier les résultats des tests, enregistrez la réponse du module et utilisez le assert module pour vérifier le résultat attendu dans la réponse.

Par exemple, pour chaque équipement du groupe d’inventaire Ansible, le manuel suivant enregistre un instantané distinct pour chaque commande ou RPC dans les fichiers de test, enregistre la réponse du module et utilise le module d’affirmation pour vérifier que tous les tests définis dans les fichiers de test sont transmis à cet équipement.

Comprendre la sortie du module jsnapy et juniper_junos_jsnapy

Lorsque le jsnapy module juniper_junos_jsnapy effectue une snapcheck snap_presnap_postaction, il enregistre automatiquement les instantanés dans le répertoire des instantanés JSNAPy. Les modules utilisent les annuaires JSNAPy par défaut, sauf si vous modifiez le fichier de configuration JSNAPy pour spécifier un autre emplacement. Le module crée un fichier distinct pour chaque commande ou RPC exécutée sur chaque équipement du groupe d’inventaire Ansible. Le tableau 4 présente les noms de fichier des fichiers instantanés pour chaque valeur de l’argumentaction.

Note:

À partir de Junos Snapshot Administrator dans Python Version 1.3.0, les répertoires par défaut pour les fichiers de test JSNAPy et les instantanés sont respectivement ~/jsnapy/testfiles et ~/jsnapy/snapshots. Cependant, les annuaires par défaut dans un environnement virtuel ou pour les versions antérieures sont /etc/jsnapy/testfiles et /etc/jsnapy/snapshots.

Tableau 4 : Nom de fichier de sortie JSNAPy

action Valeur

Fichiers de sortie

snap_pre

hostname_PRE__hashcommand.format

snap_post

hostname_POST__hashcommand.format

snapcheck

hostnamehash_snap_temp__command.format
Ou
hostname_PRE__commandhash.format

Où:

  • hostname— Nom d’hôte de l’unité sur laquelle la commande ou le RPC est exécuté.

  • (pré-| | POST snap_temp) : balise identifiant l’action. L’opération snapcheck utilise la balise dans les PRE versions actuelles ; dans les versions antérieures, l’opération utilise cette snap_temp balise.

  • hash— Hachage généré à partir des kwargs fichiers de test qui incluent les rpc clés.kwargs

    Si les fichiers de test utilisent le même RPC, mais incluent différents arguments et que les RPC sont exécutés sur le même hôte, le hachage garantit dans ces cas-là des noms de fichier de sortie uniques. Si un fichier de test définit la command clé ou si un fichier de test définit la rpc clé sans la kwargs inclure, le hachage est omis.

  • command— Commande ou RPC exécutée sur l’équipement géré. Le module remplace l’espace blanc et les caractères spéciaux dans la commande ou le nom RPC par des traits de soulignement ( _  ).

  • format— Format de la sortie, par exemple, xml.

Note:

Les jsnapy et juniper_junos_jsnapy modules différencient les noms de fichier instantanés uniquement pour une action donnée en fonction du nom et de la commande de l’hôte ou du RPC. Par conséquent, si le module prend des instantanés sur le même équipement pour la même action à l’aide de fichiers de test qui définissent la même commande ou RPC, le module génère des instantanés avec le même nom de fichier et le nouveau fichier remplace l’ancien fichier.

Par exemple, si le module inclut action: "snap_pre" et fait référence à des fichiers de test qui exécutent les show chassis fpc commandes et show interfaces terse les commandes sur les équipements dc1a.example.net et dc1b.example.net, les fichiers résultants sont les suivants :

Si le module inclut action: "snap_post" et fait référence à un fichier test qui exécute le get-interface-information RPC avec kwargs l’élément interface_name: lo0 sur l’équipement dc1a.example.net, le fichier résultant est :

En plus de générer les fichiers instantanés, les modules et juniper_junos_jsnapy les jsnapy modules peuvent également renvoyer les clés suivantes dans la réponse du module :

  • action— Action JSNAPy effectuée par le module.

  • changed: indique si l’état de l’équipement a changé. Puisque JSNAPy ne rapporte que l’état, la valeur est toujours false.

  • failed: indique si la tâche du guide stratégique a échoué.

  • msg— Résultats de test JSNAPy.

Activation du plug-in de rappel jsnapy

Lorsque vous exécutez des tests JSNAPy sur des équipements exécutant Junos OS et qu’un ou plusieurs tests échouent, il peut être difficile d’identifier et d’extraire les tests qui ont échoué si le résultat est important. Le jsnapy plug-in de rappel vous permet d’extraire et de synthétiser facilement les informations pour les tests JSNAPy défectueux. Lorsque vous activez le jsnapy plug-in de rappel et exécutez un guide stratégique comprenant des tests JSNAPy, le plug-in résume les informations relatives aux tests JSNAPy défectueux après le playbook PLAY RECAP.

Le jsnapy plug-in de rappel n’est pas activé par défaut. Pour activer le jsnapy plug-in de rappel, ajoutez l’instruction callback_whitelist = jsnapy au fichier de configuration Ansible.

Lorsque vous activez le jsnapy plug-in de rappel et que vous exécutez un guide stratégique, le plug-in résume les tests JSNAPy échoués dans un format lisible par l’homme. Par exemple :

Exemple : utilisation d’Ansible pour exécuter une opération de vérification Snapcheck JSNAPy

Le jsnapy module vous permet d’exécuter des tests JSNAPy sur les équipements exécutant Junos OS dans le cadre d’un guide stratégique Ansible. Cet exemple utilise le jsnapy module pour effectuer une snapcheck action visant à vérifier l’état opérationnel des équipements exécutant Junos OS après avoir appliqué des modifications de configuration spécifiques.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Nœud de contrôle Ansible s’exécutant :

    • Python 3.7 ou version ultérieure

    • Ansible 2.10 ou version ultérieure avec la juniper.device collection installée

    • Junos PyEZ Version 2.6.0 ou ultérieure

    • Junos Snapshot Administrator dans Python version 1.3.6 ou ultérieure

Avant d’exécuter le guide stratégique Ansible, assurez-vous de :

  • Équipements exécutant Junos OS avec NETCONF sur SSH activés et un compte utilisateur configuré avec les autorisations appropriées

  • Paire de clés publiques/privées SSH configurées pour l’utilisateur approprié sur le nœud de contrôle Ansible et l’équipement exécutant Junos OS

  • Fichier d’inventaire Ansible existant avec les hôtes requis définis

Aperçu

Dans cet exemple, le guide stratégique Ansible configure les sessions d’appairage BGP sur trois équipements exécutant Junos OS et utilise le jsnapy module pour vérifier que la session BGP est établie pour chaque adresse de voisinage. Si le manuel vérifie que les sessions sont établies sur un équipement, il confirme la validation de la nouvelle configuration. Si le guide stratégique ne confirme pas la validation, l’équipement exécutant Junos OS revient automatiquement à la configuration précédemment validée. Le projet Ansible définit respectivement les variables de groupe et d’hôte du manuel sous les annuaires et host_vars les group_vars annuaires.

Le guide stratégique comporte deux pièces de théâtre. Le premier jeu, Load and commit BGP configuration, génère et assemble la configuration, charge la configuration sur l’équipement et la valide à l’aide d’une opération validée. Si la configuration est mise à jour, un gestionnaire est notifié. Le jeu exécute les tâches suivantes :

Remove build directory

Supprime le répertoire de construction existant pour l’équipement donné, le cas échéant.

Create build directory

Crée un nouveau répertoire de construction vide pour l’équipement donné.

Build BGP configuration

Utilise le template module avec le modèle Jinja2 et les variables hôtes pour rendre la configuration BGP de l’équipement donné et l’enregistrer dans un fichier du répertoire de construction de l’équipement.

Assemble configuration parts

Utilise le assemble module pour assembler le fichier de configuration de l’équipement à partir des fichiers du répertoire de construction de cet équipement.

Dans cet exemple, seul le fichier de configuration BGP est présent. Le fichier de configuration résultant est donc identique au fichier de configuration BGP rendu dans la tâche précédente. Si vous ajoutez ultérieurement de nouvelles tâches pour générer des fichiers de configuration supplémentaires à partir d’autres modèles, le assemble module combine tous les fichiers dans une seule configuration.

Load and commit config, require confirmation

Charge la configuration sur l’équipement exécutant Junos OS et valide la configuration à l’aide d’une opération, ce qui nécessite une commit confirmed confirmation explicite pour que la validation devienne permanente. Si cette tâche apporte une modification à la configuration, elle informe également le gestionnaire qui met en pause l’exécution du guide stratégique pendant un certain temps pour permettre aux pairs BGP d’établir des connexions avant l’exécution du deuxième jeu.

Si la configuration demandée est déjà présente sur l’unité, le config module ne charge pas et ne valide pas la configuration. Dans ce cas, le module retourne changed: falseet n’avertit donc pas le gestionnaire.

Le deuxième jeu, , Verify BGPeffectue une opération JSNAPy snapcheck sur chaque équipement à l’aide des tests des fichiers de test JSNAPy et confirme la validation, à condition que tous les tests soient réussis. Le jeu exécute les tâches suivantes :

Execute snapcheck

Exécute une opération JSNAPy snapcheck qui, dans ce cas, valide que la session BGP est établie pour chacun des voisins de l’équipement et qu’il n’y a pas de pairs en bas.

Dans cet exemple, le manuel fait directement référence aux fichiers de test JSNAPy en définissant l’argument test_files au même niveau que la liste des fichiers de test JSNAPy. L’argument dir spécifie le répertoire dans lequel les fichiers de test sont stockés.

Confirm commit

Exécute une opération de vérification de validation, qui confirme l’opération de validation précédente, à condition que le premier playbook a mis à jour la configuration et que tous les tests JSNAPy ont été réussis. Si le guide stratégique met à jour la configuration mais ne confirme pas la validation, l’équipement exécutant Junos OS restaurera automatiquement la configuration précédente.

Note:

Vous pouvez confirmer l’opération de validation précédente avec une commit check ou commit deux opérations sur l’unité, ce qui correspond à l’unité ou commit: true à l’argumentcheck: true, respectivement, dans le config module.

Verify BGP configuration

(Facultatif) Indique explicitement si les tests JSNAPy ont été réussis ou non sur l’équipement donné. Cette tâche n’est pas spécifiquement requise, mais elle identifie plus facilement les échecs des tests JSNAPy et les équipements.

Configuration

Définir les variables de groupe

Procédure étape par étape

Pour définir les variables de groupe :

  • Dans le group_vars/tout fichier, définissez des variables pour le répertoire de construction et les noms de fichier des fichiers de configuration et journaux.

Définir le modèle Jinja2 et les variables hôtes

Définir le modèle Jinja2

Pour créer le modèle Jinja2 utilisé pour générer la configuration BGP :

  1. Créez un fichier nommé bgp-template.j2 dans le répertoire du guide stratégique du projet.

  2. Ajoutez le modèle de configuration BGP au fichier.

Définir les variables de l’hôte

Pour définir les variables hôtes utilisées avec le modèle Jinja2 pour générer la configuration BGP :

  1. Dans le répertoire host_vars du projet, créez un fichier distinct nommé hostname.yaml pour chaque hôte.

  2. Définissez les variables pour l’hôte r1 dans le fichier r1.yaml .

  3. Définissez les variables pour l’hôte r2 dans le fichier r2.yaml .

  4. Définissez les variables pour l’hôte r3 dans le fichier r3.yaml .

Créer les fichiers de test JSNAPy

Procédure étape par étape

Le jsnapy module fait référence aux fichiers de test JSNAPy dans le répertoire ~/jsnapy/testfiles . Pour créer les fichiers de test JSNAPy :

  1. Créez le fichier jsnapy_test_file_bgp_states.yaml , qui exécute la show bgp neighbor commande et teste que l’état de pair BGP est établi.

  2. Créez le fichier jsnapy_test_file_bgp_summary.yaml , qui exécute la show bgp summary commande et affirme que le nombre de pairs en baisse BGP doit être de 0.

Créer le guide stratégique Ansible

Définir le premier jeu pour configurer l’équipement

Pour créer le premier jeu, qui rend la configuration, la charge sur l’équipement et valide la configuration en tant qu’opération confirmée :

  1. Incluez la chaudière pour le guide stratégique et le premier jeu, qui exécute les modules localement.

  2. Créez les tâches qui remplacent le répertoire de construction existant par un répertoire vide, qui stockera les nouveaux fichiers de configuration.

  3. Créez la tâche qui rend la configuration BGP à partir du fichier de modèle Jinja2 et des variables d’hôte, puis la stocke dans le fichier bgp.conf dans le répertoire de construction de cet hôte.

  4. Créez une tâche pour assembler les fichiers de configuration dans le répertoire de construction dans le fichier de configuration junos.conf final.

  5. Créez la tâche qui charge la configuration sur l’unité, effectue une opération de validation qui nécessite une confirmation et informe le gestionnaire donné, à condition que la configuration ait été modifiée.

  6. Créez un gestionnaire qui met en pause l’exécution des guides stratégiques si la configuration de l’équipement est mise à jour et définissez le temps de pause sur une valeur appropriée pour votre environnement.

Définir le deuxième jeu pour exécuter des opérations JSNAPy

Pour créer le deuxième jeu, qui effectue une opération de vérification enfichable JSNAPy et confirme la configuration validée, à condition que la configuration a changé et que les tests JSNAPy aient été réussis :

  1. Incluez la chaudière pour le deuxième jeu, qui exécute les modules localement.

  2. Créez une tâche pour effectuer une opération de vérification enfichable JSNAPy basée sur les tests des fichiers de test JSNAPy donnés, et enregistrez la réponse du module.

  3. Créez la tâche pour confirmer la validation à condition que les conditions données soient remplies.

  4. (Facultatif) Créez une tâche qui utilise le assert module pour affirmer que les tests JSNAPy sont réussis.

Résultats

Sur le nœud de contrôle Ansible, consultez le manuel complet. Si le manuel n’affiche pas le code prévu, répétez les instructions fournies dans cette section pour corriger le manuel.

Exécution du guide stratégique

Pour exécuter le guide stratégique :

  • Émettre la ansible-playbook commande sur le nœud de contrôle et fournir le chemin du guide stratégique et toutes les options souhaitées.

Vérification

Vérifier les voisins BGP

But

Vérifiez que la session BGP est établie pour chaque adresse de voisinage.

Les fichiers de test JSNAPy testent que la session BGP est établie pour chaque adresse de voisinage et qu’il n’y a pas de pairs en panne. Le Verify BGP configuration résultat de la tâche vous permet de vérifier rapidement que l’équipement donné a réussi tous les tests JSNAPy. Si JSNAPy passPercentage est égal à 100 %, la tâche inclut "msg": "All assertions passed" dans la sortie de la tâche.

Action

Vérifiez le résultat de la Verify BGP configuration tâche et vérifiez que chaque équipement renvoie le All assertions passed message.

Sens

Le All assertions passed message indique que les sessions BGP sont établies avec succès sur les équipements.

Dépannage des erreurs du guide stratégique Ansible

Dépannage des erreurs de charge de configuration

Problème

Le guide stratégique Ansible génère une ConfigLoadError erreur indiquant qu’il n’a pas chargé la configuration sur l’équipement en raison d’une erreur de syntaxe.

Solution

Le guide stratégique rend la configuration de Junos OS à l’aide du modèle Jinja2 et des variables hôtes définies pour cet équipement dans le répertoire host_vars . Le manuel génère une erreur de syntaxe lorsque le modèle Jinja2 produit une configuration non valide. Pour corriger cette erreur, mettez à jour le modèle Jinja2 pour corriger l’élément identifié par la bad_element clé du message d’erreur.

Échec du dépannage des tests JSNAPy

Problème

Le Verify BGP configuration résultat de la tâche indique que l’affirmation a échoué, car JSNAPy passPercentage n’était pas égal à 100 %.

L’affirmation échoue lorsque l’équipement n’a pas établi la session BGP avec son voisin ou que la session tombe en panne. Si l’affirmation échoue et que la configuration de cet équipement a été mise à jour dans la première lecture, le guide stratégique ne confirme pas la validation de la nouvelle configuration sur l’équipement, et l’équipement retourne la configuration à la configuration précédemment validée.

Solution

Les tests JSNAPy peuvent échouer si l’opération snapcheck est effectuée avant que les pairs puissent établir la session ou parce que les voisins BGP ne sont pas configurés correctement. Si le résultat du guide stratégique indique que la configuration a été correctement chargée et validée sur l’équipement, essayez d’augmenter l’intervalle de pause du gestionnaire à une valeur appropriée à votre environnement et de repasser le manuel.

Si les tests échouent toujours, vérifiez que le modèle Jinja2 et les variables hôtes de chaque équipement contiennent les données correctes et que la configuration résultante pour chaque équipement est correcte.

Échec du dépannage Confirmations de validation

Problème

La configuration n’a pas été confirmée sur un ou plusieurs équipements.

Solution

Le guide stratégique confirme uniquement la configuration si elle a été modifiée et que JSNAPy a réussi. Si le résultat de la Load and commit config, require confirmation tâche indique que la configuration n’a pas été modifiée, le manuel n’exécute pas la tâche pour confirmer la validation. Si la configuration a changé mais n’a pas été confirmée, les tests JSNAPy ont échoué. Les tests JSNAPy peuvent échouer si les voisins BGP ne sont pas configurés correctement ou si le manuel ne fournit pas assez de temps entre les jeux pour que les équipements établissent la session BGP. Pour plus d’informations, voir Dépannage des tests JSNAPy défectueux.

Tableau Historique des versions
Libération
Description
2.0.0
À partir de La version 2.0.0 de Juniper.junos, le module juniper_junos_jsnapy remplace les fonctionnalités du module junos_jsnapy.