Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Utiliser Ansible pour configurer les équipements Junos

Utilisez les modules Ansible de Juniper Networks pour gérer la configuration sur les équipements Junos.

Juniper Networks fournit un module Ansible qui vous permet de configurer les équipements Junos. Le tableau 1 présente les modules disponibles. Le compte d’utilisateur utilisé pour apporter des modifications à la configuration doit disposer des autorisations nécessaires pour modifier les parties pertinentes de la configuration sur chaque appareil.

Tableau 1 : Module de gestion de la configuration

Ensemble de contenu

Nom du module

juniper.device collection

config

Les sections suivantes expliquent comment utiliser le module pour modifier et valider la configuration sur les équipements Junos.

Vue d’ensemble du module

Le juniper.device.config module vous permet d’effectuer les opérations suivantes sur les équipements Junos :

  • Charger les données de configuration

  • Valider la configuration

  • Restaurer la configuration

  • Charger la configuration de sauvetage

Pour modifier la configuration, la liste d’arguments du module doit inclure soit le paramètre pour charger les load nouvelles données de configuration, soit le rollback paramètre pour revenir à la configuration de secours ou à une configuration précédemment validée. Le processus de base pour apporter des modifications de configuration consiste à verrouiller la configuration, à charger les modifications de configuration, à valider la configuration pour qu’elle soit active, puis à déverrouiller la configuration.

Par défaut, le config module apporte des modifications à la base de données de configuration candidate à l’aide configure exclusive du mode, qui verrouille et déverrouille automatiquement la configuration globale candidate. Vous pouvez également spécifier un autre mode de configuration. Par exemple, vous pouvez apporter des modifications à une copie privée de la configuration candidate ou à la base de données de configuration éphémère. Pour plus d’informations sur la spécification du mode de configuration, reportez-vous à la section Comment spécifier le mode de configuration.

Lors du chargement de nouvelles données de configuration, en plus de spécifier le mode de configuration, vous pouvez également spécifier l’opération de chargement ainsi que la source et le format des modifications.

Le config module vous permet également de charger et de valider la configuration de sauvetage ou de restaurer la configuration à une configuration précédemment validée. Pour charger la configuration de secours ou une configuration précédemment validée, vous devez inclure l’argument rollback module. Pour plus d’informations, consultez les sections suivantes :

Après avoir modifié la configuration, vous devez valider la configuration pour en faire la configuration active sur l’appareil. Par défaut, le config module valide les modifications apportées à la configuration. Pour modifier ce comportement ou fournir des options de validation supplémentaires, reportez-vous à la section Comment valider la configuration.

Par défaut, lorsque le config module inclut les load arguments or rollback pour modifier la configuration, le module renvoie automatiquement les modifications de configuration au format diff ou patch dans la réponse du module. Les différences sont renvoyées dans les diff variables and diff_lines . Pour empêcher le module de calculer et de renvoyer les différences, définissez l’argument diff module sur false.

Comment spécifier le mode de configuration

Vous pouvez spécifier le mode de configuration à utiliser lors de la modification de la configuration de l’appareil. Pour spécifier le mode de configuration dans votre tâche, incluez le config paramètre du config_mode module. Les modes de configuration pris en charge sont les suivants :

  • batch

  • dynamic

  • ephemeral

  • exclusive

  • private

Par défaut, le juniper.device.config module apporte des modifications à la base de données de configuration candidate à l’aide du configure exclusive mode. Le mode Configurer exclusif verrouille la configuration globale candidate (également appelée base de données de configuration partagée) aussi longtemps que le module a besoin d’apporter les modifications demandées à la configuration. Le verrouillage de la base de données empêche les autres utilisateurs de modifier la base de données ou d’y apporter des modifications jusqu’à ce que le verrou soit levé.

Les exemples suivants montrent comment configurer une copie privée de la configuration candidate et comment configurer la base de données éphémère.

Exemple : config_mode : « privé »

Le playbook suivant utilise private le mode de configuration pour modifier une copie privée de la configuration candidate :

Configurer la base de données éphémère

Vous pouvez utiliser le juniper.device.config module pour mettre à jour la base de données de configuration éphémère sur les appareils qui prennent en charge cette base de données. La base de données éphémère est une base de données de configuration alternative qui fournit une interface de programmation rapide pour effectuer des mises à jour de configuration sur les équipements Junos.

Pour ouvrir et configurer l’instance par défaut de la base de données de configuration éphémère, incluez l’argument config_mode: "ephemeral" . Par exemple:

Pour ouvrir et configurer une instance existante définie par l’utilisateur de la base de données de configuration éphémère, incluez l’argument config_mode: "ephemeral" et définissez-le ephemeral_instance sur le nom de l’instance.

Comment spécifier l’action de chargement

Le juniper.device.config module prend en charge le chargement des modifications de configuration à l’aide d’un grand nombre des mêmes opérations de chargement que celles prises en charge dans l’interface de ligne de commande de Junos OS. Vous spécifiez l’opération de chargement en incluant le paramètre dans la load liste des arguments du module et en le définissant sur la valeur de l’opération de chargement correspondante. Le tableau 2 récapitule les réglages des paramètres requis pour chaque type d’opération de chargement.

Tableau 2 : Paramètres de spécification de l’opération de chargement

Opération de chargement

Argument load

Description

load merge

load: "merge"

Fusionnez la configuration chargée avec la configuration existante.

load override

load: "override"

Remplacez l’ensemble de la configuration par la configuration chargée.

load patch

load: "patch"

Chargez les données de configuration à partir d’un fichier de correctif.

load replace

load "replace"

Fusionnez la configuration chargée avec la configuration existante, mais remplacez les instructions de la configuration existante par celles qui spécifient la replace: balise dans la configuration chargée. S’il n’y a pas d’instruction dans la configuration existante, l’instruction dans la configuration chargée est ajoutée.

load set

load: "set"

Chargez les données de configuration au set format. Les données de configuration sont chargées ligne par ligne et peuvent contenir des commandes de mode de configuration telles que set, delete, et deactivate.

load update

load: "update"

Comparez la configuration chargée complète à la configuration existante. Chaque élément de configuration différent dans la configuration chargée remplace son élément correspondant dans la configuration existante. Lors de l’opération de validation, seuls les processus système affectés par les éléments de configuration modifiés analysent la nouvelle configuration.

Comment spécifier le format des données de configuration à charger

Le juniper.device.config module vous permet de configurer les équipements Junos à l’aide de l’un des formats standard pris en charge. Vous pouvez fournir des données de configuration sous forme de chaînes ou de fichiers. Les fichiers peuvent contenir des données de configuration ou des modèles Jinja2. Lorsque vous fournissez des données de configuration dans une chaîne, un fichier ou un modèle Jinja2, les formats pris en charge pour les données sont le texte, les éléments XML Junos, les commandes Junos OS set et JSON.

Le config module tente de détecter automatiquement le format des données de configuration que vous fournissez sous forme de chaînes dans l’argument lines . Toutefois, vous pouvez spécifier explicitement le format des chaînes en incluant l’argument format . Lorsque vous fournissez des données de configuration dans un fichier ou un modèle Jinja2, vous devez spécifier le format des données soit en ajoutant l’extension appropriée au fichier, soit en incluant l’argument format .

Le Tableau 3 récapitule les formats pris en charge pour les données de configuration et la valeur correspondante pour l’extension de fichier et format le paramètre. Si vous incluez l’argument format , il remplace à la fois le format de détection automatique des chaînes et le format indiqué par une extension de fichier.

Tableau 3 : spécification du format des données de configuration

Format des données de configuration

Extension de fichier

format Paramètre

Instructions de configuration de l’interface de ligne de commande (texte)

.Conf

« text »

Notation d’objet JavaScript (JSON)

.json

« json »

set Commandes Junos OS

.poser

« set »

Éléments XML Junos

.xml

« xml »

Note:

Lorsque vous définissez l’argument du load module sur 'override' ou 'update', vous ne pouvez pas utiliser le format de commande Junos OS set .

Comment charger des données de configuration sous forme de chaînes

Le juniper.device.config module vous permet de charger des données de configuration à partir d’une liste de chaînes. Pour charger des données de configuration sous forme de chaînes, incluez l’argument approprié load et l’argument lines . L’argument lines prend une liste de chaînes contenant les données de configuration à charger.

Le module tente de détecter automatiquement le format des données de lines configuration. Toutefois, vous pouvez spécifier explicitement le format en incluant l’argument format . Pour plus d’informations sur la spécification du format, reportez-vous à la section Comment spécifier le format des données de configuration à charger. Si vous incluez l’argument format , il remplace le format détecté automatiquement.

Le playbook suivant configure et valide deux scripts d’opération. Dans ce cas, l’argument load a la valeur 'set', car les données de configuration utilisent lines le format d’instruction Junos OS set .

Le playbook suivant configure les mêmes instructions en utilisant lines des données de configuration au format texte. Dans ce cas, load: "merge" est utilisé.

Comment charger des données de configuration à partir d’un fichier local ou distant

Le juniper.device.config module vous permet de charger des données de configuration à partir d’un fichier. Le fichier peut résider dans l’un des emplacements suivants :

  • nœud de contrôle Ansible

  • Appareil client

  • URL accessible à partir de l’appareil client

Lorsque vous chargez des données de configuration à partir d’un fichier, vous devez indiquer l’emplacement du fichier et le format des données de configuration dans le fichier. Les formats de données de configuration pris en charge sont le texte, les éléments XML Junos, les commandes Junos OS set et JSON. Pour plus d’informations sur le chargement de fichiers contenant des modèles Jinja2, consultez Comment charger des données de configuration à l’aide d’un modèle Jinja2.

Vous pouvez spécifier le format des données de configuration soit en incluant explicitement le format paramètre dans la liste d’arguments du module, soit en ajoutant l’extension appropriée au fichier de données de configuration. Si vous spécifiez le format paramètre, il remplace le format indiqué par l’extension du fichier. Pour plus d’informations sur la spécification du format, reportez-vous à la section Comment spécifier le format des données de configuration à charger. Lorsque les données de configuration utilisent le format XML Junos, vous devez placer les données dans la balise de niveau <configuration> supérieur.

Note:

Vous n’avez pas besoin d’inclure des données de configuration au format texte ASCII, des commandes Junos OS set ou JSON dans <configuration-text>, <configuration-set>ou <configuration-json> des balises comme requis lors de la configuration du périphérique directement dans une session NETCONF.

Le Tableau 4 présente les paramètres de module que vous pouvez inclure pour spécifier l’emplacement du fichier.

Tableau 4 : Spécification de l’emplacement du fichier de configuration

Paramètre du module

Description

src

Chemin d’accès absolu ou relatif à un fichier sur le nœud de contrôle Ansible. Le répertoire par défaut est le répertoire playbook.

url

Chemin absolu ou relatif vers un fichier sur l’équipement client, un emplacement FTP ou une URL HTTP.

Le répertoire par défaut sur l’appareil client est le répertoire de travail courant, qui est par défaut le répertoire personnel de l’utilisateur.

Pour charger des données de configuration à partir d’un fichier local sur le nœud de contrôle Ansible, définissez l’argument src sur le chemin absolu ou relatif du fichier contenant les données de configuration. Par exemple:

Pour charger des données de configuration à partir d’un fichier sur l’équipement Junos ou d’une URL FTP ou HTTP, utilisez le url paramètre et spécifiez le chemin d’accès du fichier contenant les données de configuration à charger. Par exemple:

La valeur de peut url être un chemin d’accès de fichier local absolu ou relatif, un emplacement FTP ou une URL HTTP.

  • Le chemin d’accès à un fichier local sur l’équipement cible se présente sous l’une des formes suivantes :

    • /path/filename : fichier sur un système de fichiers monté, soit sur le disque flash local, soit sur le disque dur.

    • un:filename ou a :path/filename—Fichier sur le lecteur local. Le chemin par défaut est / (le répertoire de niveau racine). Le support amovible peut être au format MS-DOS ou UNIX (UFS).

  • Le chemin d’accès à un fichier sur un serveur FTP se présente sous la forme suivante :

  • Le chemin d’accès à un fichier sur un serveur HTTP se présente sous la forme suivante :

Dans chaque cas, la valeur par défaut de la path variable est le répertoire personnel de l’utilisateur. Pour spécifier un chemin absolu, l’application commence le chemin par les caractères %2F ; par exemple, ftp://username :password@hostname/%2Fpath/filename.

Comment charger des données de configuration à l’aide d’un modèle Jinja2

Le juniper.device.config module vous permet d’afficher les données de configuration à partir d’un fichier modèle Jinja2 sur le nœud de contrôle Ansible, puis de charger et valider la configuration sur un équipement Junos. Jinja est un moteur de modèles pour Python qui vous permet de générer des documents à partir de modèles prédéfinis. Les modèles, qui sont des fichiers texte dans la langue souhaitée, offrent une grande flexibilité grâce à l’utilisation d’expressions et de variables. Vous pouvez créer des données de configuration Junos OS à l’aide de modèles Jinja2 dans l’un des formats de configuration pris en charge, notamment le texte ASCII, les éléments XML Junos, les commandes Junos OS set et JSON. Le module Ansible utilise le modèle Jinja2 et un dictionnaire de variables fourni pour restituer les données de configuration.

Pour charger et valider les données de configuration à l’aide d’un modèle Jinja2, incluez les template paramètres et vars dans la liste des arguments du module.

  • template—Chemin d’accès au fichier de modèle Jinja2

  • vars: dictionnaire des clés et des valeurs requises pour le rendu du modèle Jinja2

Vous devez également inclure le format paramètre lorsque l’extension de fichier du modèle n’indique pas le format des données. Pour plus d’informations sur la spécification du format, reportez-vous à la section Comment spécifier le format des données de configuration à charger.

Par exemple, le fichier interfaces-mpls.j2 contient le modèle Jinja2 suivant :

Pour utiliser le juniper.device.config module afin de charger le modèle Jinja2, définissez l’argument template sur le chemin du fichier de modèle et définissez les variables requises par le modèle dans le vars dictionnaire. Le playbook suivant utilise le modèle Jinja2 et les variables définies dans vars pour afficher les données de configuration, les charger et les valider sur l’hôte cible. Le format paramètre indique le format des données de configuration dans le fichier modèle.

Le module génère les données de configuration suivantes, qui sont chargées dans la configuration candidate sur l’équipement et validées :

Comment charger la configuration de sauvetage

Une configuration de secours vous permet de définir une configuration de travail connue ou une configuration dont l’état est connu que vous pouvez restaurer à tout moment. Vous pouvez utiliser la configuration de secours lorsque vous devez revenir à une configuration connue ou, en dernier recours, si la configuration de l’appareil et les fichiers de configuration de sauvegarde sont irréparables. Lorsque vous créez une configuration de secours, l’appareil enregistre la configuration la plus récemment validée en tant que configuration de secours.

Le juniper.device.config module vous permet de revenir à une configuration de sauvetage existante sur les équipements Junos. Pour charger et valider la configuration de sauvetage sur un périphérique, incluez l’argument du rollback: "rescue" module. Par exemple:

Comment restaurer la configuration

Les équipements Junos stockent une copie de la dernière configuration validée et jusqu’à 49 configurations précédentes, en fonction de la plate-forme. Vous pouvez revenir à n’importe laquelle des configurations stockées. Ceci est utile lorsque des modifications de configuration entraînent des résultats indésirables et que vous souhaitez revenir à une configuration de travail connue. La restauration de la configuration est similaire au processus de modification de la configuration sur l’appareil, mais au lieu de charger les données de configuration, vous effectuez une restauration, qui remplace l’intégralité de la configuration candidate par une configuration précédemment validée.

Le juniper.device.config module vous permet de revenir à une configuration précédemment validée sur les équipements Junos. Pour restaurer la configuration et la valider, incluez l’argument du rollback module et spécifiez l’ID de la configuration de restauration. Les valeurs d’ID valides sont égales à 0 (zéro, pour la configuration validée la plus récente) à une unité de moins que le nombre de configurations précédentes stockées (le maximum est de 49).

Le playbook suivant demande l’ID de restauration de la configuration à restaurer, annule la configuration et la valide, puis imprime les modifications de configuration en sortie standard :

Comment valider la configuration

Par défaut, lorsque vous utilisez le juniper.device.config module pour modifier la configuration à l’aide de l’argument load ou de l’argument rollback , le module effectue automatiquement une vérification de validation et valide les modifications. Pour empêcher le module d’effectuer une vérification de validation ou de valider les modifications, définissez l’argument check ou commit sur false, respectivement.

Vous pouvez également personnaliser l’opération de validation à l’aide d’un grand nombre des options disponibles dans l’interface de ligne de commande de Junos OS. Le Tableau 5 présente les arguments de module que vous pouvez utiliser pour spécifier différentes options de validation.

Tableau 5 : Options de validation

Module Argument

Description

Valeur par défaut pour load et rollback opérations

check: boolean

Effectuez une vérification de validation ou confirmez une opération de validation confirmée précédente.

true

check_commit_wait: seconds

Attendez le nombre de secondes spécifié entre la vérification de validation et l’opération de validation.

comment: "string"

Consignez un commentaire pour cette opération de validation dans le fichier journal système et dans l’historique des validations de l’appareil.

commit: boolean

Validez les modifications de configuration ou confirmez une opération de validation confirmée précédente.

true

commit_empty_changes: boolean

Validez les modifications de configuration même s’il n’y a aucune différence entre la configuration candidate et la configuration validée.

false

commit_force_sync: boolean

Synchronisez et validez la configuration sur tous les moteurs de routage, même s’il existe des sessions de configuration ouvertes ou des modifications de configuration non validées sur l’autre moteur de routage.

false

commit_sync: boolean

Synchronisez et validez la configuration sur tous les moteurs de routage.

false

confirmed: minutes

Exigez qu’une opération de validation soit confirmée dans un laps de temps spécifié après la validation initiale. Si la validation n’est pas confirmée dans le délai spécifié, rétablissez la configuration précédemment validée.

L’option commit: true ou l’option check: true doit être utilisée pour confirmer la validation.

timeout: seconds

Attendez la fin de l’opération en utilisant la valeur spécifiée comme délai d’attente.

30 secondes

Valider le commentaire

Lorsque vous validez la configuration, vous pouvez inclure un bref commentaire décrivant l’objectif des modifications validées. Pour consigner un commentaire décrivant les modifications, incluez l’argument comment: "comment string" avec la chaîne de message.

Vérification de la validation

Par défaut, le module exécute à la config fois une vérification de validation et une opération de validation. L’argument check_commit_wait définit le nombre de secondes à attendre entre la vérification de validation et les opérations de validation. Incluez cet argument lorsque vous devez prévoir suffisamment de temps pour que l’appareil termine l’opération de vérification de validation et libère le verrou de configuration avant de lancer l’opération de validation. Si vous omettez l’argument check_commit_wait , il peut y avoir certaines circonstances dans lesquelles un périphérique lance l’opération de validation avant que l’opération de vérification de validation ne libère son verrou sur la configuration, ce qui entraîne un échec de l’opération de CommitError validation.

Valider les modifications vides

Par défaut, s’il n’y a pas de différence entre la configuration candidate et la configuration validée, le module ne valide pas les modifications. Pour forcer une opération de commit même s’il n’y a pas de différences, incluez l’argument commit_empty_changes: true .

Valider Synchroniser

Si l’appareil dispose de deux moteurs de routage, vous pouvez synchroniser et valider la configuration sur les deux moteurs de routage en incluant l’argument commit_sync: true . Pour forcer la réussite de l’opération commit synchronize même s’il existe des sessions de configuration ouvertes ou des modifications de configuration non validées sur l’autre moteur de routage, utilisez l’argument commit_force_sync: true . Lorsque vous incluez cette commit_force_sync: true option, l’appareil met fin à toutes les sessions de configuration sur l’autre moteur de routage avant de synchroniser et de valider la configuration.

Valider Confirmer

Pour exiger qu’une opération de validation soit confirmée dans un laps de temps spécifié après la validation initiale, incluez l’argument confirmed: minutes . Si la validation n’est pas confirmée dans le délai imparti, la configuration revient automatiquement à la configuration précédemment validée. La plage autorisée est de 1 à 65 535 minutes. L’opération de validation confirmée est utile pour vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas la gestion d’accéder à l’appareil. Si la modification empêche l’accès ou provoque d’autres erreurs, la restauration automatique de la configuration précédente permet d’accéder à l’appareil après la date limite de restauration. Pour confirmer l’opération de validation, appelez le module avec l’argument config check: true or commit: true .

Dans le playbook suivant, la première tâche modifie la configuration, attend 10 secondes entre la vérification de validation et l’opération de validation et exige que l’opération de validation soit confirmée dans les 5 minutes. Il enregistre également un commentaire pour le commit. La deuxième tâche émet une commit check opération pour confirmer la validation. Dans un scénario réel, vous pouvez effectuer des tâches de validation après la validation initiale et n’exécuter la confirmation de validation que si les tâches répondent à certains critères de validation.

Comment ignorer les avertissements lors de la configuration d’appareils

Le juniper.device.config module vous permet de modifier et de valider la configuration sur les équipements Junos. Dans certains cas, la réponse RPC peut contenir <rpc-error> des éléments avec un niveau de gravité d’avertissement ou supérieur qui amènent le module à lever une RpcError exception. Une RpcError exception peut entraîner l’échec de l’opération de chargement ou de validation.

Dans certains cas, il peut être nécessaire ou souhaitable de supprimer les RpcError exceptions levées en réponse aux avertissements concernant les opérations de chargement et de validation. Vous pouvez demander au module de supprimer RpcError les config exceptions levées pour les avertissements en incluant le paramètre dans la ignore_warning liste des arguments du module. L’argument ignore_warning prend un booléen, une chaîne ou une liste de chaînes.

Pour demander au module d’ignorer tous les avertissements concernant les opérations de chargement et de validation effectuées par le module, incluez l’argument ignore_warning: true . L’exemple suivant ignore tous les avertissements relatifs aux opérations de chargement et de validation.

Si vous incluez ignore_warning: true et que tous les <rpc-error> éléments ont un niveau de gravité d’avertissement, l’application ignore tous les avertissements et ne lève pas d’exception RpcError . Toutefois, tous les <rpc-error> éléments présentant des niveaux de gravité plus élevés lèveront toujours des exceptions.

Pour demander au module d’ignorer des avertissements spécifiques, définissez l’argument ignore_warning sur une chaîne ou une liste de chaînes contenant les avertissements à ignorer. L’exemple suivant ignore deux avertissements spécifiques :

Le module supprime les RpcError exceptions si tous les <rpc-error> éléments ont un niveau de gravité d’avertissement et que chaque avertissement de la réponse correspond à une ou plusieurs des chaînes spécifiées.

Exemple : Utiliser Ansible pour configurer des équipements Junos

Le juniper.device.config module vous permet de gérer la configuration sur les équipements Junos. Cet exemple utilise le config module pour apporter des modifications de configuration sur un équipement Junos via NETCONF via SSH.

Exigences

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

  • Serveur de gestion de la configuration exécutant Ansible 2.17 ou version ultérieure avec la juniper.device collection installée

  • Équipement Junos sur lequel NETCONF est activé et compte d’utilisateur configuré avec les autorisations appropriées

  • Paire de clés publique/privée SSH configurée pour l’utilisateur approprié sur le contrôleur Ansible et l’équipement Junos

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

Aperçu

Cet exemple présente un playbook Ansible qui utilise le juniper.device.config module pour activer un nouveau script op dans la configuration des équipements Junos cibles. Le fichier de données de configuration, junos-config.conf, contient les données de configuration correspondantes au format texte.

Le playbook inclut la Check NETCONF connectivity tâche, qui utilise le ansible.builtin.wait_for module Ansible pour tenter d’établir une session NETCONF avec l’équipement cible à l’aide du port NETCONF par défaut (830). Si le nœud de contrôle ne parvient pas à établir une session NETCONF avec un équipement cible pendant l’exécution du playbook, il ignore les tâches restantes dans le jeu pour ce périphérique.

Le playbook utilise le juniper.device.file_copy module pour copier le nouveau script op du nœud de contrôle Ansible vers l’équipement Junos. Les arguments du module spécifient le répertoire et le nom de fichier du script sur le périphérique local et le répertoire de destination sur le périphérique distant.

La tâche de configuration de l’appareil exécute le juniper.device.config module à condition que la vérification NETCONF ait réussi. L’argument load: "merge" charge les nouvelles données de configuration dans la configuration candidate à l’aide d’une load merge opération. Par défaut, le module valide les config données de configuration sur un équipement pour load et rollback opérations. Les arguments du module incluent l’argument comment , qui enregistre un commentaire de validation dans le fichier journal système et l’historique de validation de l’appareil.

Configuration

Créer le fichier de données de configuration

Procédure étape par étape

Pour créer le fichier de données de configuration utilisé par le module :

  1. Créez un nouveau fichier avec l’extension appropriée en fonction du format des données de configuration, qui dans cet exemple est du texte.

  2. Incluez les modifications de configuration souhaitées dans le fichier.

Créer le playbook Ansible

Procédure étape par étape

Pour créer un playbook qui utilise le config module pour apporter des modifications de configuration sur un équipement Junos :

  1. Incluez le playbook boilerplate, qui exécute les modules localement.

  2. (Facultatif) Créez une tâche pour vérifier la connectivité NETCONF.

  3. Créez une tâche pour copier le nouveau script op sur l’appareil.

  4. Créez la tâche pour charger la configuration sur l’appareil et validez-la.

  5. (Facultatif) Créez une tâche pour imprimer la réponse, qui inclut les modifications de configuration au format diff .

Résultats

Sur le nœud de contrôle Ansible, passez en revue le playbook terminé. Si le playbook n’affiche pas le code voulu, répétez les instructions de cet exemple pour corriger le playbook.

Exécuter le playbook

Pour exécuter le playbook :

  • Émettez la ansible-playbook commande sur le nœud de contrôle et indiquez le chemin d’accès au playbook ainsi que les options souhaitées.

Vérification

Vérification de la configuration

But

Vérifiez que la configuration a été correctement mise à jour sur l’équipement Junos.

Action

Consultez la sortie du playbook Ansible pour voir si la tâche de configuration a réussi ou échoué. Vous pouvez également vous connecter au périphérique Junos et afficher la configuration, l’historique des validations et les fichiers journaux pour vérifier la configuration et la validation, par exemple :

Résoudre les erreurs dans le playbook

Résoudre les erreurs de délai d’expiration

Problème

Le playbook génère un TimeoutExpiredError message d’erreur et ne parvient pas à mettre à jour la configuration de l’appareil.

Par défaut, le délai d’expiration d’un RPC NETCONF est de 30 secondes. Les modifications de configuration importantes peuvent dépasser cette valeur, ce qui entraîne l’expiration de l’opération avant que la configuration puisse être téléchargée et validée.

Solution

Pour prendre en charge les modifications de configuration qui peuvent nécessiter un temps de validation plus long que l’intervalle de délai d’expiration RPC par défaut, définissez l’argument du timeout module sur une valeur appropriée et réexécutez le playbook.

Résoudre les erreurs de verrouillage de configuration

Problème

Le playbook génère un LockError message d’erreur indiquant que la configuration ne peut pas être verrouillée. Par exemple:

ou

Une erreur de verrouillage de configuration peut se produire pour les raisons suivantes :

  • Un autre utilisateur dispose d’un verrou exclusif sur la configuration.

  • Un autre utilisateur a apporté des modifications à la base de données de configuration, mais ne les a pas encore validées.

  • L’utilisateur qui exécute le module Ansible n’est pas autorisé à configurer l’appareil.

Solution

La LockError chaîne de message indique généralement la cause racine du problème. Si un autre utilisateur dispose d’un verrou exclusif sur la configuration ou l’a modifiée, attendez que le verrou soit libéré ou que les modifications soient validées, puis exécutez à nouveau le playbook. Si la cause du problème est que l’utilisateur ne dispose pas des autorisations nécessaires pour configurer le périphérique, exécutez le playbook avec un utilisateur disposant des autorisations nécessaires ou, le cas échéant, configurez le périphérique Junos pour donner à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.

Résoudre les erreurs de changement de configuration

Problème

Le playbook génère un ConfigLoadError message d’erreur indiquant que la configuration ne peut pas être modifiée, car l’autorisation est refusée.

Ce message d’erreur est généré lorsque l’utilisateur exécutant le module Ansible est autorisé à modifier la configuration, mais n’a pas l’autorisation de modifier la section demandée de la configuration.

Solution

Exécutez le playbook avec un utilisateur disposant des autorisations nécessaires ou, le cas échéant, configurez le périphérique Junos de manière à ce qu’il accorde à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.