Estos son muy poderosos no solo para declarar configuraciones de servidor, sino también para orquestar pasos de cualquier proceso ordenado manual, incluso cuando los diferentes pasos deben ir y venir entre conjuntos de máquinas en cualquier orden, ya que los libros de jugadas pueden iniciar tareas de forma sincrónica o asincrónica según sea necesario. Si bien es adecuado usar el programa /usr/bin/ansible para tareas y comandos ad-hoc. Los libros de jugadas se mantienen mejor en control de fuente y se utilizan para impulsar configuraciones más grandes, o asegurar que las configuraciones de sus sistemas remotos aún estén bajo control.
1 – Ejemplos de libros de jugadas
Estos son algunos ejemplos iniciales de playbooks de Ansible. Un libro de jugadas, por definición, se compone de una o más jugadas en una lista.
1 – Ejemplos de Playbook2 – Anfitriones y usuarios de Playbook3 – Tareas de Playbook4 – Manejadores de Playbook5 – Ejecución de Playbooks7 – Ansible Templating8 – Roles en Playbooks
El objetivo de cada juego es asignar un grupo de hosts a algún rol bien definido, a través de acciones dentro del juego que Ansible llama tareas. Sin embargo, en pocas palabras, una tarea no es más que una llamada a un módulo Ansible preestablecido. Al componer un libro de jugadas de múltiples ‘jugadas’, es posible orquestar implementaciones de múltiples máquinas. Ejecutar ciertos pasos en todas las máquinas en el grupo de “servidores web”, luego ciertos pasos en el grupo de servidores de “bases de datos”, y luego más comandos en el grupo de “servidores web”, etc. El primer fragmento y libro de jugadas configura el servidor web Apache en los hosts del grupo de servidores web. Observe las variables declaradas, el usuario remoto en uso y los controladores hacia el final. Este segundo ejemplo usa tareas que tienen parámetros muy largos y módulos que toman muchos parámetros. Cuando este sea el caso, puede dividir los elementos de las tareas en varias líneas para mejorar la legibilidad y la estructura del libro de jugadas. La división de tareas se logra mediante el uso de diccionarios YAML para proporcionar a los módulos sus argumentos clave=valor . Este ejemplo final contiene no solo una sino dos jugadas. El primero se dirige al grupo de host de servidores web y el segundo se dirige al grupo de host de bases de datos. Consulte el repositorio ansible/ansible-examples de GitHub para ver algunos ejemplos de configuración de Playbook completos y correctamente estructurados.
2 – Anfitriones y usuarios del libro de jugadas
Para cada “juego” en un libro de jugadas, puede elegir los servidores/hosts en su infraestructura a los que desea apuntar, y qué usuario remoto de Linux completará los pasos en el juego como (recuerde que los pasos se llaman tareas). La línea de anfitriones al comienzo de una obra es una lista de uno o más grupos o, si es necesario, un patrón de anfitriones. El usuario_remoto contiene el nombre de la cuenta de usuario objetivo de Linux/Unix. Los usuarios remotos también se pueden configurar por tarea en lugar de solo para todo el juego. Como en este ejemplo, donde la conexión de prueba de tarea usa un usuario diferente al juego general. Los elementos become y become_method permiten un cambio de privilegios desde dentro de la sesión del usuario de SSH. Esto es útil para usar programas shell como sudo para tareas que necesitan mayores privilegios. En estos casos, debe proporcionar la contraseña necesaria usando –ask-become-pass al ejecutar el libro de jugadas con ansible-playbook desde la línea de comandos, que se tratará más adelante. El uso de become_user permite de manera similar un cambio de usuario desde la sesión de shell de usuario de SSH del juego. Veamos más las tareas en sí mismas y lo que pueden hacer.
3 – Tareas del libro de jugadas
Como se ve, cada jugada contiene su propia lista de tareas. Las tareas se ejecutan en orden, una a la vez, en todas las máquinas que coinciden con el patrón o grupo de host. Así que tenga en cuenta que todos los hosts van a recibir y procesar las mismas directivas de tareas emitidas. Además, cuando se ejecuta un libro de jugadas, los hosts que terminan con tareas fallidas se eliminan de la rotación durante toda la ejecución del libro de jugadas. Si las cosas fallan, simplemente corrija el archivo del libro de jugadas (o el problema de conectividad del host) y vuelva a ejecutarlo. Como se vio en la primera sección de esta publicación, el objetivo de cada tarea es ejecutar un módulo, con variables establecidas pasadas a ese módulo si es necesario. Aquí hay un ejemplo omitido: Es importante destacar que el uso del módulo también debe ser “idempotente”. Es decir, al ejecutar un módulo varias veces en una secuencia, debería tener el mismo resultado final que si lo hubiera ejecutado solo una vez. Una forma de lograr este estado de idem-potencia en los libros de jugadas es hacer que un módulo verifique si ya se logró el estado final deseado y, si se logró ese estado, para salir sin realizar ninguna acción. Entonces, si todos los módulos que usa un libro de jugadas son idempotentes, es probable que el libro de jugadas también sea idempotente (en general), por lo que volver a ejecutar el libro de jugadas varias veces debería ser seguro y no crear ningún problema. Nota: los módulos de comando y shell generalmente volverán a ejecutar el mismo comando emitido nuevamente, lo cual está bien si el comando es algo que no cambia el resultado de su ejecución inicial cuando se ejecuta varias veces. También hay un indicador de “crear” disponible aquí que se puede usar para hacer que estos dos módulos sean idempotentes. Además, cada tarea debe tener un nombre, que se incluye en el resultado de ejecutar el libro de jugadas y sirve más como una descripción que como un apodo. Debido a esto, es útil proporcionar buenas descripciones para cada paso de la tarea. Al igual que con la mayoría de los módulos, el servicio del módulo toma argumentos en el formato clave=valor. Los módulos de comando y shell son los únicos módulos que toman una lista de argumentos y no usan la forma clave = valor como de costumbre. Esto hace que funcionen de la misma manera que esperaría que lo hicieran en la línea de comandos, p. El comando y el módulo de shell se preocupan por los códigos de retorno, por lo que si tiene un comando en el que el código de salida exitoso no es cero, puede modificarlo a esto: Si la línea de acción del módulo es demasiado larga, puede dividirla en un carácter de espacio y sangrar las líneas continuas para mejorar la legibilidad. Las variables declaradas se pueden usar explícitamente en las líneas de acción de la tarea, no solo en plantillas (plantillas aún no cubiertas). La variable se llama usando la palabra vhost dentro de las llaves, en el siguiente ejemplo: Continuar con el concepto y la práctica presentados aquí de idem-potencia en Ansible. La siguiente sección habla sobre los controladores.
4 – Manejadores de libros de jugadas
Los módulos deben ser idempotentes como se describe en la última sección, para que puedan transmitir si han realizado un cambio en el sistema remoto o no. Los libros de jugadas tienen la capacidad de reconocer estos cambios y también tienen un sistema de eventos básico que se puede usar para responder al cambio. Las acciones de notificación se activan al final de cada bloque de tareas en un juego y solo se activarán una vez. Incluso si se notifica y desencadena por múltiples tareas diferentes. Por ejemplo, varios recursos pueden indicar que es necesario reiniciar Apache porque han cambiado un archivo de configuración, pero Apache solo se reiniciará una vez para evitar múltiples reinicios innecesarios. Este es un ejemplo de cómo reiniciar dos servicios en una tarea cuando cambia el contenido de un archivo, pero solo si el archivo cambia. Los elementos enumerados en la sección de notificación de la tarea se denominan controladores. Los controladores son listas de tareas (no muy diferentes de las tareas normales) a las que se hace referencia mediante un nombre único global y notificadores. Si nunca se hace referencia/notifica a un controlador, no se ejecutará. Como se infirió anteriormente, independientemente de cuántas tareas notifiquen a un controlador, se ejecutará solo una vez y después de que todas las tareas se completen en una jugada en particular. Aquí hay un ejemplo de una sección de controladores con algunas tareas definidas:
5 – Libros de jugadas para correr
Ahora que ha aprendido gran parte del trabajo básico para la sintaxis del libro de jugadas, deberíamos ver cómo ejecutar un libro de jugadas completo. Para ejecutar un libro de jugadas, use el comando anisble-playbook seguido de la ruta al archivo del libro de jugadas. En este escenario, está en el directorio de trabajo actual y se llama playbook.yml. El -f 10 especifica el uso de 10 procesos Ansible simultáneos a la vez. Al ejecutar un libro de jugadas, siempre habrá un resumen de los nodos/hosts a los que se dirigieron y cómo les fue con las instrucciones. Las fallas generales y los intentos fatales inalcanzables por la ejecución del libro de jugadas se mantienen separados en los “recuentos”. La marca –verbose etiquetada en el comando ansible-playbook da como resultado una cuenta más detallada de los resultados de una ejecución del libro de jugadas. Además, el indicador –list-hosts muestra qué hosts se verán afectados por un libro de jugadas antes de ejecutarlo. Es posible invertir la arquitectura de Ansible, obligando a los nodos/hosts a registrarse en una ubicación central en lugar de enviar la configuración externamente, mediante el script ansible-pull . Ejecute la opción de ayuda para ver detalles sobre esto si está interesado. Aparte, algunos dicen que la salida del libro de jugadas de Ansible se actualiza enormemente si el paquete cowsay está instalado en su sistema.
7 – Plantillas Ansible
Las plantillas en Ansible se construyen utilizando el lenguaje de plantillas Jinja2 Python y residen en sus propios archivos. Son capaces de hacer referencia a variables de fuentes externas, como desde dentro del libro de jugadas utilizando la plantilla y el inventario de archivos Ansible externo, p. un archivo main.yml dentro de un directorio superior /vars . Las plantillas suelen ser útiles para configurar archivos de configuración, para que ellos y otros archivos sean más versátiles o reutilizables entre los libros de jugadas. Pueden tener cualquier nombre de archivo, pero las extensiones .tpl o .j2 son comunes. A continuación se muestra un ejemplo de plantilla para configurar un servidor virtual Apache. Utiliza una variable para configurar la raíz del documento en cada host de Ansible: La plantilla del módulo integrado: se utiliza para aplicar un archivo de plantilla en una tarea. Por ejemplo, si nombró un archivo de plantilla vhost.tpl y lo colocó dentro del mismo directorio que su libro de jugadas, así es como usaría la plantilla para reemplazar el host virtual Apache predeterminado, en sus hosts de Ansible:
8 – Roles en los libros de jugadas
Los roles funcionan mejor para libros de jugadas más complejos que tienen muchas tareas múltiples pero relacionadas. Cada rol contiene solo los datos e información relevantes necesarios para llevar a cabo dichas tareas. Como generalmente hay varias etapas en una tarea o conjunto de tareas, los libros de jugadas pueden volverse muy largos y congestionados con todas sus operaciones. Por lo tanto, limitar las tareas a los roles ayuda a aliviar este problema. Como ejemplo, un libro de jugadas que instala Nginx probablemente implica agregar el repositorio de paquetes estables, luego instalar el paquete en sí, así como configurar toda la configuración para el servidor web. Sin duda, el paso final de configuración requiere datos adicionales, como variables, archivos, plantillas dinámicas y más. Estos se mantienen en el área de su propio rol. El sistema de archivos para un rol se parece al siguiente, donde rolname es el directorio raíz y las opciones son las áreas de directorio subsiguientes para cada información. Dentro de cada una de las áreas de directorio individuales anteriores, Ansible buscará un archivo main.yml automáticamente. Cualquier pieza de configuración para el rol en cuestión está contenida dentro de estas ubicaciones. Después de entender cómo cada uno de estos diferentes conceptos funcionan juntos para crear un libro de jugadas. Puede continuar creando el suyo propio desde cero, a partir de otros ejemplos o convirtiendo sus scripts de configuración anteriores.
