Utilice el ejemplo de roles de red de Ansible

Los roles son conjuntos de valores predeterminados de Ansible, archivos, tareas, plantillas, variables y otros componentes de Ansible que funcionan juntos. Como viste en Ejecute su primer comando y manual de estrategias, pasar de un comando a un libro de jugadas facilita la ejecución de varias tareas y la repetición de las mismas en el mismo orden. Pasar de un libro de jugadas a un rol hace que sea aún más fácil reutilizar y compartir las tareas ordenadas. Puedes mirar Ansible Galaxy, que le permite compartir sus roles y utilizar los roles de otros, ya sea directamente o como inspiración.

• Un ejemplo de libro de jugadas de DNS
• Convierta el libro de jugadas en un rol

• Precedencia variable

  • Precedencia más baja
  • Precedencia más alta
• Actualizar un rol instalado

Entender los roles

Entonces, ¿qué es exactamente un rol y por qué debería preocuparte? Los roles de Ansible son básicamente libros de jugadas divididos en una estructura de archivo conocida. Pasar a roles desde un libro de jugadas facilita compartir, leer y actualizar su flujo de trabajo de Ansible. Los usuarios pueden escribir sus propios roles. Entonces, por ejemplo, no tiene que escribir su propio libro de jugadas de DNS. En su lugar, especifica un servidor DNS y un rol para configurarlo por usted.

Para simplificar aún más su flujo de trabajo, el equipo de Ansible Network ha escrito una serie de roles para casos de uso de redes comunes. Usar estos roles significa que no tienes que reinventar la rueda. En lugar de escribir y mantener el tuyo create_vlan manuales o roles, puede concentrarse en diseñar, codificar y mantener las plantillas del analizador que describen su inventario y topologías de red, y dejar que los roles de red de Ansible hagan el trabajo. Ver el roles relacionados con la red en Ansible Galaxy.

Un ejemplo de libro de jugadas de DNS

Para demostrar el concepto de lo que es un rol, el ejemplo playbook.yml a continuación se muestra un solo archivo YAML que contiene un libro de estrategias de dos tareas. Este Ansible Playbook configura el nombre de host en un dispositivo Cisco IOS XE, luego configura los servidores DNS (sistema de nombres de dominio).

----name: configure cisco routers
  hosts: routers
  connection: ansible.netcommon.network_cli
  gather_facts: no
  vars:dns:"8.8.8.8 8.8.4.4"tasks:-name: configure hostname
     cisco.ios.ios_config:lines: hostname  inventory_hostname -name: configure DNS
     cisco.ios.ios_config:lines: ip name-server dns

Si ejecuta este libro de jugadas con el ansible-playbook comando, verá el resultado a continuación. Este ejemplo usó -l opción para limitar el libro de jugadas a ejecutar solo en el rtr1 nodo.

[[email protected] ~]$ ansible-playbook playbook.yml -l rtr1

PLAY [configure cisco routers] *************************************************

TASK [configure hostname] ******************************************************
changed: [rtr1]

TASK [configure DNS] ***********************************************************
changed: [rtr1]

PLAY RECAP *********************************************************************
rtr1                       :ok=2changed=2unreachable=0failed=0

Este libro de jugadas configuró el nombre de host y los servidores DNS. Puede verificar esa configuración en Cisco IOS XE rtr1 enrutador:

rtr1#sh run | i namehostname rtr1
ip name-server 8.8.8.8 8.8.4.4

Convierta el libro de jugadas en un rol

El siguiente paso es convertir este manual en una función reutilizable. Puede crear la estructura del directorio manualmente o puede utilizar ansible-galaxy init para crear el marco estándar para un rol.

[[email protected] ~]$ ansible-galaxy init system-demo
[[email protected] ~]$ cd system-demo/
[[email protected] system-demo]$ tree
.
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
  └── main.yml

Esta primera demostración utiliza solo el Tareas y vars directorios. La estructura del directorio se vería de la siguiente manera:

[[email protected] system-demo]$ tree
.
├── tasks
│   └── main.yml
└── vars
    └── main.yml

A continuación, mueva el contenido del vars y tasks secciones del libro de jugadas original de Ansible en el papel. Primero, mueva las dos tareas al tasks/main.yml expediente:

[[email protected] system-demo]$ cat tasks/main.yml
---
- name: configure hostname
  cisco.ios.ios_config:
    lines: hostname inventory_hostname 

- name: configure DNS
  cisco.ios.ios_config:
    lines: ip name-server dns

A continuación, mueva las variables al vars/main.yml expediente:

[[email protected] system-demo]$ cat vars/main.yml
---
dns: "8.8.8.8 8.8.4.4"

Finalmente, modifique el libro de jugadas original de Ansible para eliminar el tasks y vars secciones y agregue la palabra clave roles con el nombre del rol, en este caso system-demo. Tendrás este libro de jugadas:

----name: configure cisco routers
  hosts: routers
  connection: ansible.netcommon.network_cli
  gather_facts: no

  roles:- system-demo

En resumen, esta demostración ahora tiene un total de tres directorios y tres archivos YAML. Ahí está el system-demo carpeta, que representa el rol. Esta system-demo contiene dos carpetas, tasks y vars. Hay un main.yml es cada carpeta respectiva. los vars/main.yml contiene las variables de playbook.yml. los tasks/main.yml contiene las tareas de playbook.yml. los playbook.yml El archivo se ha modificado para llamar al rol en lugar de especificar vars y tareas directamente. Aquí hay un árbol del directorio de trabajo actual:

[[email protected] ~]$ tree
.
├── playbook.yml
└── system-demo
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

Ejecutar el libro de jugadas da como resultado un comportamiento idéntico con una salida ligeramente diferente:

[[email protected] ~]$ ansible-playbook playbook.yml -l rtr1

PLAY [configure cisco routers] *************************************************

TASK [system-demo : configure hostname] ****************************************
ok: [rtr1]

TASK [system-demo : configure DNS] *********************************************
ok: [rtr1]

PLAY RECAP *********************************************************************
rtr1             :ok=2changed=0unreachable=0failed=0

Como se vio arriba, cada tarea ahora se antepone con el nombre del rol, en este caso system-demo. Al ejecutar un libro de jugadas que contiene varios roles, esto ayudará a identificar desde dónde se llama una tarea. Este libro de jugadas volvió ok en lugar de changed porque tiene un comportamiento idéntico para el libro de jugadas de un solo archivo desde el que comenzamos.

Como antes, el libro de jugadas generará la siguiente configuración en un enrutador Cisco IOS-XE:

rtr1#sh run | i name
hostname rtr1
ip name-server 8.8.8.8 8.8.4.4

Es por eso que los roles de Ansible pueden considerarse simplemente como libros de jugadas deconstruidos. Son simples, efectivos y reutilizables. Ahora otro usuario puede simplemente incluir el system-demo papel en lugar de tener que crear un libro de jugadas personalizado “codificado”.

Precedencia variable

¿Qué pasa si desea cambiar los servidores DNS? No se espera que cambie el vars/main.yml dentro de la estructura de roles. Ansible tiene muchos lugares donde puede especificar variables para una obra determinada. Ver Usando Variables para obtener detalles sobre las variables y la precedencia. En realidad, hay 21 lugares para colocar variables. Si bien esta lista puede parecer abrumadora a primera vista, la gran mayoría de los casos de uso solo implican conocer el lugar para las variables de menor precedencia y cómo pasar las variables con mayor precedencia. Ver Precedencia de variables: ¿Dónde debo poner una variable? para obtener más orientación sobre dónde debe colocar las variables.

Precedencia más baja

La precedencia más baja es la defaults directorio dentro de un rol. Esto significa que todas las otras 20 ubicaciones en las que podría especificar potencialmente la variable tendrán mayor prioridad que defaults, no importa qué. Para dar inmediatamente las vars de la system-demo rol de la menor precedencia, renombrar el vars directorio a defaults.

[[email protected] system-demo]$ mv vars defaults
[[email protected] system-demo]$ tree
.
├── defaults
│   └── main.yml
├── tasks
│   └── main.yml

Agregar una nueva vars sección del libro de jugadas para anular el comportamiento predeterminado (donde la variable dns está configurado en 8.8.8.8 y 8.8.4.4). Para esta demostración, configure dns a 1.1.1.1, entonces playbook.yml se convierte en:

---
- name: configure cisco routers
  hosts: routers
  connection: ansible.netcommon.network_cli
  gather_facts: no
  vars:
    dns: 1.1.1.1
  roles:
    - system-demo

Ejecute este manual actualizado en rtr2:

[[email protected] ~]$ ansible-playbook playbook.yml -l rtr2

La configuración en el rtr2 El enrutador Cisco se verá de la siguiente manera:

rtr2#sh run | i name-server
ip name-server 1.1.1.1

La variable configurada en el libro de jugadas ahora tiene prioridad sobre la defaults directorio. De hecho, cualquier otro lugar que configure las variables ganaría los valores en el defaults directorio.

Precedencia más alta

Especificando variables en el defaults directorio dentro de un rol siempre tendrá la prioridad más baja, mientras se especifica vars como vars extra con el -e o --extra-vars= siempre tendrá la mayor prioridad, pase lo que pase. Volver a ejecutar el libro de jugadas con el -e opción anula tanto la defaults directorio (8.8.4.4 y 8.8.8.8) así como el recién creado vars dentro del libro de jugadas que contiene el servidor DNS 1.1.1.1.

[[email protected] ~]$ ansible-playbook playbook.yml -e "dns=192.168.1.1" -l rtr3

El resultado en el enrutador Cisco IOS XE solo contendrá la configuración de precedencia más alta de 192.168.1.1:

rtr3#sh run | i name-server
ip name-server 192.168.1.1

¿Cómo es esto útil? ¿Por qué debería preocuparte? Los operadores de red suelen utilizar vars adicionales para anular los valores predeterminados. Un poderoso ejemplo de esto es con Red Hat Ansible Tower y la función de encuesta. Es posible a través de la interfaz de usuario web solicitar a un operador de red que complete los parámetros con un formulario web. Esto puede ser realmente simple para los escritores de libros de jugadas sin conocimientos técnicos para ejecutar un libro de jugadas usando su navegador web. Ver Encuestas de plantillas de trabajos de Ansible Tower para más detalles.

Actualizar un rol instalado

La página de Ansible Galaxy para un rol enumera todas las versiones disponibles. Para actualizar un rol instalado localmente a una versión nueva o diferente, use el ansible-galaxy install comando con la versión y --force opción. Es posible que también deba actualizar manualmente los roles dependientes para admitir esta versión. Ver el rol Léame pestaña en Galaxy para conocer los requisitos mínimos de versión de la función dependiente.

[[email protected]]$ ansible-galaxy install mynamespace.my_role,v2.7.1 --force

Ver también

Documentación de Ansible Galaxy

Guía del usuario de Ansible Galaxy