SUR CETTE PAGE
Comment spécifier le format des données de configuration à charger
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
Comment ignorer les avertissements lors de la configuration d’appareils
Exemple : utiliser Ansible pour configurer des équipements Junos
Utiliser Ansible pour configurer des périphériques Junos
RÉSUMÉ Utilisez les modules Ansible de Juniper Networks pour gérer la configuration sur les équipements Junos.
Juniper Networks fournit des modules Ansible qui vous permettent de configurer des équipements Junos. Le tableau 1 présente les modules disponibles. Le compte d’utilisateur utilisé pour modifier la configuration doit disposer des autorisations nécessaires pour modifier les parties pertinentes de la configuration sur chaque appareil.
Ensemble de contenu |
Nom du module |
---|---|
|
|
|
À partir de la Juniper.junos
version 2.0.0, le juniper_junos_config
module combine et remplace les fonctionnalités des junos_commit
modules , junos_get_config
et junos_install_config
junos_rollback
.
Les sections suivantes expliquent comment utiliser les modules pour modifier et valider la configuration sur les équipements Junos.
Présentation du module
Les config
modules et juniper_junos_config
vous permettent 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 de nouvelles données de configuration, soit le load
paramètre pour revenir à la configuration de rollback
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 la rendre active, puis à déverrouiller la configuration.
Par défaut, les config
modules et apportent des modifications à la base de données de configuration candidate à l’aide du configure exclusive
mode qui verrouille et juniper_junos_config
déverrouille automatiquement la configuration globale candidate. Vous pouvez également apporter des modifications à une copie privée de la configuration candidate. Pour plus d’informations sur la spécification du mode de configuration, consultez Comment spécifier le mode de configuration.
Lors du chargement de nouvelles données de configuration, outre 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 manière dont les données de configuration sont chargées dans la configuration candidate. Les fonctions prennent en charge bon nombre des mêmes opérations de chargement que celles disponibles dans l’interface de ligne de commande Junos OS. Pour plus d’informations, consultez 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 JSON. Pour plus d’informations sur la spécification du format des données de configuration, consultez Comment spécifier le format des données de configuration à charger. -
Source de données de configuration : vous pouvez charger les 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 en incluant respectivement le
lines
paramètre ,src
,template
ouurl
. Pour plus d’informations sur la spécification de la source des données de configuration, consultez les sections suivantes :
Les config
modules et vous permettent également de charger et juniper_junos_config
de valider la configuration de secours ou de restaurer 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 module rollback
. 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, les modules et juniper_junos_config
valident les config
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 module ou inclut les arguments ou pour modifier la configuration, le config
module renvoie automatiquement les load
modifications de configuration au format diff ou juniper_junos_config
rollback
patch dans la réponse du module. Les différences sont renvoyées dans les diff
variables etdiff_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 base de données de configuration candidate. Par défaut, les config
modules et juniper_junos_config
apportent 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 pour apporter les modifications demandées à la configuration. Le verrouillage de la base de données empêche les autres utilisateurs de modifier ou de valider les modifications apportées à la base de données tant que le verrou n’est pas levé.
Pour spécifier le mode, incluez le config_mode
paramètre dans la liste d’arguments du module. Les modes pris en charge incluent exclusive
et private
. Les deux modes ignorent toutes les modifications non validées à la sortie.
Le playbook suivant utilise configure private
le mode pour modifier la configuration :
--- - name: "Configure Device" hosts: dc1 connection: local gather_facts: no tasks: - name: "Configure op script" juniper.device.config: config_mode: "private" load: "set" lines: - "set system scripts op file bgp.slax" register: response - name: "Print the config changes" debug: var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configure-script.yaml PLAY [Configure Device] ******************************************************* TASK [Configure op script] **************************************************** changed: [dc1a.example.net] TASK [Print the config changes] *********************************************** ok: [dc1a.example.net] => { "response.diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ] } PLAY RECAP ******************************************************************** dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Procédure de spécification de l’action de chargement
Les config
modules et juniper_junos_config
prennent en charge le chargement des modifications de configuration en utilisant bon nombre des mêmes opérations de chargement que celles prises en charge dans l’interface de ligne de commande Junos OS. Vous spécifiez l’opération de chargement en incluant le load
paramètre dans la liste d’arguments du module et en le définissant sur la valeur de l’opération de chargement correspondante. Le tableau 2 récapitule les paramètres requis pour chaque type d’opération de charge.
Opération de chargement |
load Argument |
Description |
---|---|---|
|
|
Fusionnez la configuration chargée avec la configuration existante. |
|
|
Remplacez l’ensemble de la configuration par la configuration chargée. |
|
|
Fusionnez la configuration chargée avec la configuration existante, mais remplacez les instructions de la configuration existante par celles qui spécifient la balise dans la |
|
|
Chargez les données de configuration à partir d’un fichier correctif. |
|
|
Chargez les données de configuration formatées |
|
|
Comparez la configuration chargée complète à la configuration existante. Chaque élément de configuration différent dans la configuration chargée remplace l’élément correspondant dans la configuration existante. Pendant 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
Les config
modules et juniper_junos_config
vous permettent 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 pour les données incluent du texte, des éléments XML Junos, des commandes Junos OS set
et JSON.
À partir de Junos OS version 16.1R1, les équipements Junos prennent en charge le chargement des données de configuration au format JSON.
Les config
modules et juniper_junos_config
tentent de détecter automatiquement le format des données de configuration fournies sous forme de chaînes à l’aide de 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 en ajoutant l’extension appropriée au fichier ou 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.
Format des données de configuration |
Extension De Fichier |
paramètre de format |
---|---|---|
Instructions de configuration CLI (texte) |
.Conf |
« |
Notation d’objet JavaScript (JSON) |
.Json |
« |
Commandes Junos OS |
.Ensemble |
« |
Éléments XML Junos |
.Xml |
« |
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
Les config
modules et juniper_junos_config
vous permettent 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.
Les modules tentent 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, consultez Comment spécifier le format des données de configuration à charger. Si vous incluez le paramètre dans la liste d’arguments du module, il remplace le format
format de détection automatique.
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
.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration data using strings and commit" juniper.device.config: load: "set" lines: - "set system scripts op file bgp.slax" - "set system scripts op file bgp-neighbor.slax" register: response - name: "Print the response" debug: var: response
Le playbook suivant configure les mêmes instructions à l’aide de lines
données de configuration au format texte. Dans ce cas, load: "merge"
est utilisé.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration data using strings and commit" juniper.device.config: load: "merge" lines: - | system { scripts { op { file bgp.slax; file bgp-neighbor.slax; } } } register: response - name: "Print the response" debug: var: response
Comment charger des données de configuration à partir d’un fichier local ou distant
Les config
modules et juniper_junos_config
vous permettent 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 depuis l’appareil client
Lorsque vous chargez des données de configuration à partir d’un fichier, vous devez indiquer le format des données de configuration dans le fichier et l’emplacement du 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.
Vous pouvez spécifier le format des données de configuration en incluant explicitement le format
paramètre dans la liste d’arguments du module ou en ajoutant l’extension appropriée au fichier de données de configuration. Si vous spécifiez le paramètre, il remplace le format
format indiqué par l’extension de fichier. Pour plus d’informations sur la spécification du format, consultez 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 placer dans la balise de niveau <configuration>
supérieur.
Vous n’avez pas besoin d’inclure des données de configuration au format texte ASCII, commandes Junos OS set
ou JSON dans , ou <configuration-json>
balises, <configuration-set>
comme requis lors de la configuration du périphérique directement dans <configuration-text>
une session NETCONF.
Le tableau 4 présente les paramètres de module que vous pouvez inclure pour spécifier l’emplacement du fichier.
Paramètre de module |
Description |
---|---|
|
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. |
|
Chemin absolu ou relatif d’accès à un fichier sur l’appareil client, à un emplacement FTP ou à une URL HTTP (Hypertext Transfer Protocol). 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 de base 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 d’accès absolu ou relatif du fichier contenant les données de configuration. Par exemple :
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration from a local file and commit" juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos.conf" register: response - name: "Print the response" debug: var: response
Pour charger des données de configuration à partir d’un fichier sur le périphérique Junos géré 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 :
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration from a remote file and commit" juniper.device.config: load: "merge" url: "/var/tmp/junos.conf" register: response - name: "Print the response" debug: var: response
La valeur de peut url
être un chemin d’accès de fichier local absolu ou relatif, un emplacement FTP ou une URL HTTP (Hypertext Transfer Protocol).
-
Un nom de fichier local peut avoir 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).
-
-
Un nom de fichier pour un fichier sur un serveur FTP a la forme suivante :
ftp://username:password@hostname/path/filename
-
Le nom d’un fichier sur un serveur HTTP se présente sous la forme suivante :
http://username:password@hostname/path/filename
Dans chaque cas, la valeur par défaut de la path variable est le répertoire de base 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.
Comment charger des données de configuration à l’aide d’un modèle Jinja2
Les config
modules et vous permettent de restituer les données de configuration d’un fichier de modèle Jinja2 sur le nœud de contrôle Ansible, puis de charger et juniper_junos_config
valider la configuration sur un équipement Junos. Jinja est un moteur de template 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. Les modules Ansible utilisent le modèle Jinja2 et un dictionnaire de variables fourni pour restituer les données de configuration.
Pour charger et valider des données de configuration à l’aide d’un modèle Jinja2, incluez les template
paramètres et vars
dans la liste d’arguments du module.
-
template
—Chemin du fichier de modèle Jinja2 -
vars
—Dictionnaire des clés et des valeurs requises pour rendre le modèle Jinja2
Vous devez également inclure le paramètre lorsque l’extension de fichier des modèles n’indique pas le format
format des données. Pour plus d’informations sur la spécification du format, consultez Comment spécifier le format des données de configuration à charger.
Par exemple, le fichier interfaces-mpls.j2 contient le modèle Jinja2 suivant :
interfaces { {% for item in interfaces %} {{ item }} { description "{{ description }}"; unit 0 { family {{ family }}; } } {% endfor %} } protocols { mpls { {% for item in interfaces %} interface {{ item }}; {% endfor %} } rsvp { {% for item in interfaces %} interface {{ item }}; {% endfor %} } }
Pour utiliser le module ou juniper_junos_config
pour charger le modèle Jinja2, définissez l’argument template
sur le chemin d’accès du fichier de modèle et définissez les variables requises par le modèle dans le config
vars
dictionnaire. Le playbook suivant utilise le modèle Jinja2 et les variables définies dans vars
pour restituer les données de configuration et 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.
--- - name: "Load and commit configuration" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load a configuration from a Jinja2 template and commit" juniper.device.config: load: "merge" template: "build_conf/templates/interfaces-mpls.j2" format: "text" vars: interfaces: ["ge-1/0/1", "ge-1/0/2", "ge-1/0/3"] description: "MPLS interface" family: "mpls" register: response - name: "Print the response" debug: var: response
Le module génère les données de configuration suivantes, qui sont chargées dans la configuration candidate sur l’appareil et validées :
interfaces { ge-1/0/1 { description "MPLS interface"; unit 0 { family mpls; } } ge-1/0/2 { description "MPLS interface"; unit 0 { family mpls; } } ge-1/0/3 { description "MPLS interface"; unit 0 { family mpls; } } } protocols { mpls { interface ge-1/0/1; interface ge-1/0/2; interface ge-1/0/3; } rsvp { interface ge-1/0/1; interface ge-1/0/2; interface ge-1/0/3; } }
Comment charger la configuration de sauvetage
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 dernière configuration validée en tant que configuration de secours.
Les config
modules et juniper_junos_config
vous permettent de revenir à une configuration de sauvetage existante sur les équipements Junos. Pour charger et valider la configuration de secours sur un appareil, incluez l’argument du rollback: "rescue"
module. Par exemple :
--- - name: "Revert to rescue configuration" hosts: dc1a connection: local gather_facts: no tasks: - name: "Load and commit rescue configuration" juniper.device.config: rollback: "rescue" register: response - name: "Print response" debug: var: response
Comment restaurer la configuration
Les appareils Junos stockent une copie de la dernière configuration validée et jusqu’à 49 configurations précédentes, selon la plate-forme. Vous pouvez revenir à n’importe quelle configuration stockée. Ceci est utile lorsque les 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’ensemble de la configuration candidate par une configuration précédemment validée.
Les config
modules et juniper_junos_config
vous permettent 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 comprises entre 0 (zéro pour la dernière configuration validée) et une de moins que le nombre de configurations précédentes stockées (49 au maximum).
Le playbook suivant vous invite à indiquer l’ID de restauration de la configuration à restaurer, annule la configuration et la valide, puis imprime les modifications de configuration à la sortie standard.
--- - name: "Roll back the configuration" hosts: dc1a connection: local gather_facts: no vars_prompt: - name: "ROLLBACK" prompt: "Rollback ID of the configuration to restore" private: no tasks: - name: "Roll back the configuration and commit" juniper.device.config: rollback: "{{ ROLLBACK }}" register: response - name: "Print the configuration changes" debug: var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configuration-rollback.yaml Rollback ID of the configuration to restore: 1 PLAY [Roll back the configuration] ******************************************** TASK [Roll back the configuration and commit] ********************************* changed: [dc1a.example.net] TASK [Print the configuration changes] *************************************** ok: [dc1a.example.net] => { "response.diff_lines": [ "", "[edit interfaces]", "- ge-0/0/0 {", "- unit 0 {", "- family mpls;", "- }", "- }" ] } PLAY RECAP ******************************************************************** dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Comment valider la configuration
Par défaut, lorsque vous utilisez le module ou pour modifier la configuration à l’aide de l’argument load
ou juniper_junos_config
rollback
, le config
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 bon nombre des options disponibles dans l’interface de ligne de commande Junos OS. Le tableau 5 présente les arguments de module que vous pouvez utiliser pour spécifier différentes options de validation.
Module Argument |
Description |
Valeur par défaut pour |
---|---|---|
|
Effectuez une vérification de validation ou confirmez une opération de validation confirmée précédente. |
|
|
Attendez le nombre de secondes spécifié entre la vérification de validation et l’opération de validation. |
– |
|
Consignez un commentaire pour cette opération de validation dans le fichier journal système et dans l’historique des validations de l’appareil. |
– |
|
Validez les modifications de configuration ou confirmez une opération de validation confirmée précédente. |
|
|
Validez les modifications de configuration même s’il n’y a aucune différence entre la configuration candidate et la configuration validée. |
|
|
Exigez qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale. Sinon, revenez à la configuration précédemment validée. L’option |
– |
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 de message.
Par défaut, les modules et exécutent à la config
fois une vérification de validation et juniper_junos_config
une opération de validation. L’argument check_commit_wait
définit le nombre de secondes à attendre entre les opérations de vérification de validation et 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 vous omettez cet argument, il peut arriver qu’un périphérique lance l’opération de validation avant que l’opération de vérification de validation ne relâche son verrou sur la configuration, ce qui entraîne l’échec de l’opération CommitError
de validation.
Par défaut, s’il n’y a pas de différences entre la configuration candidate et la configuration validée, 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
.
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’argumentconfirmed: 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 l’accès de gestion à l’équipement. 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 l’expiration du délai de restauration. Pour confirmer l’opération de validation, appelez le config
module ou avec l’argument check: true
ou juniper_junos_config
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 requiert 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 le commit. 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.
--- - name: "Load configuration and confirm within 5 minutes" hosts: dc1 connection: local gather_facts: no tasks: - name: "Load configuration. Wait 10 seconds between check and commit. Confirm within 5 min." juniper.device.config: load: "merge" format: "text" src: "build_conf/{{ inventory_hostname }}/junos.conf" check_commit_wait: 10 confirmed: 5 comment: "updated using Ansible" register: response - name: "Print the response" debug: var: response - name: "Confirm the commit with a commit check" juniper.device.config: check: true diff: false commit: false register: response - name: "Print the response" debug: var: response
Comment ignorer les avertissements lors de la configuration d’appareils
Les config
modules et vous permettent de modifier et juniper_junos_config
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 provoquent le déclenchement d’une RpcError
exception par le module, provoquant ainsi l’échec de l’opération de chargement ou de validation.
Dans certains cas, il peut être nécessaire ou souhaitable de supprimer les exceptions déclenchées en réponse aux avertissements concernant les RpcError
opérations de chargement et de validation. Vous pouvez demander config
aux modules et juniper_junos_config
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 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 pour les opérations de chargement et de validation.
--- - name: Configure Device hosts: dc1 connection: local gather_facts: no tasks: - name: Configure op script juniper.device.config: config_mode: "private" load: "set" lines: - "set system scripts op file bgp.slax" ignore_warning: true register: response - name: Print the response debug: var: response
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 déclenche RpcError
pas d’exception. Toutefois, tous les <rpc-error>
éléments présentant des niveaux de gravité plus élevés soulè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 :
--- - name: Configure Device hosts: dc1 connection: local gather_facts: no tasks: - name: Configure Junos device and ignore warnings juniper.device.config: config_mode: "private" load: "merge" src: "build_conf/{{ inventory_hostname }}/junos.conf" ignore_warning: - "Advertisement-interval is less than four times" - "Chassis configuration for network services has been changed." register: response - name: Print the response debug: var: response
Le module supprime RpcError
les 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 config
module vous permet de gérer la configuration sur les équipements Junos. Cet exemple utilise le module pour modifier la configuration d’un config
périphérique Junos via NETCONF over SSH.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Serveur de gestion de la configuration exécutant Ansible 2.10 ou version ultérieure avec la
juniper.device
collection installéeAppareil Junos avec NETCONF activé et compte 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 le périphérique 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 config
module pour activer un nouveau script opérationnel dans la configuration des équipements Junos cibles. Le fichier de données de configuration, junos-config.conf, contient les données de configuration pertinentes au format texte.
Le playbook inclut la Checking NETCONF connectivity
tâche, qui utilise le module Ansible pour essayer d’établir une session NETCONF avec l’équipement cible en utilisant le wait_for
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 du jeu pour ce périphérique.
La tâche de configuration du périphérique exécute le config
module à condition que la vérification NETCONF ait réussi. L’argument load: "merge"
module charge les nouvelles données de configuration dans la configuration candidate à l’aide d’une load merge
opération. Par défaut, le config
module valide les données de configuration sur un appareil pour load
et rollback
les opérations. Les arguments de module incluent l’argument, qui enregistre un commentaire de commit dans le fichier journal système et l’historique comment
des validations du périphérique.
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 :
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.
Incluez les modifications de configuration souhaitées dans le fichier.
user@ansible-cn:~/ansible$ cat build_conf/dc1a.example.net/junos-config.conf system { scripts { op { file bgp.slax; } } }
Créer le playbook Ansible
Procédure étape par étape
Pour créer un playbook qui utilise le module pour modifier la configuration d’un config
périphérique Junos :
Incluez le playbook boilerplate, qui exécute les modules localement.
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no
(Facultatif) Créez une tâche pour vérifier la connectivité NETCONF.
tasks: - name: Checking NETCONF connectivity wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5
Créez la tâche pour charger la configuration sur l’appareil et validez-la.
- name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response
(Facultatif) Créez une tâche pour imprimer la réponse, qui inclut les modifications de configuration au format diff .
- name: Print the response debug: var: response
Résultats
Sur le nœud de contrôle Ansible, consultez le playbook terminé. Si le playbook n’affiche pas le code voulu, répétez les instructions de cet exemple pour corriger le playbook.
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no tasks: - name: Checking NETCONF connectivity wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5 - name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response - name: Print the response debug: var: response
Exécuter le playbook
Pour exécuter le playbook :
-
Exécutez la
ansible-playbook
commande sur le nœud de contrôle et indiquez le chemin du playbook et toutes les options souhaitées.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-config.yaml PLAY [Load and commit configuration data on a Junos device] **** TASK [Checking NETCONF connectivity] ************************************** ok: [dc1a.example.net] TASK [Merge configuration data from a file and commit] ******************** changed: [dc1a.example.net] TASK [Print the response] ************************************************* ok: [dc1a.example.net] => { "response": { "changed": true, "diff": { "prepared": "\n[edit system scripts op]\n+ file bgp.slax;\n" }, "diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ], "failed": false, "file": "build_conf/dc1a.example.net/junos-config.conf", "msg": "Configuration has been: opened, loaded, checked, diffed, committed, closed." } } PLAY RECAP **************************************************************** dc1a.example.net : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Vérification
Vérifier 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 à l’équipement Junos et afficher la configuration, l’historique des validations et les fichiers journaux pour vérifier la configuration et valider, par exemple :
user@dc1a> show configuration system scripts op { file bgp.slax; }
user@dc1a> show system commit 0 2020-12-17 15:33:50 PST by user via netconf Configuring op script with Ansible
user@dc1a> show log messages Dec 17 15:33:39 dc1a mgd[33444]: UI_COMMIT: User 'user' requested 'commit' operation (comment: Configuring op script with Ansible) Dec 17 15:33:57 dc1a mgd[33444]: UI_COMMIT_COMPLETED: commit complete
Résoudre les erreurs du playbook
- Résoudre les erreurs de délai d’attente
- Résoudre les erreurs de verrouillage de configuration
- Résoudre les erreurs de modification de configuration
Résoudre les erreurs de délai d’attente
Problème
Le playbook génère un TimeoutExpiredError
message d’erreur et ne parvient pas à mettre à jour la configuration de l’appareil.
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
La durée par défaut d’expiration d’un RPC NETCONF est de 30 secondes. Les modifications importantes de la configuration peuvent dépasser cette valeur, ce qui entraîne l’expiration du délai d’expiration de l’opération avant que la configuration puisse être téléchargée et validée.
Solution
Pour tenir compte des modifications de configuration qui peuvent nécessiter un temps de validation supérieur au 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 :
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: None, message: configuration database modified)"}
Ou
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: lock-configuration, message: permission denied)"}
Une erreur de verrouillage de configuration peut se produire pour les raisons suivantes :
Un autre utilisateur a 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 le périphérique.
Solution
La LockError
chaîne de message indique généralement la cause racine du problème. Si un autre utilisateur a un verrou exclusif sur la configuration ou a modifié la configuration, attendez que le verrou soit levé ou que les modifications soient validées, puis exécutez à nouveau le playbook. Si le problème est que l’utilisateur n’est pas autorisé à 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 qu’il accorde à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.
Résoudre les erreurs de modification 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.
FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: scripts, message: error: permission denied)"}
Ce message d’erreur est généré lorsque l’utilisateur exécutant le module Ansible a l’autorisation de 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 pour qu’il accorde à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.
Juniper.junos
version 2.0.0, le
juniper_junos_config
module combine et remplace les fonctionnalités des
junos_commit
modules ,
junos_get_config
et
junos_install_config
junos_rollback
.