Utilisation du juniper.device.config module Ansible pour gérer la configuration de Junos OS

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

• Annuler la configuration

• Charger la configuration de sauvetage

Le processus de base pour apporter des modifications de configuration consiste à verrouiller la configuration, à charger les modifications de configuration, à valider la configuration pour la rendre active, puis à déverrouiller la configuration. 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. Pour modifier la configuration, la liste d’arguments du module doit inclure l’un des paramètres suivants :

• load: charge de nouvelles données de configuration.

• rollback: revenez à la configuration de sauvetage ou à une configuration validée précédemment.

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, qui verrouille et déverrouille automatiquement la configuration globale candidate. Vous pouvez également spécifier un mode de configuration différent. 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, consultez la rubrique Spécification du 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.

• Opération de chargement : l’opération de chargement détermine la façon dont les données de configuration sont chargées dans la base de données de configuration sélectionnée. Vous pouvez choisir parmi les mêmes opérations de chargement que celles disponibles dans la CLI de Junos OS. Pour plus d’informations, voir Comment spécifier l’action de chargement.

• Format : vous pouvez configurer les équipements Junos à l’aide de l’un des formats standard pris en charge. Vous pouvez fournir des données de configuration ou des modèles Jinja2 sous forme de texte, d’éléments XML Junos, de commandes Junos OS set ou de JSON. Pour plus d’informations sur la spécification du format des données de configuration, voir Spécification du format des données de configuration à charger.

• Source de données de configuration : vous pouvez charger des données de configuration à partir d’une liste de chaînes, d’un fichier sur le nœud de contrôle Ansible local, d’un modèle Jinja2 ou d’une URL accessible depuis l’appareil client. Pour plus d’informations sur la spécification de la source des données de configuration, consultez les sections suivantes :

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

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

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

Le juniper.device.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 :

• Comment charger la configuration de sauvetage

• Comment restaurer la configuration

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

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

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 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 exclusif de configuration verrouille la configuration globale candidate (également appelée base de données de configuration partagée) aussi longtemps que le module doit apporter les modifications de configuration demandées. Le verrouillage de la base de données empêche les autres utilisateurs de modifier ou de valider les modifications de la base de données en même temps.

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: "private"
• Configurer la base de données éphémère

Le juniper.device.config module prend en charge les modifications de configuration de chargement en utilisant la plupart des opérations de chargement prises en charge dans la CLI de Junos OS. Vous spécifiez l’opération de chargement en définissant l’argument du load module sur la valeur de l’opération de chargement correspondante. Le Tableau 2 résume les valeurs des arguments pour les différentes opérations de chargement.

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

Opération de chargement	load Argumentation	Descriptif
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. Tous les processus système analysent la configuration.
load patch	load: patch	Chargez les données de configuration à partir d’un fichier de correctifs.
load replace	load: replace	Fusionnez la configuration chargée avec la configuration existante, mais remplacez les instructions de la configuration existante par des instructions de la configuration chargée qui spécifient la replace: balise. Si l’instruction ne se trouve pas 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, deleteet deactivate.
load update	load: update	Chargez une configuration complète et comparez-la à la configuration existante. Remplacez uniquement les parties de la configuration candidate qui ont changé. Pendant l’opération de validation, seuls les processus système affectés analysent la nouvelle configuration.

Le juniper.device.config module vous permet de configurer des é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 incluent le texte, les éléments XML Junos, les commandes Junos OS set et JSON.

Le juniper.device.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. Ajoutez l’extension appropriée au fichier ou incluez l’argument format .

Le Tableau 3 résume 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 la CLI (texte)	.conf	text
JavaScript Object Notation (JSON)	.json	json
set Commandes de Junos OS	.set	set
Éléments XML de Junos	.xml	xml

Remarque :

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 .

Le juniper.device.config module vous permet de charger des données de configuration à partir d’une liste de chaînes. Pour charger les 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 lines format des données de configuration. Toutefois, vous pouvez spécifier explicitement le format en incluant l’argument format . Pour plus d’informations sur la spécification du format, voir 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 op. Dans ce cas, l’argument load a de la valeur 'set' , car les données de configuration dans lines utilisent le format d’instruction Junos OS set .

Le playbook suivant configure les mêmes instructions à l’aide de lines données de configuration au format texte. Dans ce cas, l’exemple utilise load: "merge".

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 FTP ou HTTP accessible depuis 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 incluent 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.

Pour spécifier le format, incluez le paramètre du module ou ajoutez l’extension format 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 de fichier. Pour plus d’informations sur la spécification du format, voir Comment spécifier le format des données de configuration à charger. Lorsque les données de configuration utilisent le format XML Junos, vous devez les inclure dans la balise de niveau <configuration> supérieur.

Remarque :

Vous n’avez pas besoin de joindre les données de configuration au format texte, commandes Junos OS set ou JSON dans <configuration-text>, <configuration-set>ou <configuration-json> les balises requises lors de la configuration de l’équipement 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	Descriptif
src	Chemin absolu ou relatif vers un fichier sur le nœud de contrôle Ansible. Le répertoire par défaut est le répertoire du playbook.
url	Chemin d’accès absolu ou relatif à un fichier sur l’équipement client. Le répertoire par défaut sur l’appareil client est le répertoire de travail actuel, qui est par défaut le répertoire personnel de l’utilisateur. FTP URL HTTP URL

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 le périphérique Junos ou d’une URL FTP ou HTTP, utilisez le url paramètre. Spécifiez le chemin ou l’URL du fichier à charger. Par exemple :

La valeur de url peut être un chemin d’accès absolu ou relatif à un fichier local, 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.

  • R :filename ou un fichier :path/filename—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 a la forme suivante :

• Le chemin d’accès à un fichier sur un serveur HTTP a 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 avec les caractères %2F ; par exemple, ftp://username :password@hostname/ %2Fpath/filename.

Le juniper.device.config module vous permet de restituer les données de configuration à partir d’un fichier modèle Jinja2 sur le nœud de contrôle Ansible, puis de charger et de 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 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, qui inclut du texte ASCII, des éléments XML Junos, des commandes Junos OS set et JSON. Le module Ansible utilise le modèle Jinja2 et un dictionnaire de variables fourni pour afficher 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 dans vars la liste des arguments du module.

• template—Chemin du fichier de modèle Jinja2

• vars—Dictionnaire des clés et des valeurs requises pour afficher le 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, voir 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 pour charger le modèle Jinja2, définissez l’argument template sur le chemin du fichier modèle. Définissez les variables requises par le modèle dans le vars dictionnaire.

Le playbook suivant utilise le modèle Jinja2 et le vars dictionnaire pour afficher les données de configuration. Le format paramètre indique le format des données de configuration dans le fichier modèle. Le playbook charge et valide la configuration sur l’hôte cible.

Le module génère les données de configuration suivantes. Le module charge les données dans la configuration candidate sur l’appareil et la valide.

Une configuration de secours vous permet de définir une configuration de travail connue ou une configuration avec un état connu que vous pouvez restaurer à tout moment. Vous utilisez 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 endommagés de manière irréparable. Lorsque vous créez une configuration de secours, l’appareil enregistre la configuration validée la plus récente 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 appareil, incluez l’argument du rollback: rescue module. Par exemple :

Les équipements Junos stockent une copie de la configuration validée la plus récente et jusqu’à 49 configurations précédentes, selon la plate-forme. Vous pouvez revenir à n’importe quelle configuration stockée. Cette fonctionnalité 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. Toutefois, au lieu de charger les données de configuration, vous effectuez une restauration, qui remplace l’ensemble 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 module et spécifiez l’ID rollback de la configuration de restauration. Les valeurs d’ID valides sont comprises entre 0 (zéro, pour la dernière configuration validée) soit une de moins que le nombre de configurations précédentes stockées (49 au maximum).

Le playbook suivant demande d’abord l’ID de restauration de la configuration à restaurer. La première tâche restaure la configuration à la version demandée et la valide. La deuxième tâche imprime les différences de configuration en sortie standard.

Par défaut, lorsque vous utilisez le juniper.device.config module pour modifier la configuration, 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 avec un grand nombre des options disponibles dans la CLI 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	Descriptif	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 la 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 la configuration même si la configuration candidate n’a pas été modifiée.	false
commit_force_sync: boolean	Synchronisez et validez la configuration sur tous les moteurs de routage, même si l’autre moteur de routage a des sessions de configuration ouvertes ou des modifications de configuration non validées.	false
commit_sync: boolean	Synchroniser et valider la configuration sur tous les moteurs de routage.	false
confirmed: minutes	Exiger qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale. Si vous ne confirmez pas la validation dans le délai spécifié, rétablissez la configuration précédemment validée. Confirmez la validation à l’aide de l’option commit: true ou de l’option check: true .	–
timeout: seconds	Attendez la fin de l’opération en utilisant la valeur spécifiée comme délai d’expiration.	30 secondes

Commit Commentaire

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

Vérification de la validation

Par défaut, le module exécute à la fois une vérification de validation juniper.device.config 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 laisser suffisamment de temps à l’appareil pour terminer l’opération de vérification de validation et libérer le verrou de configuration avant de lancer l’opération de validation. Si le 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, l’opération de validation échoue et le module émet un CommitError.

Valider les modifications vides

Par défaut, si la configuration candidate et la configuration validée ne présentent aucune différence, le module ne valide pas les modifications. Pour forcer une opération de validation même en l’absence de différences, incluez l’argument commit_empty_changes: true .

Validation, synchronisation

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 si l’autre moteur de routage a des sessions de configuration ouvertes ou des modifications de configuration non validées, utilisez l’argument commit_force_sync: true . Lorsque vous incluez l’option commit_force_sync: true , 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 délai spécifié après la validation initiale, incluez l’argument confirmed: minutes . Si vous ne confirmez pas la validation 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 l’accès de gestion à 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 une fois la date limite de restauration écoulée. Pour confirmer l’opération de validation, appelez le module avec l’argument juniper.device.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 nécessite 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.

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 entraînent le déclenchement d’une RpcError exception par le module. 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 qui sont levées en réponse aux avertissements pour les opérations de chargement et de validation. Vous pouvez demander juniper.device.config au module de supprimer RpcError les exceptions déclenchées pour les avertissements en incluant le paramètre dans la ignore_warning liste d’arguments du module. L’argument ignore_warning prend un booléen, une chaîne ou une liste de chaînes.

Pour indiquer au module d’ignorer tous les avertissements pour 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 pour les 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 . Cependant, tout <rpc-error> élément avec des niveaux de gravité plus élevés soulèvera toujours des exceptions.

Pour indiquer 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.