A la luz de las mejoras significativas implementadas en Ansible Engine 2.6, además de tener en cuenta el lanzamiento de Ansible Tower 3.3 y el reciente lanzamiento de Ansible Engine 2.7, echemos un vistazo más de cerca a las perspectivas de la automatización de la red.
En este post:
- Complemento de conexión Httpapi.
- Soporte para Arista eAPI y Cisco NX-API.
- Nuevos módulos de automatización de redes.
- net_get y net_put.
- netconf_get, netconf_rpc y netconf_config.
- cli_command y cli_config.
- Interfaz web mejorada de Ansible Tower.
- Administre las credenciales en Ansible Tower cuando trabaje con dispositivos de red.
- Usando diferentes versiones de Ansible en Tower al mismo tiempo
No olvide que el lanzamiento de cada nueva versión de Ansible va acompañado de una actualización
de la guía de portabilidad , lo que facilitará en gran medida la transición a la nueva versión.
Complemento de conexión HTTPAPI
Los complementos de conexión son los que permiten a Ansible conectarse a los hosts de destino y luego realizar tareas en ellos. Comenzando con Ansible 2.5, ha aparecido un nuevo complemento de este tipo llamado network_cli. Elimina la necesidad de usar el parámetro del proveedor y estandariza el orden de ejecución de los módulos de red, como resultado de lo cual los libros de jugadas para dispositivos de red ahora se ejecutan, ejecutan y funcionan de la misma manera que los libros de jugadas para hosts Linux. A su vez, para Ansible Tower, la diferencia entre dispositivos de red y hosts desaparece, y ya no es necesario distinguir entre nombres de usuario y contraseñas para dispositivos de red y máquinas. Esto se discutió con más detalle
aquí , pero en resumen, las contraseñas de inicio de sesión para el servidor Linux y el enrutador Arista EOS o Cisco ahora se pueden usar y almacenar de manera similar.
En Ansible 2.5, la conexión a través de los métodos eAPI y NX-API solo era posible utilizando el método del proveedor anterior. Ansible 2.6 ya no tiene esta limitación y puede utilizar libremente el método de conexión httpapi de alto nivel. Veamos cómo se hace esto.
Primero debe habilitar eAPI o NX-API en el dispositivo de red para poder usar el método httpapi. Esto se hace fácilmente con el comando Ansible apropiado, por ejemplo, aquí se explica cómo habilitar eAPI en un conmutador Arista EOS.
[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] }
Cuando se conecta a un verdadero conmutador Arista EOS, el comando show management api http-command mostrará que la API está habilitada:
leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>>
El script de Ansible Playbook a continuación simplemente ejecuta el comando show version, y luego en la sección de depuración solo devuelve la versión del resultado JSON de la tarea.
--- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]
La ejecución de este script dará como resultado el siguiente resultado:
[user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0
NOTA: Arista eAPI no admite versiones abreviadas de comandos (como "show ver" en lugar de "show version2), por lo que debe escribirlos todos. Para obtener más información sobre el complemento de conexión httpapi, consulte la documentación.
Nuevos módulos de automatización de red.
Ansible 2.6 y la versión 2.7 lanzada en octubre ofrecen siete nuevos módulos para la automatización de redes.
- net_get : copia un archivo de un dispositivo de red a Ansible Controller.
- net_put - Copia un archivo de Ansible Controller a un dispositivo de red.
- netconf_get - Recupera datos de configuración / estado de un dispositivo de red con NETCONF habilitado.
- netconf_rpc : realiza operaciones en un dispositivo de red con NETCONF habilitado.
- netconf_config : configuración del dispositivo netconf , el módulo permite al usuario enviar un archivo XML a los dispositivos netconf y verificar si la configuración ha cambiado.
- cli_command : ejecuta el comando cli en dispositivos de red que tienen una interfaz de comando (cli).
- cli_config : envía la configuración de texto (push) a los dispositivos de red a través de network_cli.
net_get y net_put
Los módulos net_get y net_put no están vinculados al equipo de ningún fabricante en particular y simplemente copian archivos del dispositivo de red a dispositivos que utilizan protocolos de transferencia estándar SCP o SFTP (especificados por el parámetro de protocolo). Ambos módulos requieren el uso del método de conexión network_cli y también funcionan solo si scp (pip install scp) está instalado en el controlador y SCP o SFTP está habilitado en el dispositivo de red.
Suponemos que en el ejemplo con nuestro libro de jugadas, ya hemos ejecutado el siguiente comando en el dispositivo Leaf01:
leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.
Así es como se ve un libro de jugadas con dos tareas (la primera copia el archivo del dispositivo Leaf01 y la segunda copia el archivo al dispositivo Leaf01):
--- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt
netconf_get, netconf_rpc y netconf_config
- netconf_get - Recupera datos de configuración / estado de un dispositivo de red con NETCONF habilitado.
- netconf_rpc : realiza operaciones en un dispositivo de red con NETCONF habilitado.
- netconf_config : configuración del dispositivo netconf , el módulo permite al usuario enviar un archivo XML a los dispositivos netconf y verificar si la configuración ha cambiado.
Protocolo de administración de red NETCONF (Protocolo de configuración de red) está desarrollado y estandarizado por el IETF. De acuerdo con RFC 6241, NETCONF se puede utilizar para instalar, manipular y eliminar configuraciones de dispositivos de red. NETCONF es una alternativa a la línea de comando SSH (network_cli) y API como Cisco NX-API o Arista eAPI (httpapi).
Para demostrar los nuevos módulos netconf, primero habilitamos netconf en los enrutadores Juniper utilizando el módulo
junos_netconf . Netconf no es compatible con todos los modelos de equipos de red, así que revise su documentación antes de usarlo.
[user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] }
Juniper Networks ofrece el Explorador de API XML de Junos para
etiquetas operativas y para
etiquetas de configuración . Considere el ejemplo de la solicitud operativa que Juniper Networks utiliza en su
documentación para ilustrar la solicitud RPC de una interfaz específica.
<rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>
Se traduce fácilmente en Ansible Playbook. get-interface-information es una llamada RPC, y los parámetros adicionales se especifican como pares clave-valor. En este ejemplo, solo hay un parámetro, nombre de interfaz, y en nuestro dispositivo de red solo queremos ver em1.0. Usamos el parámetro de registro que se configuró para la tarea, solo para guardar los resultados, por lo que usamos el módulo de depuración y mostramos los resultados en la pantalla del terminal. El módulo netconf_rpc también le permite traducir la salida XML directamente a JSON.
--- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info
Después de comenzar el libro de jugadas, obtenemos esto:
ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>>
Para obtener más información, consulte la
Guía de la plataforma Juniper y la
documentación de NETCONF .
cli_command y cli_config
- cli_command : ejecuta un comando en dispositivos de red utilizando su interfaz de línea de comando (si hay uno).
- cli_config : envía la configuración de texto (push) a los dispositivos de red a través de network_cli.
Los módulos cli_command y cli_config que aparecieron en Ansible Engine 2.7 tampoco están vinculados al equipo de un fabricante en particular y pueden usarse para automatizar varias plataformas de red. Se basan en el valor de la variable ansible_network_os (establecida en el archivo de inventario o en la carpeta group_vars) para usar el complemento cliconf deseado. En la
documentación se proporciona una lista de todos los valores de la variable ansible_network_os. En esta versión de Ansible, aún puede usar los módulos antiguos para plataformas específicas, así que tómese su tiempo para reescribir los libros de jugadas existentes. Para obtener más información, consulte las
guías oficiales de portabilidad .
Veamos cómo se usan estos módulos en Ansible Playbook. Este libro de jugadas se ejecutará en dos sistemas de enrutadores de servicios en la nube (CSR) de Cisco que ejecutan IOS-XE. La variable ansible_network_os en el archivo de inventario se establece en ios.
<config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios
Así es como se usan cli_config y cli_command:
--- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout
Y aquí está el resultado de este libro de jugadas:
[user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0
Tenga en cuenta que estos módulos son
idempotentes siempre que utilice la sintaxis adecuada para los dispositivos de red correspondientes.
Interfaz de torre Ansible mejorada
La interfaz web en Red Hat Ansible Tower 3.3 se ha vuelto más conveniente y funcional, permitiendo menos clics al realizar diversas tareas.
La gestión de credenciales, el programador de tareas, las secuencias de comandos de inventario, el control de acceso basado en roles, las notificaciones y mucho más ahora se recopilan en el menú principal en el lado izquierdo de la pantalla y están disponibles con un solo clic. La pantalla de visualización de trabajos Vista de trabajos muestra inmediatamente información adicional importante: quién inició la tarea y cuándo; qué inventario se desarrolló durante su implementación; de qué proyecto fue tomado el libro de jugadas.
Gestionar credenciales para dispositivos de red en Ansible Tower
Red Hat Ansible Tower 3.3 hace que sea mucho más fácil administrar contraseñas de inicio de sesión para dispositivos de red. En la nueva interfaz web, el comando Credenciales se encuentra inmediatamente en el menú principal, en el grupo Recursos.
Ansible Tower 3.3 dejó un tipo de credencial especial llamada "red" (Red), que establece las variables de entorno ANSIBLE_NET_USERNAME y ANSIBLE_NET_PASSWORD utilizadas en el antiguo método de proveedor. Todo esto aún funciona, tal como está escrito en la
documentación , para que pueda usar los scripts existentes de Ansible Playbooks. Sin embargo, para los nuevos métodos de alto nivel de conexión de httpapi y network_cli, el tipo de credencial de la red ya no es necesario, ya que ahora Ansible funciona igualmente con inicios de sesión de contraseña como con conectarse a dispositivos de red, y así cuando se conecta a hosts de Linxu. Por lo tanto, para dispositivos de red, ahora debe seleccionar el tipo de credencial de la máquina; simplemente selecciónelo e ingrese su contraseña de inicio de sesión o proporcione una clave SSH.
NOTA: Ansible Tower cifra la contraseña inmediatamente después de guardar las credenciales.
Gracias al cifrado, las credenciales se pueden delegar de forma segura a otros usuarios y grupos; simplemente no verán ni reconocerán la contraseña. Para obtener más información sobre cómo funcionan las credenciales, qué cifrado se utiliza y qué otros tipos de credenciales (como Amazon AWS, Microsoft Azure y Google GCE) se pueden encontrar en la
documentación de Ansible Tower .
Una descripción más detallada de Red Hat Ansible Tower 3.3 se puede encontrar
aquí .
Usando diferentes versiones de Ansible en Tower al mismo tiempo
Supongamos que queremos que algunos libros de jugadas se ejecuten a través de Ansible Engine 2.4.2, y otros a través de Ansible Engine 2.6.4. Tower tiene una herramienta especial virtualenv para crear entornos limitados de Python para evitar conflictos con dependencias conflictivas y diferentes versiones. Ansible Tower 3.3 le permite configurar virtualenv en diferentes niveles: organización, proyecto o plantilla de trabajo. Así es como se ve la Plantilla de trabajo que creamos en Ansible Tower para respaldar nuestra red.
Cuando tiene al menos dos entornos virtuales, el menú emergente Entorno Ansible aparece en el menú principal de Ansible Tower, donde puede especificar fácilmente qué versión de Ansible se debe usar al realizar la tarea.
Por lo tanto, si tiene una combinación de libros de jugadas para la automatización de la red, algunos de los cuales usan el método del proveedor anterior (Ansible 2.4 y versiones anteriores), y algunos usan los nuevos complementos httpapi o network_cli (Ansible 2.5 y superior), puede asignar fácilmente cada tarea Versión Ansible Además, esta característica será útil si los desarrolladores y la producción usan diferentes versiones de Ansible. En otras palabras, puede actualizar la Torre de forma segura, sin preocuparse de que después de eso tendrá que cambiar a cualquier versión de Ansible Engine, lo que aumenta enormemente la flexibilidad para automatizar diversos tipos de equipos y entornos de red, así como los casos de uso.
Para obtener más información sobre el uso de virtualenv, consulte la
documentación .