SUR CETTE PAGE
Comment spécifier le format des données de configuration à charger
Comment charger les données de configuration en tant que chaînes
Chargement des données de configuration à partir d’un fichier local ou distant
Chargement des données de configuration à l’aide d’un modèle Jinja2
Comment ignorer les avertissements lors de la configuration des équipements
Exemple: Utilisation d’Ansible pour configurer les équipements s’exécutant sous Junos OS
Utilisation d’Ansible pour configurer les équipements s’exécutant sous Junos OS
SYNTHÈSE Utilisez les modules Juniper Networks Ansible pour gérer la configuration sur les équipements sous Junos OS.
Juniper Networks modules Ansible vous permettent de configurer les équipements qui s’exécutent Junos OS. Le tableau 1 présente les modules disponibles. Le compte utilisateur utilisé pour apporter des modifications de configuration doit être autorisé à modifier les parties pertinentes de la configuration sur chaque équipement.
Ensemble de contenus |
Nom du module |
---|---|
|
|
|
À partir de la Juniper.junos
version 2.0.0, le module combine et remplace les fonctionnalités des juniper_junos_config
, et des junos_commit
junos_get_config
junos_install_config
junos_rollback
modules.
Les sections suivantes discutent de l’utilisation des modules pour modifier et valider la configuration sur les équipements qui s’exécutent Junos OS.
Présentation du module
Les modules et les modules vous permettent d’effectuer les opérations suivantes sur les config
juniper_junos_config
équipements s’exécutant Junos OS:
Données de configuration de charge
Valider la configuration
Retour à la configuration
Charger la configuration de sauvetage
Pour modifier la configuration, la liste d’arguments du module doit inclure soit les paramètres pour charger de nouvelles données de configuration, soit les paramètres pour revenir à la configuration de sauvetage ou une configuration précédemment load
rollback
engagée. Le processus de base pour apporter des modifications de configuration consiste à verrouiller la configuration, à charger les modifications de configuration, à la valider pour la rendre active, puis à déverrouiller la configuration.
Par défaut, les modules et les modules modifient la base de données de configuration du candidat en mode, ce qui verrouille et libère automatiquement la configuration globale config
juniper_junos_config
du configure exclusive
candidat. Vous pouvez également apporter des modifications à une copie privée de la configuration du candidat. 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 la spécification du mode de configuration, vous pouvez également spécifier le fonctionnement de la charge, la source et le format des modifications.
Opération de charge: le fonctionnement de la charge détermine la façon dont les données de configuration sont chargées dans la configuration de candidat. Les fonctions supportent un grand nombre des opérations de charge disponibles dans le Junos OS CLI. Pour plus d’informations, consultez comment spécifier l’action de charge.
Format: vous pouvez configurer les équipements qui s’Junos OS en utilisant l’un des formats standard pris en charge. Vous pouvez fournir des données de configuration ou des modèles Jinja2 en tant que texte, éléments XML Junos, Junos OS
set
commandes ou JSON. Pour plus d’informations sur la spécification du format des données de configuration, consultez la présentation 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 du nœud de contrôle Ansible local, d’un modèle Jinja2 ou d’une URL accessible depuis l’équipement client en incluant le , ou les
lines
src
template
paramètres,url
respectivement. Pour plus d’informations sur la spécification de la source des données de configuration, consultez les sections suivantes:
Les modules et les modules vous permettent également de charger et de valider la configuration de sauvetage ou de revenir à une config
juniper_junos_config
configuration précédemment engagée. Pour charger la configuration de sauvetage ou une configuration précédemment engagée, vous devez inclure rollback
l’argument du 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’équipement. Par défaut, les modules et les config
juniper_junos_config
modules validationent les modifications de configuration. Pour modifier ce comportement ou fournir des options de validation supplémentaires, consultez Comment valider la configuration.
Par défaut, lorsque le ou le module inclut les arguments en faveur de la modification de la configuration, le module renvoie automatiquement les changements de configuration au format diff ou correctif dans la réponse config
juniper_junos_config
du load
rollback
module. Les différences sont renvoyées dans le diff
et diff_lines
les variables. Pour empêcher le module de calculer et de renvoyer les différences, définissez diff
l’argument du 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 du candidat. Par défaut, les modules et les modules modifient la base de données de config
juniper_junos_config
configuration des candidats en configure exclusive
mode. Le mode exclusif de configuration verrouille la configuration globale du candidat (également appelée base de données de configurationpartagée) aussi longtemps que le module nécessite d’apporter les modifications demandées à la configuration. Le verrouillage de la base de données empêche les autres utilisateurs de modifier ou d’engager des modifications dans la base de données jusqu’à ce que la verrou soit libérée.
Pour spécifier le mode, inclure les config_mode
paramètres dans la liste d’arguments du module. Les modes pris en charge incluent exclusive
et private
. Ces deux modes rejettent toute modification non émise à la sortie.
Le manuel suivant utilise le configure private
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
Comment spécifier l’action de charge
Les config
juniper_junos_config
modules et les modules supportent le chargement des changements de configuration en utilisant un grand nombre des opérations de charge prise en charge dans le Junos OS CLI. Vous spécifiez le fonctionnement de la charge en incluant le paramètre dans la liste d’arguments du module et en le paramétant sur la valeur de load
l’opération de charge correspondante. Le tableau 2 résume les paramètres requis pour chaque type de charge.
Opérations de charge |
argument de charge |
Description |
---|---|---|
|
|
Fusionner la configuration chargée avec la configuration existante. |
|
|
Remplacez l’ensemble de la configuration par la configuration chargée. |
|
|
Fusionner la configuration chargée avec la configuration existante, mais remplacer les instructions de la configuration existante par celles qui spécifient la balise |
|
|
Charger les données de configuration à partir d’un fichier correctif. |
|
|
Données de configuration de charge au |
|
|
Comparez la configuration complète chargée par rapport à la configuration existante. Chaque élément de configuration différent dans la configuration chargée remplace l’é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 traitent la nouvelle configuration. |
Comment spécifier le format des données de configuration à charger
Les modules et les modules vous permettent de configurer des équipements qui s’Junos OS avec l’un des config
juniper_junos_config
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. Lors de la fourniture de données de configuration au sein d’une chaîne, d’un fichier ou d’un modèle Jinja2, les formats pris en charge pour ces données incluent le texte, les éléments XML Junos, les commandes de Junos OS set
et JSON.
À partir de Junos OS version 16.1R1, les équipements exécutant Junos OS chargent les données de configuration dans le format JSON.
Les modules et les modules tentent de détecter automatiquement le format des données de config
configuration fournies sous forme de juniper_junos_config
chaînes à l’aide de lines
l’argument. Cependant, vous pouvez spécifier le format des chaînes en incluant format
l’argument. 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 format
l’argument.
Le tableau 3 résume les formats pris en charge pour les données de configuration et la valeur correspondante de l’extension et des paramètres des format
fichiers. Si vous inclut l’argument, il remplace le format de détection automatique des chaînes et le format
format indiqué par une extension de fichier.
Format des données de configuration |
Extension de fichier |
Paramètre du format |
---|---|---|
CLI de configuration générale (texte) |
.fr/fr |
" |
Notation des objets JavaScript (JSON) |
.json |
" |
Junos OS de |
.set |
" |
Éléments XML Junos |
.xml |
" |
Lorsque vous définissez l’argument du module ou que vous ne pouvez pas utiliser Junos OS load
'override'
format de 'update'
set
commande.
Comment charger les données de configuration en tant que chaînes
Les config
juniper_junos_config
modules et les modules vous permettent de charger des données de configuration à partir d’une liste de chaînes. Pour charger les données de configuration comme chaînes, inclure load
l’argument approprié et lines
l’argument. lines
L’argument 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 lines
de configuration. Cependant, vous pouvez spécifier le format en incluant format
l’argument. Pour plus d’informations sur la spécification du format, consultez la présentation des données de configuration à charger. Si vous inclut les paramètres dans la liste d’arguments du module, il remplace le format
format de détection automatique.
Le manuel suivant configure et commit deux scripts op. Dans ce cas, l’argument présente une valeur, car les données de configuration dans l’utilisation Junos OS load
'set'
format de lines
set
l’énoncé.
--- - 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 manuel 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
Chargement des données de configuration à partir d’un fichier local ou distant
Les config
juniper_junos_config
modules et les modules 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
Équipement client
URL accessible depuis l’équipement 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 de celui-ci. Les formats de données de configuration pris en charge incluent le texte, des éléments XML Junos, Junos OS set
commandes 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 les paramètres dans la liste d’arguments du module ou en ajoutant l’extension appropriée au fichier de données format
de configuration. Si vous spécifiez le paramètre, il remplace le format
format indiqué par l’extension du fichier. Pour plus d’informations sur la spécification du format, consultez la présentation des données de configuration à charger. Lorsque les données de configuration utilisent le format XML Junos, vous devez les joindre à la balise de <configuration>
haut niveau.
Il n’est pas nécessaire de joindre des données de configuration au format ASCII, des commandes Junos OS ou JSON dans , ou des balises, comme requis lors de la configuration de l’équipement directement au sein d’une set
<configuration-text>
session <configuration-set>
<configuration-json>
NETCONF.
Le tableau 4 présente les paramètres du module que vous pouvez inclure pour spécifier la position du fichier.
Paramètre du module |
Description |
---|---|
|
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 manuel. |
|
Chemin absolu ou relatif vers un fichier sur l’équipement client, un emplacement FTP ou une URL HTTP (Hypertext Transfer Protocol). Le répertoire par défaut de l’équipement client est le répertoire de travail actuel, qui est par défaut celui de l’utilisateur. |
Pour charger les données de configuration à partir d’un fichier local sur le nœud de contrôle Ansible, définissez l’argument en faveur du chemin absolu ou relatif du fichier contenant src
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 les données de configuration à partir d’un fichier de l’équipement géré qui s’exécute sur Junos OS, ou d’un FTP ou d’une URL HTTP, utilisez les paramètres et spécifiez le chemin du fichier qui contient les données de configuration à url
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 peut être un chemin de fichier local absolu ou relatif, un emplacement FTP ou une url
URL HTTP (Hypertext Transfer Protocol).
Un nom de fichier local peut présenter l’un des formulaires suivants:
/ path filename / —Fichier sur un système de fichiers monté, soit sur le disque flash local, soit sur le disque dur.
a: filename ou a: path / filename — Fichier sur le disque local. Le chemin par défaut est / (le répertoire au niveau racine). Le support amovible peut être au format MS-DOS ou UNIX (UFS).
Un nom de fichier d’un fichier sur un serveur FTP présente le formulaire suivant:
ftp://username:password@hostname/path/filename
Un nom de fichier d’un fichier sur un serveur HTTP présente le formulaire suivant:
http://username:password@hostname/path/filename
Dans chaque cas, la valeur par défaut de la path variable est le répertoire d’accueil de l’utilisateur. Pour spécifier un chemin absolu, l’application lance le chemin avec les caractères %2F; par exemple, ftp:// username password : @ hostname /%2F path / filename .
Chargement des données de configuration à l’aide d’un modèle Jinja2
Les modules et les modules vous permettent de rendre les données de configuration à partir d’un fichier de modèle Jinja2 sur le nœud de contrôle Ansible, de charger et de valider la configuration sur un équipement exécutant Junos OS. Jinja est un moteur de modèle pour Python qui vous permet de générer des documents à partir de config
juniper_junos_config
modèles prédéfini. 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 Junos OS de configuration à l’aide des modèles Jinja2 dans l’un des formats de configuration pris en charge, qui inclut le texte ASCII, les éléments XML Junos, les commandes Junos OS set
et JSON. Les modules Ansible utilisent le modèle Jinja2 et un dictionnaire fourni des variables pour fournir les données de configuration.
Pour charger et valider les données de configuration à l’aide d’un modèle Jinja2, inclure les paramètres et les éléments de la template
vars
liste d’arguments du module.
template
—Chemin du fichier de modèle Jinja2vars
— Dictionnaire des clés et valeurs requises pour rendre le modèle Jinja2
Vous devez également inclure le paramètre lorsque l’extension de fichier des format
modèles n’indique pas le format des données. Pour plus d’informations sur la spécification du format, consultez la présentation 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 ou le module pour charger le modèle config
Jinja2, définissez l’argument en direction du chemin du fichier de modèle et définissez les variables requises par le modèle juniper_junos_config
template
du vars
dictionnaire. Le manuel suivant utilise le modèle Jinja2 et les variables définies pour rendre les données de configuration, les charger et les valider sur vars
l’hôte cible. Le paramètre indique le format des données de format
configuration dans le fichier de 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, chargées dans la configuration du candidat sur l’équipement et engagé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 sauvetage vous permet de définir une configuration de fonctionnement connue ou une configuration avec un état connu que vous pouvez restaurer à tout moment. Vous utilisez la configuration de sauvegarde lorsque vous devez retourner à une configuration connue ou en dernier recours si la configuration de l’équipement et les fichiers de configuration de sauvegarde deviennent endommagés après réparation. Lorsque vous créez une configuration de sauvegarde, l’équipement enregistre la configuration la plus récemment engagée comme configuration de sauvegarde.
Les modules et les modules vous permettent de retourner à une configuration de sauvetage existante sur les équipements qui config
juniper_junos_config
s’exécutent Junos OS. Pour charger et valider la configuration de sauvetage sur un équipement, inclut 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 revenir à la configuration
Les équipements Junos OS stockent une copie de la configuration 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 pratique est utile lorsque les modifications de configuration provoquent des résultats indésirables et que vous souhaitez revenir à une configuration de fonctionnement connue. Le retour de la configuration est similaire au processus d’apporter des modifications de configuration à l’équipement, mais au lieu de charger les données de configuration, vous effectuez une opération de retour en arrière, qui remplace l’ensemble de la configuration du candidat par une configuration précédemment engagée.
Les config
modules et les modules vous permettent de revenir à une configuration précédemment engagée sur les équipements exécutant juniper_junos_config
Junos OS. Pour revenir sur la configuration et la valider, inclure l’argument du module rollback
et spécifier l’ID de la configuration de retour en arrière. Les valeurs d’ID valides sont de 0 (zéro, pour la configuration la plus récemment validée) et sont inférieures au nombre de configurations précédentes stockées (la maximale est de 49).
Le manuel suivant invite à restaurer l’ID de la configuration, à restaurer la configuration, à la restaurer et à la valider, puis à désattenter les changements de configuration en 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 ou le module pour modifier la configuration en utilisant l’argument ou config
l’argumentaire, le module effectue automatiquement une vérification de validation et validation juniper_junos_config
load
des rollback
modifications. Pour empêcher le module d’effectuer une vérification de validation ou de valider les modifications, définissez check
commit
l’ou l’argumentaire false
vers , respectivement.
Vous pouvez également personnaliser l’opération de validation avec la plupart des options disponibles dans le Junos OS CLI. Le Tableau 5 présente les arguments du module que vous pouvez utiliser pour spécifier différentes options de validation.
Argument des modules |
Description |
Valeur par défaut pour et |
---|---|---|
|
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és entre la vérification de validation et l’opération de validation. |
– |
|
Enregistrez un commentaire sur cette opération de validation dans le fichier journal système et dans l’historique de validation de l’équipement. |
– |
|
Commit the configuration changes or confirm a previous confirmed commit operation. |
|
|
Commit the configuration changes even if there there there no differences between the candidate configuration and the committed configuration. |
|
|
Exigez qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale. Sinon, revenir à la configuration précédemment engagée.
|
– |
Lorsque vous commitez la configuration, vous pouvez inclure un bref commentaire pour décrire le but des modifications engagées. Pour enregistrer un commentaire décrivant les modifications, inclure comment: "comment string"
l’argumentaire avec la chaîne de messages.
Par défaut, les modules et les config
juniper_junos_config
modules exécutent une vérification de validation et une opération de validation. Cet argument définit le nombre de secondes à attendre entre les opérations de vérification de validation et check_commit_wait
de validation. Inclure cet argument lorsque vous devez fournir suffisamment de temps à l’équipement 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 y avoir certaines circonstances dans lesquelles un équipement lance l’opération de validation avant que l’opération de vérification de validation libère sa verrouille sur la configuration, ce qui peut entraîner une opération de validation, puis CommitError
l’échec.
Par défaut, s’il n’y a aucune différence entre la configuration du candidat et la configuration engagée, le module ne commit pas les modifications. Pour forcer une opération de validation même lorsqu’il n’y a aucune différence, inclure commit_empty_changes: true
l’argument.
Pour exiger qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale, inclure confirmed: minutes
l’argument. Si la validation n’est pas confirmée dans le délai donné, la configuration revient automatiquement à la configuration précédemment engagée. La plage autorisée est de 1 à 65 535 minutes. L’opération de validation confirmée permet de vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas la gestion d’accéder à l’équipement. Si la modification empêche l’accès ou provoque d’autres erreurs, le retour à la configuration précédente permet d’accéder à l’équipement après la date butoir de retour en arrière. Pour confirmer l’opération de validation, invoquer le config
ou le module avec juniper_junos_config
check: true
l’ou commit: true
l’argumentaire.
Dans le manuel suivant, la première tâche modifie la configuration, attend 10 secondes entre le contrôle 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 sur la validation. La deuxième tâche consiste à mettre commit check
en place une 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 que si les tâches passent 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 des équipements
Les modules et vous permettent de modifier et de valider la configuration sur les config
juniper_junos_config
équipements s’exécutant Junos OS. Dans certains cas, la réponse au RPC peut contenir des éléments dont le niveau de gravité de l’avertissement est ou supérieur, ce qui peut entraîner l’échec de la charge ou de la validation du <rpc-error>
RpcError
module.
Dans certains cas, il peut être nécessaire ou souhaitable d’supprimer les exceptions qui sont élevées en réponse aux avertissements des opérations de charge RpcError
et de validation. Vous pouvez demander aux modules et aux modules de supprimer les exceptions qui sont élevées pour les avertissements en incluant les paramètres dans la config
juniper_junos_config
liste RpcError
ignore_warning
d’arguments du module. ignore_warning
L’argument prend un booléan, une chaîne ou une liste de chaînes.
Pour demander au module d’ignorer tous les avertissements d’opérations de charge et de validation exécutées par le module, inclure ignore_warning: true
l’argument. L’exemple suivant ignore tous les avertissements d’opérations de charge 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 inclut et que tous les éléments comportent un niveau de gravité de l’avertissement, l’application ignore tous les avertissements et ne ignore_warning: true
<rpc-error>
soulève pas RpcError
d’exception. Cependant, tous les <rpc-error>
éléments ayant des niveaux de gravité plus élevés soulèvent encore des exceptions.
Pour demander au module d’ignorer des avertissements spécifiques, définissez l’argument en chaîne ou une liste de ignore_warning
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 device running Junos OS 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 les exceptions si tous les éléments ont un niveau de gravité d’avertissement et que chaque avertissement de la réponse correspond à une ou plusieurs RpcError
<rpc-error>
chaînes spécifiées.
Exemple: Utilisation d’Ansible pour configurer les équipements s’exécutant sous Junos OS
Le module vous permet de gérer la configuration sur les config
équipements s’exécutant Junos OS. Cet exemple utilise le module pour apporter des modifications de configuration à un équipement s’exécutant Junos OS config
via NETCONF sur SSH.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants:
Serveur de gestion de configuration exécutant Ansible 2.10 ou ultérieure avec
juniper.device
la collection installéeL’équipement Junos OS avec NETCONF et un compte utilisateur configuré avec les autorisations appropriées
Paire de clés publiques/privées SSH configurée pour l’utilisateur approprié sur le contrôleur Ansible et l’équipement sous Junos OS
Fichier d’inventaire Ansible existant avec les hôtes requis définis
Aperçu
Cet exemple présente un manuel Ansible qui utilise le module pour activer un nouveau script opérationnel dans la configuration des équipements cibles qui config
s’exécutent Junos OS. Le fichier de données de configuration, junos-config.conf,contient les données de configuration pertinentes au format sous forme de texte.
Le manuel inclut la tâche, qui utilise le module Ansible pour essayer d’établir une session NETCONF avec l’équipement cible à l’aide du port par défaut Checking NETCONF connectivity
wait_for
NETCONF (830). Si le nœud de contrôle ne parvient pas à établir une session NETCONF avec un équipement cible lors de l’exécution du playbook, alors il ignore les tâches restantes dans la lecture de cet équipement.
La tâche de configuration de l’équipement exécute le module à condition que la vérification config
NETCONF soit réussie. load: "merge"
L’argumentaire du module charge les nouvelles données de configuration dans la configuration du candidat à l’aide load merge
d’une opération. Par défaut, le module validatione les données de config
configuration sur l’équipement et load
les rollback
opérations. Les arguments du module incluent l’argument, qui enregistre un commentaire de validation dans le fichier journal système de comment
l’équipement et l’historique de validation.
Configuration
Création du 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 selon le format des données de configuration, dans cet exemple, en texte.
Inclure 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 guide électronique Ansible
Procédure étape par étape
Pour créer un manuel qui utilise le module pour apporter des modifications de configuration sur un équipement sous config
Junos OS:
Inclut la base de données de lecture, qui exécute les modules localement.
--- - name: Load and commit configuration data on a device running Junos OS 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’équipement et la valider.
- 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 changements de configuration au format diff.
- name: Print the response debug: var: response
Résultats
Sur le nœud de contrôle Ansible, examinez le manuel terminé. Si le manuel n’affiche pas le code prévu, répétez les instructions de cet exemple pour corriger le manuel.
--- - name: Load and commit configuration data on a device running Junos OS 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écution du Guide
Pour exécuter le manuel:
Numérotez la commande sur le nœud de contrôle et fournissez le chemin du manuel et
ansible-playbook
toutes les options souhaitées.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-config.yaml PLAY [Load and commit configuration data on a device running Junos OS] **** 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érification de la configuration
But
Vérifiez que la configuration a été correctement mise à jour sur l’équipement sous Junos OS.
Action
Consultez le manuel Ansible pour savoir si la tâche de configuration a réussi ou échoué. Vous pouvez également vous connecter à l’équipement qui s’exécute sur Junos OS afficher la configuration, l’historique de validation et les fichiers journaux pour vérifier la configuration et la validation, 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
Dépannage des erreurs du Guide
- Dépannage des erreurs de délai d’insé time-out
- Erreurs de verrouillage de configuration de dépannage
- Erreurs de modification de configuration de dépannage
Dépannage des erreurs de délai d’insé time-out
Problème
Le manuel génère un TimeoutExpiredError
message d’erreur et ne parvient pas à mettre à jour la configuration de l’équipement.
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
Le délai d’insé time-out d’un RPC NETCONF est de 30 secondes. D’importantes modifications de configuration peuvent dépasser cette valeur, ce qui peut entraîner le délai d’attente de l’opération avant que la configuration puisse être téléchargée et engagée.
Solution
Pour prendre en charge les changements de configuration qui peuvent nécessiter un temps de validation plus long que l’intervalle d’engagement par défaut en RPC, définissez l’argument du module en valeur appropriée et exécutez à nouveau le timeout
manuel.
Erreurs de verrouillage de configuration de dépannage
Problème
Le manuel 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 la configuration peut se produire pour les raisons suivantes:
Un autre utilisateur a la verrouille exclusive de la configuration.
Un autre utilisateur a apporté des modifications à la base de données de configuration, mais n’a pas encore engagé ces modifications.
L’utilisateur qui exécute le module Ansible ne peut pas configurer l’équipement.
Solution
La LockError
chaîne de messages indique généralement la cause racine du problème. Si un autre utilisateur a une verrouillage exclusif de la configuration ou a modifié sa configuration, attendez la sortie de cette verrou ou les modifications, puis exécutez à nouveau le manuel. Si la cause du problème est que l’utilisateur n’a pas les autorisations nécessaires pour configurer l’équipement, exécutez le manuel avec un utilisateur dispose des autorisations nécessaires, ou, le cas échéant, configurez l’équipement en cours d’exécution Junos OS afin de donner à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.
Erreurs de modification de configuration de dépannage
Problème
Le manuel génère un message d’erreur indiquant que la configuration ne peut pas être ConfigLoadError
modifiée, car l’autorisation est refusé.
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 qui exécute 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 manuel avec un utilisateur qui dispose des autorisations nécessaires, ou, le cas échéant, configurez l’équipement en cours d’exécution Junos OS afin de donner à l’utilisateur actuel les autorisations nécessaires pour effectuer les modifications.