Uso de Ansible para configurar dispositivos Junos

El juniper.device.config módulo le permite realizar las siguientes operaciones en dispositivos Junos:

• Cargar datos de configuración

• Confirmar la configuración

• Revertir la configuración

• Cargar la configuración de rescate

Para modificar la configuración, la lista de argumentos del módulo debe incluir el load parámetro para cargar nuevos datos de configuración o el rollback parámetro para revertir a la configuración de rescate o una configuración confirmada anteriormente. El proceso básico para realizar cambios en la configuración consiste en bloquear la configuración, cargar los cambios de configuración, confirmar la configuración para activarla y, a continuación, desbloquear la configuración.

De forma predeterminada, el config módulo realiza cambios en la base de datos de configuración candidata utilizando configure exclusive el modo, que bloquea y desbloquea automáticamente la configuración global candidata. También puede especificar un modo de configuración diferente. Por ejemplo, puede realizar cambios en una copia privada de la configuración candidata o en la base de datos de configuración efímera. Para obtener más información acerca de cómo especificar el modo de configuración, consulte Cómo especificar el modo de configuración.

Al cargar nuevos datos de configuración, además de especificar el modo de configuración, también puede especificar la operación de carga y el origen y formato de los cambios.

• Operación de carga: la operación de carga determina cómo se cargan los datos de configuración en la base de datos de configuración seleccionada. La función admite muchas de las mismas operaciones de carga que están disponibles en la CLI de Junos OS. Para obtener más información, consulte Cómo especificar la acción de carga.

• Formato: puede configurar dispositivos Junos con uno de los formatos estándar compatibles. Puede proporcionar datos de configuración o plantillas Jinja2 como texto, elementos XML de Junos, comandos de Junos OS set o JSON. Para obtener información acerca de cómo especificar el formato de los datos de configuración, consulte Cómo especificar el formato de los datos de configuración que se van a cargar.

• Origen de datos de configuración: puede cargar datos de configuración desde una lista de cadenas, un archivo en el nodo de control local de Ansible, una plantilla Jinja2 o una URL accesible desde el dispositivo cliente incluyendo el linesparámetro, src, templateo , respectivamente url . Para obtener más información acerca de cómo especificar el origen de los datos de configuración, consulte las secciones siguientes:

  • Cómo cargar datos de configuración como cadenas

  • Cómo cargar datos de configuración desde un archivo local o remoto

  • Cómo cargar datos de configuración usando una plantilla Jinja2

El config módulo también le permite cargar y confirmar la configuración de rescate o revertir la configuración a una configuración previamente confirmada. Para cargar la configuración de rescate o una configuración confirmada anteriormente, debe incluir el argumento module rollback . Para obtener más información, consulte las secciones siguientes:

• Cómo cargar la configuración de rescate

• Cómo revertir la configuración

Después de modificar la configuración, debe confirmar la configuración para convertirla en la configuración activa en el dispositivo. De forma predeterminada, el config módulo confirma los cambios en la configuración. Para modificar este comportamiento o proporcionar opciones de confirmación adicionales, consulte Cómo confirmar la configuración.

De forma predeterminada, cuando el config módulo incluye los load argumentos o rollback para cambiar la configuración, el módulo devuelve automáticamente los cambios de configuración en formato diff o parche en la respuesta del módulo. Las diferencias se devuelven en las diff variables y diff_lines . Para evitar que el módulo calcule y devuelva las diferencias, establezca el argumento del diff módulo en false.

Puede especificar el modo de configuración que se utilizará al modificar la configuración del dispositivo. Para especificar el modo de configuración en la tarea, incluya el config parámetro del config_mode módulo. Los modos de configuración admitidos incluyen:

• batch

• dynamic

• ephemeral

• exclusive

• private

De forma predeterminada, el módulo realiza cambios en la base de datos de configuración candidata utilizando configure exclusive el juniper.device.config modo. El modo exclusivo de configuración bloquea la configuración global candidata (también conocida como base de datos de configuración compartida) durante el tiempo que el módulo requiera realizar los cambios solicitados en la configuración. El bloqueo de la base de datos impide que otros usuarios modifiquen o confirmen cambios en la base de datos hasta que se libere el bloqueo.

En los ejemplos siguientes se muestra cómo configurar una copia privada de la configuración candidata y cómo configurar la base de datos efímera.

• Ejemplo: config_mode: "privado"
• Configurar la base de datos efímera

El juniper.device.config módulo admite la carga de cambios de configuración mediante muchas de las mismas operaciones de carga admitidas en la CLI de Junos OS. La operación de carga se especifica incluyendo el load parámetro en la lista de argumentos del módulo y estableciéndolo en el valor de la operación de carga correspondiente. En la tabla 2 se resumen los parámetros necesarios para cada tipo de operación de carga.

Tabla 2: Parámetros para especificar la operación de carga

Operación de carga	load Argumento	Descripción
load merge	load: "merge"	Combine la configuración cargada con la configuración existente.
load override	load: "override"	Reemplace toda la configuración por la configuración cargada.
load patch	load: "patch"	Cargue los datos de configuración desde un archivo de revisión.
load replace	load "replace"	Combine la configuración cargada con la configuración existente, pero reemplace las instrucciones de la configuración existente por aquellas que especifican la replace: etiqueta en la configuración cargada. Si no hay ninguna instrucción en la configuración existente, se agrega la instrucción en la configuración cargada.
load set	load: "set"	Cargue los datos de configuración que están en set formato. Los datos de configuración se cargan línea por línea y pueden contener comandos de modo de configuración como set, deletey deactivate.
load update	load: "update"	Compare la configuración cargada completa con la configuración existente. Cada elemento de configuración que es diferente en la configuración cargada reemplaza su elemento correspondiente en la configuración existente. Durante la operación de confirmación, solo los procesos del sistema que se ven afectados por los elementos de configuración modificados analizan la nueva configuración.

El juniper.device.config módulo le permite configurar dispositivos Junos mediante uno de los formatos estándar compatibles. Puede proporcionar datos de configuración como cadenas o archivos. Los archivos pueden contener datos de configuración o plantillas Jinja2. Al proporcionar datos de configuración dentro de una cadena, archivo o plantilla Jinja2, los formatos admitidos para los datos incluyen texto, elementos XML de Junos, comandos de Junos OS set y JSON.

El config módulo intenta detectar automáticamente el formato de los datos de configuración que proporciona como cadenas dentro del lines argumento. Sin embargo, puede especificar explícitamente el formato de las cadenas incluyendo el format argumento. Cuando proporcione datos de configuración en un archivo o plantilla Jinja2, debe especificar el formato de los datos agregando la extensión adecuada al archivo o incluyendo el format argumento.

En la tabla 3 se resumen los formatos admitidos para los datos de configuración y el valor correspondiente para la extensión de archivo y format el parámetro. Si incluye el format argumento, invalida tanto el formato de detección automática de cadenas como el formato indicado por una extensión de archivo.

Tabla 3: Especificación del formato de los datos de configuración

Formato de datos de configuración	Extensión de archivo	parámetro format
Instrucciones de configuración de CLI (texto)	.Conf	"text"
Notación de objetos JavaScript (JSON)	.json	"json"
Comandos de Junos OS set	.poner	"set"
Elementos XML de Junos	.XML	"xml"

Nota:

Cuando establece el argumento del load módulo en 'override' o 'update', no puede utilizar el formato de comando de Junos OS set .

El juniper.device.config módulo le permite cargar datos de configuración desde una lista de cadenas. Para cargar datos de configuración como cadenas, incluya el argumento apropiado load y el lines argumento. El lines argumento toma una lista de cadenas que contienen los datos de configuración para cargar.

El módulo intenta detectar automáticamente el formato de los lines datos de configuración. Sin embargo, puede especificar explícitamente el formato incluyendo el format argumento. Para obtener información acerca de cómo especificar el formato, consulte Cómo especificar el formato de los datos de configuración que se van a cargar. Si incluye el format argumento, invalida el formato detectado automáticamente.

El siguiente manual configura y confirma dos scripts operativos. En este caso, el load argumento tiene el valor 'set', ya que los datos de configuración utilizan lines el formato de instrucción Junos OS set .

En el siguiente manual se configuran las mismas instrucciones mediante lines datos de configuración en formato de texto. En este caso, load: "merge" se utiliza.

El juniper.device.config módulo le permite cargar datos de configuración desde un archivo. El archivo puede residir en una de las siguientes ubicaciones:

• Nodo de control de Ansible

• Dispositivo cliente

• URL accesible desde el dispositivo cliente

Al cargar datos de configuración desde un archivo, debe indicar la ubicación del archivo y el formato de los datos de configuración en el archivo. Los formatos de datos de configuración admitidos incluyen texto, elementos XML de Junos, comandos de Junos OS set y JSON. Para obtener información acerca de cómo cargar archivos que contienen plantillas Jinja2, consulte Cómo cargar datos de configuración mediante una plantilla Jinja2.

Puede especificar el formato de los datos de configuración incluyendo explícitamente el format parámetro en la lista de argumentos del módulo o agregando la extensión adecuada al archivo de datos de configuración. Si especifica el format parámetro, anula el formato indicado por la extensión de archivo. Para obtener información acerca de cómo especificar el formato, consulte Cómo especificar el formato de los datos de configuración que se van a cargar. Cuando los datos de configuración utilizan el formato XML de Junos, debe encerrar los datos en la etiqueta de nivel <configuration> superior.

Nota:

No es necesario incluir datos de configuración con formato de texto ASCII, comandos de Junos OS set o JSON en <configuration-text>, ni <configuration-json> etiquetas, <configuration-set>según sea necesario, al configurar el dispositivo directamente dentro de una sesión de NETCONF.

En la tabla 4 se describen los parámetros del módulo que puede incluir para especificar la ubicación del archivo.

Tabla 4: Especificación de la ubicación del archivo de configuración

Parámetro de módulo	Descripción
src	Ruta absoluta o relativa a un archivo en el nodo de control de Ansible. El directorio predeterminado es el directorio del manual.
url	Ruta absoluta o relativa a un archivo en el dispositivo cliente, o a una ubicación FTP o una URL HTTP. El directorio predeterminado del dispositivo cliente es el directorio de trabajo actual, que de forma predeterminada es el directorio principal del usuario.

Para cargar datos de configuración desde un archivo local en el nodo de control de Ansible, establezca el src argumento en la ruta absoluta o relativa del archivo que contiene los datos de configuración. Por ejemplo:

Para cargar datos de configuración desde un archivo en el dispositivo Junos o desde una URL FTP o HTTP, utilice el url parámetro y especifique la ruta del archivo que contiene los datos de configuración que se van a cargar. Por ejemplo:

El valor de puede url ser una ruta de archivo local absoluta o relativa, una ubicación FTP o una dirección URL HTTP.

• La ruta de acceso de un archivo local en el dispositivo de destino tiene una de las siguientes formas:

  • /path/filename: archivo en un sistema de archivos montado, ya sea en el disco flash local o en el disco duro.

  • un:filename o un:path/filename—Archivo en la unidad local. La ruta predeterminada es / (el directorio de nivel raíz). Los medios extraíbles pueden estar en formato MS-DOS o UNIX (UFS).

• La ruta de acceso de archivo para un archivo en un servidor FTP tiene la siguiente forma:

• La ruta de acceso de un archivo en un servidor HTTP tiene el siguiente formato:

En cada caso, el valor predeterminado de la path variable es el directorio principal del usuario. Para especificar una ruta absoluta, la aplicación inicia la ruta con los caracteres %2F; por ejemplo, ftp://username:password@hostname/%2Fpath/filename.

El juniper.device.config módulo le permite representar datos de configuración desde un archivo de plantilla Jinja2 en el nodo de control de Ansible y cargar y confirmar la configuración en un dispositivo Junos. Jinja es un motor de plantillas para Python que le permite generar documentos a partir de plantillas predefinidas. Las plantillas, que son archivos de texto en el idioma deseado, proporcionan flexibilidad mediante el uso de expresiones y variables. Puede crear datos de configuración de Junos OS con plantillas Jinja2 en uno de los formatos de configuración compatibles, que incluye texto ASCII, elementos XML de Junos, comandos de Junos OS set y JSON. El módulo de Ansible utiliza la plantilla Jinja2 y un diccionario de variables suministrado para representar los datos de configuración.

Para cargar y confirmar datos de configuración mediante una plantilla Jinja2, incluya los template parámetros y vars en la lista de argumentos del módulo.

• template—Ruta del archivo de plantilla Jinja2

• vars—Diccionario de claves y valores necesarios para representar la plantilla Jinja2

También debe incluir el format parámetro cuando la extensión de archivo de la plantilla no indique el formato de los datos. Para obtener información acerca de cómo especificar el formato, consulte Cómo especificar el formato de los datos de configuración que se van a cargar.

Por ejemplo, el archivo interfaces-mpls.j2 contiene la siguiente plantilla Jinja2:

Para usar el juniper.device.config módulo para cargar la plantilla Jinja2, establezca el template argumento en la ruta del archivo de plantilla y defina las variables requeridas por la plantilla en el vars diccionario. El siguiente manual utiliza la plantilla Jinja2 y las variables definidas en vars para representar los datos de configuración y cargarlos y confirmarlos en el host de destino. El format parámetro indica el formato de los datos de configuración en el archivo de plantilla.

El módulo genera los siguientes datos de configuración, que se cargan en la configuración candidata en el dispositivo y se confirman:

Una configuración de rescate le permite definir una configuración de trabajo conocida o una configuración con un estado conocido que puede restaurar en cualquier momento. Utilice la configuración de rescate cuando necesite volver a una configuración conocida o como último recurso si la configuración del dispositivo y los archivos de configuración de copia de seguridad se dañan sin posibilidad de reparación. Cuando se crea una configuración de rescate, el dispositivo guarda la configuración confirmada más reciente como configuración de rescate.

El juniper.device.config módulo le permite revertir a una configuración de rescate existente en dispositivos Junos. Para cargar y confirmar la configuración de rescate en un dispositivo, incluya el argumento del rollback: "rescue" módulo. Por ejemplo:

Los dispositivos Junos almacenan una copia de la configuración confirmada más reciente y hasta 49 configuraciones anteriores, dependiendo de la plataforma. Puede revertir a cualquiera de las configuraciones almacenadas. Esto resulta útil cuando los cambios en la configuración provocan resultados no deseados y desea volver a una configuración de trabajo conocida. La reversión de la configuración es similar al proceso para realizar cambios de configuración en el dispositivo, pero en lugar de cargar los datos de configuración, se realiza una reversión, que reemplaza toda la configuración candidata por una configuración confirmada anteriormente.

El juniper.device.config módulo le permite revertir a una configuración previamente confirmada en dispositivos Junos. Para revertir la configuración y confirmarla, incluya el argumento del rollback módulo y especifique el ID de la configuración de reversión. Los valores de ID válidos son 0 (cero, para la configuración confirmada más recientemente) a través de uno menos que el número de configuraciones anteriores almacenadas (el máximo es 49).

En el siguiente manual se solicita el identificador de reversión de la configuración que se va a restaurar, se revierte la configuración y se confirma, y, a continuación, se imprimen los cambios de configuración en el resultado estándar:

De forma predeterminada, cuando se utiliza el juniper.device.config módulo para modificar la configuración mediante el load argumento o rollback , el módulo realiza automáticamente una comprobación de confirmación y confirma los cambios. Para evitar que el módulo realice una comprobación de confirmación o confirme los cambios, establezca el check argumento o commit en false, respectivamente.

También puede personalizar la operación de confirmación con muchas de las mismas opciones que están disponibles en la CLI de Junos OS. En la tabla 5 se describen los argumentos de módulo que se pueden utilizar para especificar diferentes opciones de confirmación.

Tabla 5: Opciones de confirmación

Argumento del módulo	Descripción	Valor predeterminado para load y rollback operaciones
check: boolean	Realice una comprobación de confirmación o confirme una operación de confirmación confirmada anterior.	true
check_commit_wait: seconds	Espere el número de segundos especificado entre la comprobación de confirmación y la operación de confirmación.	–
comment: "string"	Registre un comentario para esa operación de confirmación en el archivo de registro del sistema y en el historial de confirmaciones del dispositivo.	–
commit: boolean	Confirme los cambios de configuración o confirme una operación de confirmación confirmada anterior.	true
commit_empty_changes: boolean	Confirme los cambios de configuración incluso si no hay diferencias entre la configuración candidata y la configuración confirmada.	false
commit_force_sync: boolean	Sincronice y confirme la configuración en todos los motores de enrutamiento, incluso si hay sesiones de configuración abiertas o cambios de configuración no confirmados en el otro motor de enrutamiento.	false
commit_sync: boolean	Sincronice y confirme la configuración en todos los motores de enrutamiento.	false
confirmed: minutes	Requerir que una operación de confirmación se confirme dentro de un período de tiempo especificado después de la confirmación inicial. Si la confirmación no se confirma en el tiempo especificado, vuelva a la configuración confirmada anteriormente. Se debe utilizar la commit: true opción o la check: true opción para confirmar la confirmación.	–
timeout: seconds	Espere a que finalice la operación utilizando el valor especificado como tiempo de espera.	30 segundos

Confirmar comentario

Cuando confirme la configuración, puede incluir un breve comentario para describir el propósito de los cambios confirmados. Para registrar un comentario que describa los cambios, incluya el comment: "comment string" argumento con la cadena de mensaje.

Confirmar comprobación

De forma predeterminada, el config módulo ejecuta tanto una comprobación de confirmación como una operación de confirmación. El check_commit_wait argumento define el número de segundos que se deben esperar entre las operaciones de comprobación de confirmación y confirmación. Incluya este argumento cuando necesite proporcionar tiempo suficiente para que el dispositivo complete la operación de comprobación de confirmación y suelte el bloqueo de configuración antes de iniciar la operación de confirmación. Si omite el check_commit_wait argumento, puede haber ciertas circunstancias en las que un dispositivo inicie la operación de confirmación antes de que la operación de comprobación de confirmación libere su bloqueo en la configuración, lo que da como resultado una operación de CommitError confirmación fallida.

Confirmar cambios vacíos

De forma predeterminada, si no hay diferencias entre la configuración candidata y la configuración confirmada, el módulo no confirma los cambios. Para forzar una operación de confirmación incluso cuando no haya diferencias, incluya el commit_empty_changes: true argumento.

Confirmar Sincronizar

Si el dispositivo tiene motores de enrutamiento duales, puede sincronizar y confirmar la configuración en ambos motores de enrutamiento incluyendo el commit_sync: true argumento. Para forzar que la commit synchronize operación se realice correctamente incluso si hay sesiones de configuración abiertas o cambios de configuración no confirmados en el otro motor de enrutamiento, utilice el commit_force_sync: true argumento. Cuando se incluye la commit_force_sync: true opción, el dispositivo finaliza cualquier sesión de configuración en el otro motor de enrutamiento antes de sincronizar y confirmar la configuración.

Confirmar Confirmar

Para requerir que una operación de confirmación se confirme dentro de un período de tiempo especificado después de la confirmación inicial, incluya el confirmed: minutes argumento. Si la confirmación no se confirma dentro del límite de tiempo especificado, la configuración se revierte automáticamente a la configuración confirmada anteriormente. El rango permitido es de 1 a 65,535 minutos. La operación de confirmación confirmada es útil para comprobar que un cambio de configuración funciona correctamente y no impide el acceso de administración al dispositivo. Si el cambio impide el acceso o causa otros errores, la reversión automática a la configuración anterior permite el acceso al dispositivo después de que expire la fecha límite de reversión. Para confirmar la operación de confirmación, invoque el config módulo con el check: true argumento o commit: true .

En el siguiente manual, la primera tarea modifica la configuración, espera 10 segundos entre la comprobación de confirmación y la operación de confirmación, y requiere que la operación de confirmación se confirme en 5 minutos. También registra un comentario para la confirmación. La segunda tarea emite una commit check operación para confirmar la confirmación. En un escenario real, puede realizar tareas de validación después de la confirmación inicial y solo ejecutar la confirmación de confirmación si las tareas superan determinados criterios de validación.

El juniper.device.config módulo le permite modificar y confirmar la configuración en dispositivos Junos. En algunos casos, la respuesta RPC puede contener <rpc-error> elementos con un nivel de gravedad de advertencia o superior que hacen que el módulo genere una RpcError excepción. Una RpcError excepción puede provocar un error en la operación de carga o confirmación.

En algunos casos, puede ser necesario o deseable suprimir las RpcError excepciones que se generan en respuesta a las advertencias de operaciones de carga y confirmación. Puede indicar config al módulo que suprima RpcError las excepciones generadas para las advertencias incluyendo el ignore_warning parámetro en la lista de argumentos del módulo. El ignore_warning argumento toma un booleano, una cadena o una lista de cadenas.

Para indicar al módulo que ignore todas las advertencias para las operaciones de carga y confirmación realizadas por el módulo, incluya el ignore_warning: true argumento. En el ejemplo siguiente se omiten todas las advertencias para las operaciones de carga y confirmación.

Si incluye ignore_warning: true y todos los <rpc-error> elementos tienen un nivel de gravedad de advertencia, la aplicación omite todas las advertencias y no genera una RpcError excepción. Sin embargo, cualquier <rpc-error> elemento con niveles de gravedad más altos seguirá generando excepciones.

Para indicar al módulo que ignore advertencias específicas, establezca el ignore_warning argumento en una cadena o en una lista de cadenas que contengan las advertencias que desea omitir. En el ejemplo siguiente se omiten dos advertencias específicas:

El módulo suprime las RpcError excepciones si todos los <rpc-error> elementos tienen un nivel de gravedad de advertencia y cada advertencia en la respuesta coincide con una o más de las cadenas especificadas.