Utilisation d’Ansible pour configurer les équipements s’exécutant sous Junos OS

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:

  • 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

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:

• Comment charger la configuration de sauvetage

• Comment revenir à la configuration

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 .

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:

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.

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.

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.

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é.

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é.

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.

Le tableau 4 présente les paramètres du module que vous pouvez inclure pour spécifier la position du fichier.

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:

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:

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:

• Un nom de fichier d’un fichier sur un serveur HTTP présente le formulaire suivant:

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 .

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 Jinja2

• vars— 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:

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.

Le module génère les données de configuration suivantes, chargées dans la configuration du candidat sur l’équipement et engagées:

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:

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.

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.

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.

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.

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:

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.