¡Esta es una revisión vieja del documento!
Tabla de Contenidos
Ansible: Conceptos avanzados
Sección perteneciente al curso Ansible Automatización IT
¿Qué es YAML y por qué es importante conocerlo?
YAML es un formato de serialización de datos , legible por humanos, que está inspirado en lenguajes como XML.
YAML es un superconjunto del formato JSON, que permite añadir estructuras más complejas e incluso comentarios.
En el mundo Ansible, todos los playbooks están escritos en YAML.
Reglas generales:
- Extensión
.yaml(recomendada) o.yml - Las tabulaciones no están permitidas, solo los espacios.
- Es necesario identar (sangrar) el código uno o más espacios.
- Todas las claves/propiedades son case-sensitive (se distingue mayúsculas de minúsculas).
- Los comentarios empiezan con un símbolo
#.
Ejemplo de un playbook en YAML:
hosts: webservers sudo: yes vars: app_name: PleaseDeployMe repo_url: https://github.com/username/reponame.git repo_remote: origin repo_version: master webapps_dir: /deployed virtualenv_root: /deployed/PleaseDeployMe/mac tasks: - name: git pull project git: repo={{repo_url}} dest={{webapps_dir}}/{{app_name}} version=master
Tipos de datos
Cadenas de texto
--- foo: Esta es una cadena de texto
Los tres guiones indican el inicio del fichero.
Para meter caracteres especiales, hay que meterlos entre comillas:
--- foo: Esta es una cadena de texto "\n" estoy en una línea nueva.
Booleanos
True es lo mismo que On; False es lo mismo que Off.
--- foo: True bar: False light: On TV: Off
Números
Soporta números decimales, hexadecimales…
--- foo: 12345 bar: 0x12d4 plop: 023332
Array / listas
--- items: [1, 2, 3, 4, 5] names: ["one", "two", "three", "four", "five"]
También se podría escribir en el siguiente formato:
items: - 1 - 2 - 3 - 4 - 5
Diccionarios
--- foo: {thing1: huey, thing2: louie, thing3: dewey}
Los diccionarios se pueden anidar con otros elementos:
--- foo: bar: - bar - rgb - plob
El diccionario bar tiene dentro una lista de 3 elementos.
Variables
Permiten almacenar y reusar información. Las variables se procesan en orden, de mayor a menor preferencia:
- Variables por línea de comandos
- Variables en tareas
- Variables en roles y secciones
include - Variables creadas con la directiva
register - Variables en los inventarios
- Variables en las plays
- Host facts
- Variables por defecto en los roles
En la documentación oficial de Ansible se habla hasta de 15 niveles de prioridad.
Reglas a la hora de definir variables en Ansible:
- Deben comenzar con letra
- Pueden contener letras, números y guiones bajos.
Tareas, Plays y Playbooks I
Una tarea es la aplicación de un módulo en un playbook para realizar una acción específica sobre un equipo.
Algunas tareas:
file: un directorio debe existir.yum: un paquete tiene que estar instalado.service: un servicio tiene que estar ejecutándose.template: se quiere cargar una configuración en un template.get_url: se quiere descargar un fichero de una URL.git: se quiere clonar el código fuente desde un repositorio.
Ejemplo de la sección de tareas en un fichero YAML de Ansible:
tasks: - name: httpd package is present yum: name: httpd state: latest - name: latest index.html file is present copy: scr: files/index.html dest: /var/www/html/ - name: restart httpd service: name: httpd state: restarted
Plays y Playbooks
Una play consiste en un conjunto ordenado de tareas que se ejecutan en los hosts seleccionados sobre un inventario. Un playbook es un fichero que contiene una o más plays:
A continuación vemos un ejemplo de un Playbook con una sola play:
--- - name: install and start apache hosts: web become: yes vars: http_port: 80 tasks: - name: httpd package is present yum: name: httpd state: latest - name: latest index.html file is present copy: scr: files/index.html dest: /var/www/html/
Ansible permite importar playbooks con la palabra clave import_playbook.
Ejemplo de nuestro primer playbook (primer_playbook.yaml):
# Este es nuestro primer playbook - name: primera play hosts: all gather_facts: false # para que no traiga los facts por defecto tasks: - name: comprobar conexión ping: data: functionando
Lo ejecutamos:
ansible-playbook -i /home/pepito/inventario -u ansible_user --key-file /home/pepito/.ssh/id_rsa primer_playbook.yaml
También podríamos añadirle la opción -v para obtener más información de la salida:
ansible-playbook -i /home/pepito/inventario -u ansible_user --key-file /home/pepito/.ssh/id_rsa primer_playbook.yaml -v
Poner ejemplo de la salida del comando anterior.
Podemos revisar la sintaxis del Playbook sin ejecutarlo:
ansible-playbook primer_playbook.yaml --syntax-check
Tareas, Plays y Playbooks II
Vamos a coger el playbook de la sección anterior y complicarlo un poco más añadiéndole otra play:
# Este es nuestro primer playbook - name: primera play hosts: all gather_facts: false # para que no traiga los facts por defecto tasks: - name: comprobar conexión ping: data: funcionando - name: segunda play hosts: servidor_web gather_facts: false tasks: - name: listar directorios command: ls - name: instalar nginx apt: name=nginx state=present
Antes de ejecutar, revisamos la sintaxis del fichero:
ansible-playbook primer_playbook.yaml --syntax-check
Si todo va bien, ejecutamos el playbook:
ansible-playbook -i /home/pepito/inventario -u ansible_user --key-file /home/pepito/.ssh/id_rsa primer_playbook.yaml -v
Vemos que falla porque no el usuario no tiene permisos para instalar el paquete nginx. Podemos indicar que necesitamos elevar privilegios con become: yes:
# Este es nuestro primer playbook - name: primera play hosts: all gather_facts: false # para que no traiga los facts por defecto tasks: - name: comprobar conexión ping: data: funcionando - name: segunda play hosts: servidor_web become: yes gather_facts: false tasks: - name: listar directorios command: ls - name: instalar nginx apt: name=nginx state=present
En la máquina destino, tenemos que evitar que pida la contraseña el usar sudo. Para ello, hay que editar el fichero /etc/sudoers y la línea que comienza por %sudo dejarla de la siguiente manera:
%sudo ALL=(ALL) NOPASSWD: ALL
Modificamos más el playbook para incluir variables:
# Este es nuestro primer playbook - name: primera play hosts: all gather_facts: false # para que no traiga los facts por defecto tasks: - name: comprobar conexión ping: data: funcionando - name: segunda play hosts: servidor_web become: yes gather_facts: false vars: state: absent tasks: - name: listar directorios command: ls - name: instalar nginx apt: name=nginx state={{ state }}
Lo que añadamos entre llaves ({{}}) se sustituirá por el valor que le hayamos dado. En este caso state es absent, así que es lo mismo que si hubiéramos puesto:
apt: name=nginx state=absent
Si ejecutamos ahora ese playbook, desinstalará nginx.
Qué son los handlers y para qué se usan
Los handlers son tareas especiales que se ejecutan al final de una play si son notificadas por otra tarea cuando ocurre un cambio.
tasks: - name: httpd package is present yum: name: httpd state: latest notify: restart httpd - name: latest index.html file is present copy: src: files/index.html dest: /var/www/html handlers: - name: restart httpd service: name: httpd state: restarted
Los handlers se definen al final del Playbook