Seguimos con ansible, esta vez para poder mejorar nuestros playbooks y toda nuestra automatización. En este caso, vamos a ver sintaxis y handlers. Entraremos un poco más en profundidad con las sintaxis, para seguir mejorando nuestros playbooks, y empezaremos a usar los handlers
Sintaxis
Como ya hemos visto en otras entradas la sintaxis de yaml para los playbooks es muy sencilla y además nos es más “legible” cuando estamos utilizando.
Como ya sabemos, nosotros definimos de esta manera una tarea:
– name: Instalar ntp service
yum: name= ntp state= present
En el cual definíamos el nombre con name. En este caso vamos, a instalar la última versión ntp en la máquina.
O un ejemplo con más opciones, seria copiar un fichero:
– name: Copiar fichero de configuración
copy: src= /home/usuario/fichero dest= /etc/programa/fichero owner= usuario group= grupo1 mode= 0755 notify= ntp restart
Esto copiaría un fichero del home de usuario, a una ruta de un programa en /etc, con el propietario usuario, del grupo grupo1, con los permisos de 755, y además reinicia el servicio especificado, en este caso ntp.
Hasta aquí todo claro, pero lo que queremos es hacerlo más legible. Para ello vamos a modificar la sintaxis de esta manera:
– name: Copiar fichero de configuración
copy:
src: /home/usuario/fichero
dest: /etc/programa/fichero
owner: usuario
group: grupo1
mode: 0755
notify: ntp restart
Dejándolo todo más claro.
Cambiamos en formato dejando los = por : y vemos que name y copy están en la misma línea, pero los argumentos están en otro línea diferente lo que correspondería al interior de copy. Ojo con esta parte de arquitectura, porque es muy importante y puede estar fallar la ejecución y volvernos locos con esto.
Los dos métodos son válidos pero tenemos que intentar mejorar la visualización del código en ansible, para que nos sea, como hemos comentado antes, más legible en caso de tener muchos argumentos.
A nivel de variables también podemos “organizarlo” de otra manera. Imaginaros, que como hemos puesto en ejemplo de yum, necesitamos instalar varios programas como el ntp, mysql o apache.
En este caso lo definiríamos así:
En una sola línea:
O podemos definirlo en varias líneas:
También podemos utilizar, los llamados diccionarios, para poder tener una mejor organización.
En este caso, tendríamos una lista de variables, pero especificados con una clave.
Como usaríamos este caso, pues muy sencillo:
diccionario.web
Esto nos devolvería el valor que tiene la clave web, que sería apache2.
Que queremos utilizarlo en formato de una sola línea, entonces sería así:
Más ejemplos de sintaxis seria, por ejemplo, usar varias líneas en una sentencia muy larga con un salto de línea, para ello usaremos |
En caso que queramos usar una sola línea en esa sentencia usaríamos > Esto mostraría toda la línea de seguido.
Os muestro un ejemplo de cómo saldría, para ello vamos a usar debug, que nos va a mostrar el contenido de las variable.
Y nos mostraría esto:
lista_1linea
lista
diccionario
diccionario_1linea
texto
texto_1linea
Y como hemos comentado antes, si necesitamos usar el valor de una clave dentro de un diccionario, en el caso que he puesto seria diccionario.web:
Handlers
Son igual que las tareas pero solo se ejecutaran cuando otra tarea lo llame. El uso más frecuente es, cambiar la configuración de una aplicación y vamos a querer reiniciar un servicio cuando se cambie esa configuración. Muy importante, los handlers se ejecutan siempre a final del playbook. Es decir, si tenemos 100 tareas y la primera tiene la llamada al handler hasta el final no hará ese handler
Un ejemplo práctico. Tenemos que copiar el fichero de configuración de ntp y después si hay algún cambio, reiniciara el servicio:
Task:
-name: fichero configuración ntp
Copy: scr=fichero.conf dest=/etc/ntp/fichero.conf
Notify: reiniciar_ntp
Este reiniciar_ntp tenemos que tenerlo definido como handlers a parte.
Handlers:
-name: reniciar_ntp
Service: name=ntpd state=restarted
Creo el fichero.conf para que haga la copia.
Como ha hecho al copia ejecuta el handler y reinicia el servicio ntp.
Si vuelvo a ejecutarlo.
Al no copiar el fichero.conf, no reinicia el servicio.
Muy útil cuando necesitamos tareas anidadas.
Espero que os sirva