Utiliser Ansible pour récupérer ou comparer des configurations de Junos OS

Lorsque vous utilisez le juniper.device.config module pour récupérer la configuration, vous devez inclure le paramètre dans la retrieve liste des arguments du module. Le retrieve paramètre spécifie la base de données de configuration à partir de laquelle récupérer les données. Vous pouvez définir retrieve les valeurs suivantes pour renvoyer les données de configuration de la base de données respective :

• retrieve: 'candidate': récupère les données de la configuration candidate.

• retrieve: 'committed': récupère les données de la configuration validée.

Base de données de configuration validée

Le playbook suivant récupère la configuration validée complète au format texte pour chaque équipement du groupe d’inventaire :

Base de données de configuration candidate

Le playbook suivant récupère la configuration candidate complète au format texte pour chaque appareil du groupe d’inventaire. Le module renvoie une erreur si la base de données est verrouillée ou modifiée.

En plus de récupérer la configuration complète de Junos OS, vous pouvez récupérer des parties spécifiques de la configuration en incluant le config paramètre du filter module. La filter valeur du paramètre est une chaîne contenant le filtre de sous-arborescence qui sélectionne les instructions de configuration à renvoyer. Le filtre de sous-arborescence renvoie les données de configuration qui correspondent aux critères de sélection. Si vous demandez plusieurs hiérarchies, la valeur de filter doit représenter tous les niveaux de la hiérarchie de configuration, en commençant par la racine (représentée par l’élément <configuration> ) jusqu’à chaque élément à afficher.

Le playbook suivant récupère et imprime la configuration aux [edit interfaces] niveaux et [edit protocols] hiérarchique dans la base de données de configuration validée pour chaque équipement :

Le playbook suivant récupère et imprime la configuration de l’interface ge-1/0/1 :

Le playbook suivant récupère et imprime la configuration validée au niveau de la [edit system services] hiérarchie :

Lorsque vous utilisez le juniper.device.config module pour récupérer la configuration, le module appelle l’opération de protocole <get-configuration> XML Junos, qui peut renvoyer des données de configuration dans différents formats. Par défaut, le module renvoie les données de configuration sous forme de texte formaté. Le format de texte utilise des sauts de ligne, des tabulations et d’autres espaces, des accolades et des crochets pour indiquer les relations hiérarchiques entre les instructions.

Pour spécifier le format dans lequel renvoyer les données de configuration, définissez le config paramètre du format module sur le format souhaité. Les valeurs acceptables sont les suivantes :

• 'json'—JavaScript Object Notation (JSON)

• 'set'—Commandes Junos OS set

• 'text': texte formaté (par défaut)

• 'xml'—Éléments XML Junos

Dans la sortie du playbook, les config touches et config_lines contiennent la configuration au format demandé. Si vous demandez le format Junos XML ou JSON, la config_parsed clé contient la configuration équivalente au format JSON.

Le playbook suivant récupère la configuration validée complète pour chaque appareil du groupe d’inventaire au format XML :

Vous pouvez charger des modules YANG standardisés ou personnalisés sur les équipements Junos pour ajouter des modèles de données qui ne sont pas pris en charge nativement par Junos OS, mais qui peuvent l’être par traduction. Vous configurez les modèles de données non natifs dans la configuration candidate à l’aide de la syntaxe définie pour ces modèles. Lorsque vous validez la configuration, les scripts de traduction du modèle de données traduisent ces données et valident la configuration Junos OS correspondante en tant que modification temporaire de la configuration d’extraction.

Les configurations candidate et active contiennent les données de configuration des modèles de données YANG non natifs dans la syntaxe définie par ces modèles. Vous pouvez utiliser le module pour récupérer les juniper.device.config données de configuration des modèles de données YANG standard (IETF, OpenConfig) et personnalisés, en plus de récupérer la configuration native de Junos OS. Par défaut, les données de configuration pour les modèles de données YANG tiers ne sont pas incluses dans la réponse du module.

Pour récupérer les données de configuration définies par un modèle de données YANG non natif en plus de récupérer la configuration de Junos OS, exécutez le module avec le model paramètre et incluez le namespace paramètre le cas échéant. L’argument model prend l’une des valeurs suivantes :

• custom: récupère les données de configuration définies par les modèles de données YANG personnalisés. Vous devez inclure l’argument namespace lors de la récupération de données pour les modèles de données YANG personnalisés.

• ietf: récupère les données de configuration définies par les modèles de données IETF YANG.

• openconfig: récupère les données de configuration définies par les modèles de données YANG OpenConfig.

• True: récupère toutes les données de configuration, y compris la configuration complète de Junos OS et les données de tous les modèles de données YANG.

Si l’argument model spécifie ietf ou openconfig, le module utilise automatiquement l’espace de noms approprié. Si vous spécifiez model: "custom" de récupérer des données pour un modèle de données YANG personnalisé, vous devez également inclure l’argument namespace avec l’espace de noms correspondant.

Si vous incluez l’argument model avec la valeur custom, ietfou openconfig et incluez également l’argument filter pour renvoyer une sous-arborescence XML spécifique, Junos OS renvoie uniquement la hiérarchie correspondante à partir du modèle de données non natif. Si la configuration de Junos OS contient une hiérarchie du même nom, par exemple « interfaces », elle n’est pas incluse dans la réponse. L’option filter n’est pas prise en charge lors de l’utilisation de model: "True".

Lorsque vous utilisez le module pour récupérer des config données de configuration non natives, vous ne pouvez spécifier le format des données renvoyées que si vous incluez également le filter paramètre. Si vous omettez le filter paramètre, vous devez spécifier format: "xml".

Le playbook suivant récupère la hiérarchie de configuration OpenConfig interfaces à partir de la configuration validée. Si vous omettez l’argument filter , le RPC renvoie les configurations complètes de Junos OS et d’OpenConfig.

La tâche suivante récupère la l2vpn hiérarchie de configuration à partir de la configuration validée pour un modèle de données YANG personnalisé avec l’espace de noms donné :

La tâche suivante récupère la configuration validée complète de Junos OS, ainsi que les données de configuration des autres modèles de données YANG qui ont été ajoutés au périphérique :

Lorsque vous utilisez le juniper.device.config module pour récupérer la configuration, il appelle l’opération de protocole <get-configuration> XML Junos. Le module prend en charge les arguments explicites pour de nombreux <get-configuration> attributs, par exemple, l’attribut format . Le module prend également en charge l’argument options , ce qui vous permet d’inclure tous les attributs supplémentaires <get-configuration> qui n’ont pas d’argument de module équivalent. L’argument options prend un dictionnaire de paires clé/valeur de tous les attributs pris en charge par l’opération <get-configuration> .

Pour obtenir la liste complète des attributs pris en charge par l’opération du protocole <get-configuration> XML Junos, reportez-vous à la section <get-configuration>.

Par exemple, le config module récupère les données de la configuration pré-héritage, dans laquelle les <groups>balises , <apply-groups>, <apply-groups-except>et <interface-range> sont des éléments distincts dans la sortie de configuration. Pour récupérer des données à partir de la configuration post-héritage, qui affiche les instructions héritées de groupes et de plages définis par l’utilisateur en tant qu’enfants des instructions héritées, vous pouvez inclure l’argument options avec inherit: "inherit".

Le playbook suivant récupère les données de configuration au niveau de la [edit system services] hiérarchie à partir de la configuration validée post-héritage. Dans ce cas, si la configuration contient également des instructions configurées au niveau de la [edit groups global system services] hiérarchie, ces instructions sont héritées sous [edit system services] dans la configuration post-héritage et renvoyées dans les données de configuration récupérées.

Lorsque vous utilisez le juniper.device.config module pour récupérer la configuration, vous pouvez enregistrer les données de configuration renvoyées dans un fichier sur le nœud de contrôle Ansible local en incluant le dest_dir paramètre ou dest du module. L’option dest_dir spécifie simplement un répertoire, et l’option peut spécifier à la fois un chemin d’accès dest et un nom de fichier. Si un fichier de sortie existe déjà avec le nom de la cible, le module écrase le fichier.

Pour spécifier le répertoire sur le nœud de contrôle Ansible local dans lequel les configurations récupérées sont enregistrées, incluez l’argument dest_dir et définissez le chemin d’accès au répertoire cible. La configuration de chaque périphérique est stockée dans un fichier distinct nommé hostname.config.

Le playbook suivant récupère la configuration validée de tous les appareils du groupe d’inventaire. Le playbook enregistre chaque configuration d’appareil dans un fichier distinct dans le répertoire configs , sous le répertoire playbook, sur le nœud de contrôle Ansible.

Pour spécifier le chemin d’accès et le nom des fichiers de sortie, incluez l’argument dest et définissez le chemin absolu ou relatif du fichier. Si vous incluez l’argument dest , mais omettez le répertoire, les fichiers sont enregistrés dans le répertoire playbook. Si vous récupérez la configuration de plusieurs périphériques, l’argument dest doit inclure une variable telle que {{ inventory_hostname }} différencier le nom de fichier pour chaque périphérique. Si vous ne différenciez pas les noms de fichiers, le fichier de configuration de chaque périphérique écrasera le fichier de configuration des autres périphériques.

Le playbook suivant récupère la [edit system services] hiérarchie de la base de données de configuration validée sur tous les appareils du groupe d’inventaire. Le playbook enregistre chaque configuration d’appareil dans un fichier distinct dans le répertoire playbook du nœud de contrôle Ansible. Chaque fichier est identifié de manière unique par le nom d’hôte de l’appareil.

Si vous enregistrez les données de configuration dans des fichiers et que vous ne souhaitez pas dupliquer les données de configuration dans la réponse du module, vous pouvez éventuellement les inclure return_output: false dans la liste d’arguments du module. En réglant return_output sur false , le module omet les configclés , config_lineset config_parsed , dans sa réponse. Cela peut s’avérer nécessaire si l’équipement renvoie une quantité importante de données de configuration.

Le juniper.device.config module vous permet de comparer la configuration active à une configuration précédemment validée, ou à une configuration de restauration. Pour comparer la configuration active à une configuration précédente, incluez les arguments de module suivants :

Par défaut, lorsque vous incluez l’argument rollback: id , le module restaure la configuration, effectue une vérification de validation et valide les modifications. Vous devez inclure l’argument commit: false pour comparer uniquement les configurations et empêcher le module de charger et de valider la configuration de restauration. L’inclusion de l’argument check: false empêche l’opération inutile de vérification de validation.

Le module renvoie les diff clés et diff_lines . Les clés contiennent les différences de configuration entre la configuration active et la configuration précédente au format diff ou patch.

• diff— dictionnaire qui contient une seule clé nommée prepared et sa valeur, qui est une seule chaîne multiligne contenant les différences.

• diff_lines: liste de chaînes d’une seule ligne contenant les différences.

Pour enregistrer les différences dans un fichier sur le nœud de contrôle Ansible local, incluez l’argument diffs_file et définissez le chemin absolu ou relatif du fichier de sortie. Si vous incluez l’argument diffs_file mais omettez le répertoire, les fichiers sont enregistrés dans le répertoire playbook. Si vous comparez les configurations sur plusieurs périphériques, l’argument diffs_file doit inclure une variable telle que {{ inventory_hostname }} différencier le nom de fichier pour chaque périphérique. Si vous ne différenciez pas les noms de fichiers, le fichier de sortie de chaque périphérique écrasera le fichier de sortie des autres périphériques.

Le guide suivant vous invite à entrer l’ID de restauration d’une configuration précédemment validée. Le playbook compare ensuite la configuration validée à la configuration de restauration spécifiée, enregistre la comparaison dans un fichier au nom unique et imprime également la réponse à la sortie standard.