Salida Ansible y centralización de registros

1. Contexto

Antes de presentarle el mecanismo de los callbacks, verá lo que se puede hacer con el retorno estándar de Ansible. Con respecto al retorno estándar, se tratarán los aspectos siguientes:

2. Archivo de configuración y cowsay

En el caso de que disponga del binario cowsay en la máquina que ejecuta Ansible, este último será usado por defecto para mostrar los resultados de los playbooks ejecutados.

He aquí un pequeño ejemplo del retorno que podemos obtener:

ok: [haproxy1] 
_____________________________________________________________ 
< TASK [mediawiki/haproxy : enable and start haproxy service] > 
------------------------------------------------------------- 
       \   ^__^ 
        \  (oo)\_______ 
           (__)\       )\/\ 
               ||----w | 
               ||     || 

Se puede configurar la forma del retorno de cowsay usando uno de tantos temas que posee. Para ello tiene que usar la variable ANSIBLE_COW_SELECTION. He aquí un ejemplo de resultado usando el tema turkey (export ANSIBLE_COW_SELECTION=turkey):

ok: [haproxy1] 
_____________________________________________________________ 
< TASK [mediawiki/haproxy : enable and start haproxy service] > 
------------------------------------------------------------- 
 \                                  ,+*^^*+___+++_ ...

1. Contexto

Vio el caso particular de Cowsay y de la gestión de los colores. Ansible contiene numerosos callbacks de visualización. En las líneas siguientes verá cómo cambiarlos.

Como para Cowsay, se puede utilizar el archivo de configuración o una variable de entorno:

Como siempre, haga sus tests con la variable de entorno. Una vez que haya encontrado la configuración que le convenga, hágala fija en el archivo de configuración. 

2. Algunos plugins alternativos de visualización

Cuando se ejecutan tareas de un playbook, cada una será indicada usando la forma siguiente:

Se puede reducir el retorno usando el plugin dense. Este último solamente mostrará una línea con el nombre del playbook ejecutado seguido por las operaciones que estén siendo ejecutadas.

He aquí un ejemplo de lanzamiento cuando exporta...

1. Contexto

En el caso de un despliegue inicial de Ansible, posiblemente no necesitará centralizar las operaciones ejecutadas. Sin embargo, cuando tenga decenas de instalaciones ejecutadas sobre miles de máquinas en un servicio de decenas de personas, quizá necesite tener información de lo que está pasando.

En este caso, de nuevo Ansible propone distintas soluciones por defecto. Hay dos que le permitirán centralizar los registros simplemente:

Estudiará el callback Ara para descubrir una solución más avanzada.

Estos son los consejos que le brinda este libro, siempre podrá elegir otra solución. No dude en investigar para conocer otras soluciones disponibles; la comunidad Ansible es muy activa.

Si no encontrara una solución satisfactoria, siempre podrá escribir su propio callback que responderá a sus necesidades.

2. Centralización de registros usando Syslog

Una manera tradicional de centralizar registros es utilizar el mecanismo Syslog de Unix. Este servicio lo ofrece rsyslog y el puerto de escucha es 514 en modo UDP.

Para abrir la comunicación entre Ansible y Syslog, tendrá que:

Si no exporta las variables con prefijo SYSLOG_, los registros serán enviados por defecto al servidor localhost, al puerto 514 y el retorno será LOG_USER. 

Aquí abajo tiene un ejemplo de ejecución del playbook install-mariadb.yml en el inventario wiki.inv:

$ export ANSIBLE_CALLBACK_WHITELIST=syslog_json 
$ export SYSLOG_SERVER=localhost 
$ ansible-playbook -i wiki.inv install-mariadb.yml 

No hay ningún cambio en el resultado de la ejecución de Ansible. Sin embargo, debería ver aparecer registros en el archivo /var/log/syslog.

He aquí un extracto de los mensajes que debería ver:

Aug 14 13:31:37 trabajo ansible-command: task execution OK; host:  
mysql1; message: {"changed": false, "msg": "", "rc": 0, "results": 
["mariadb-server-1:5.5.52-1.el7.x86_64 providing mariadb-server 
is already installed", "MySQL-python-1.2.5-1.el7.x86_64 providing 
MySQL-python...

1. Contexto

Ya ha visto las soluciones disponibles en Ansible así como las de la comunidad, pero desafortunadamente no ha encontrado una solución adaptada a su situación.

En este caso, deberá proceder a la escritura de su propio callback. Se trata, básicamente, de un programa en Python. Deberá tener algunas nociones sobre programación en Python y sobre el uso de las nociones objeto de este lenguaje.

2. Estructura del programa

Antes de ver cómo usar el callback en Ansible, debe descubrir la estructura de este pequeño programa.

He aquí las dos líneas de ese encabezado:

#!/usr/bin/python3 
# -*- coding: utf-8 -*- 

He aquí las declaraciones que tendrá que realizar:

# Make coding more python3-ish 
from __future__ import (absolute_import, division, print_function) 
__metaclass__ = type 

El callback deberá declarar una clase CallbackModule. También tendrá que heredar la clase CallbackModule del paquete ansible.plugins.callback.default.

from ansible.plugins.callback.default import CallbackModule as  
CallbackModule_default 

He aquí el código correspondiente a esta clase:

# This callback inherit from default callback 
class CallbackModule(CallbackModule_default):* 
   CALLBACK_VERSION = 2.0 
   CALLBACK_NAME = 'test' 

3. Exposición del callback a Ansible

Acaba de escribir su primer callback. Ahora tiene que exponerlo al motor de Ansible.