¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Ansible
  3. Funcionamiento de un playbook
Extrait - Ansible Administre la configuración de sus servidores y el despliegue de sus aplicaciones
Extractos del libro
Ansible Administre la configuración de sus servidores y el despliegue de sus aplicaciones Volver a la página de compra del libro

Funcionamiento de un playbook

Objetivos del capítulo y requisitos

1. Contexto y requisitos

Si ha llegado a este capítulo del libro, ya debe haber estudiado los puntos siguientes: 

  • Configurar la comunicación con las máquinas remotas (clave SSH).

  • Tener nociones sobre el funcionamiento de los inventarios.

  • Tener algunas nociones sobre el uso de estos últimos.

  • Haber visto cómo funciona un playbook simple.

En este capítulo se retomarán estos elementos y se irá más lejos en la comprensión de Ansible.

2. Archivos descargables

Puede encontrar los ejemplos de los directorios inventarios y variables en el archivo comprimido capitulo-06.tar.gz que se encuentra en la página del libro del sitio de Ediciones ENI.

El motor de plantillas Jinja: principio de funcionamiento

A través de los ejemplos que verá a continuación, usted estudiará cómo usar Ansible para obtener datos que caracterizan las máquinas con el objetivo de catalogarlas. Para ello necesitará estudiar el funcionamiento del motor Jinja.

Jinja es un motor de plantillas escrito en Python. Está inspirado en el motor Django, pero es más fácil de utilizar. El principio es el siguiente: un esquema contendrá todo el diseño. Jinja cargará este patrón y realizará la sustitución de los campos en función del contexto de ejecución.

Este tipo de herramienta se utiliza para mostrar información en una página web en función de variables (información sobre un usuario, mostrar la fecha del día, etc.). Para comprender bien cómo funciona este tipo de motor, tome el caso de una página HTML que presenta el nombre de una máquina:

<html> 
 <head> 
   <title>Máquina rec-apache-1</title> 
 </head> 
 <body> 
   <p>Esta máquina se llama rec-apache-1</p> 
 </body> 
</html> 

Encontrará el nombre de la máquina en dos sitios distintos: en la etiqueta título de la página (etiqueta <title>...</title>) y en el párrafo (etiqueta <p>...</p>) del cuerpo de la página (etiqueta <body>...</body>).

Imagine ahora que el nombre de la máquina esté guardado en la variable inventory_hostname. Para que la página de antes sea genérica, solamente tendrá...

Plantilla Jinja

Ha estudiado un mecanismo simple que permite generar archivos en la máquina local tomando como punto de partida datos del inventario. Ahora verá cómo usar datos recuperados por el módulo setup (campo gather_facts de los playbooks). Después utilizará estas variables en la generación del modelo. 

Para ello, debe tratar los siguientes puntos:

  • Saber realizar un bucle con un template Jinja.

  • Encontrar la variable Ansible recuperada por el módulo setup que contiene lo que necesita.

  • Comprender cómo ejecutar los módulos en las ubicaciones correctas con la opción connection.

1. Mecanismo de bucle en una tabla con Jinja

En Jinja, un bucle se declara con los siguientes elementos:

  • la palabra clave for;

  • el nombre de la variable de la iteración;

  • la palabra clave in;

  • la tabla que quiere recorrer.

He aquí un ejemplo de este tipo de bucle:

{% for elemento in lista_elemento %} 
El contenido de la variable elemento es el siguiente: {{elemento}} 
{% endfor %} 

Aquí la variable lista_elemento será una tabla de elementos. Cada elemento generará una línea.

Como ha visto anteriormente, puede utilizar tablas de hash, además de las tablas normales. En este caso, necesitará:

  • hacer una llamada a la función items de la tabla de hash;

  • remplazar la variable de iteración simple por la pareja de variables clave/valor.

He aquí un ejemplo simple de este tipo de declaración:

{% for clave, valor in claves_valores.items() %} 
La clave contiene {{clave}}...

Delegación de la tarea

Queriendo recuperar datos de las diferentes máquinas, se han recuperado en realidad datos de la máquina que ha iniciado Ansible.

No se preocupe; se podrán recuperar datos de las máquinas remotas antes de utilizarlos localmente. Para ello, debe tratar la noción de plugin de conexión (ssh o local) así como la delegación (opción delegate_to).

1. Cambio de tipo de conexión en una tarea

Volvamos al error que ha experimentado en la lista de las direcciones IP. Este error es muy simple y viene del campo connection: local que posicionó a nivel global del playbook. En realidad, usted hubiera preferido que la operación gather_facts se hiciera en las diferentes máquinas del inventario y que solo el archivo se guardara en local.

 En ese caso, simplemente debe mover el campo connection del playbook anterior al nivel de la instrucción template y dejar que el resto se haga con los valores por defecto (en este caso, será SSH). Aplicando estas modificaciones, el código debería parecerse a esto:

- name: "Generate html file for each host" 
 hosts: all 
 gather_facts: yes 
 tasks: 
   - name: "html file generation" 
     template: 
       src: "maquina.html.j2" 
       dest: "{{playbook_dir}}/{{inventory_hostname}}.html" 
     connection: local 

 Vuelva a ejecutar el comando (ansible-playbook -i inventario-apache.yml inventory.yml).

He aquí el resultado obtenido:

PLAY [Generate html file for each host] ************************* 
 
TASK [Gathering Facts] ***************************************** 
ok: [rec-apache-1] 
ok: [rec-apache-2] 
 
TASK [html file generation] ************************************* 
changed: [rec-apache-1] 
changed: [rec-apache-2] 
 
PLAY RECAP ***************************************************** 
rec-apache-1    : ok=2    changed=1    unreachable=0    failed=0 
rec-apache-2    : ok=2    changed=1...

Gestión de un servidor Apache

El playbook de centralización de información en los servidores está terminado. Este funciona perfectamente siempre y cuando el servidor Apache donde se encuentra el inventario esté configurado y funcionando.

Ahora verá cómo realizar la instalación del servidor Apache en la máquina que le servirá como piloto.

 Antes que nada, no instalará Apache sobre todas las máquinas del inventario, sino sobre la máquina de centralización. Para ello, debe proceder de esta manera:

  • Modificar el inventario con el objetivo de añadir un grupo inventory en el que añadirá la máquina central-inventory.

  • En el playbook, el campo hosts tomará el valor inventory.

 El playbook modificará la configuración del servidor Apache para autorizar los accesos al directorio inventario. Aquí encontrará el extracto de la configuración Apache que realizará esta operación:

Alias /inventario /var/www/html/inventory 
 
# Dar permisos de acceso a todo el mundo 
<Directory /var/www/html/inventory/> 
 Order Allow,Deny 
 Allow from All 
</Directory> 

Para implementar este archivo, la instrucción template utilizará como parámetros las opciones siguientes:

  • El nombre de la plantilla (src: inventory.conf.j2)

  • La ubicación del archivo...

Reducción de operaciones que causan impacto

De manera general, hay que reducir las operaciones que no sirvan para nada. Entre estas operaciones, los paro/marcha generan la no disponibilidad de servicios o pérdida de tiempo. En nuestro caso, no hay grandes consecuencias al hacer paro/marcha. Sin embargo, esto se puede convertir en un problema en el caso de una aplicación a disposición de distintos usuarios.

Ahora se tratarán dos técnicas que permitirán reducir la frecuencia de estas operaciones:

  • usando tags;

  • usando variables y el condicionamiento del inicio de operaciones;

  • usando un mecanismo de handler.

1. Mecanismo de los tags

Una manera de excluir una tarea de una serie de ejecuciones es utilizando los tags. Los tags se pueden definir a distintos niveles:

  • en el mismo playbook;

  • en la tarea.

a. Declaración de un tag

La anotación se añade con el campo tag. Si añade un tag restart en la tarea de reinicio del servicio Apache, el código de la tarea tomará la forma siguiente:

- name: "Start apache service" 
 service: 
   name: "httpd" 
   state: "restarted" 
   enabled: yes 
 tags: [ "restart" ] 

b. ¿Cómo hacer una lista de los tags de un playbook?

Para obtener la lista de los tags de un playbook, utilice el comando ansible-playbook seguido del nombre del playbook y añada la opción --list-tags.

Para el playbook install-apache.yml, el comando será el siguiente:

$ ansible-playbook install-apache.yml --list-tags 

He aquí el resultado del comando:

playbook: install-apache.yml 
 
 play #1 (inventario): Apache installation     TAGS: [] 
     TASK TAGS: [restart] 

El tag restart se encuentra en el playbook de instalación de Apache.

c. Selección o exclusión de un tag

Para excluir o seleccionar un tag, tiene dos opciones:

  • --tags LIST_TAGS: selección de las tareas que quiere ejecutar;

  • --skip LIST_TAGS: exclusión de las tareas.

Los tags se representan bajo la forma de una lista de palabras separadas por una coma (,).

He aquí el comando que permite solamente lanzar el reinicio de Apache:

$ ansible-playbook -i inventario-apache.yml install-apache.yml \ 
                   --tags restart...