Sortie Ansible et centralisation

1. Contexte

Avant d’aborder le mécanisme des callbacks, vous allez voir ce qu’il est possible de faire au niveau de la sortie standard d’Ansible. Vous aborderez notamment les aspects suivants :

2. Fichier de configuration et cowsay

Dans le cas où vous disposez du binaire cowsay sur la machine qui sert à lancer Ansible, ce dernier l’utilisera par défaut pour afficher les résultats des playbooks lancés.

Ci-dessous un petit exemple de trace que vous pourriez obtenir :

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

Il est possible de customiser le rendu en sortie de cowsay en utilisant un des nombreux skins. On passe pour cela par la variable ANSIBLE_COW_SELECTION. Ci-dessous, un exemple de résultat en utilisant le skin turkey (export ANSIBLE_COW_SELECTION=turkey) :

ok: [haproxy1]  
_____________________________________________________________...

1. Contexte

Vous avez vu le cas particulier de Cowsay et de la gestion des couleurs. Ansible est accompagné de nombreux callbacks d’affichage. Dans ce qui va suivre, vous allez voir comment en changer.

Comme pour Cowsay, il est possible de passer par le fichier de configuration ou une variable d’environnement :

Comme toujours, faites vos tests avec la variable d’environnement. Une fois que vous aurez trouvé la configuration qui vous sied, fixez-la avec un fichier de configuration.

2. Quelques plugins d’affichage alternatifs

Lors de l’exécution des tâches d’un playbook, chacune est indiquée avec le formalisme suivant :

Il est possible de réduire la sortie en utilisant le plugin dense. Ce dernier n’affichera qu’une seule ligne du nom du playbook lancé suivie des opérations en cours de lancement.

Ci-dessous, un exemple de lancement lorsque vous exportez la variable ANSIBLE_STDOUT_CALLBACK=dense :

PLAY 1: APACHE INSTALLATION  
task 3. apache1 apache2...

1. Contexte

Dans le cas d’un déploiement initial d’Ansible vous n’aurez pas forcément besoin de centraliser les opérations lancées. En revanche, lorsque vous aurez plusieurs dizaines d’installations qui sont lancées sur plusieurs milliers de machines par une équipe de plusieurs dizaines de personnes, vous aurez peut-être envie d’avoir quelques indications sur ce qu’il se passe.

Là encore, Ansible propose plusieurs solutions par défaut. Vous en verrez deux qui permettent de centraliser simplement les choses :

Le callback Ara sera également abordé afin de découvrir une solution plus avancée.

Il s’agit là de suggestions. Il vous sera toujours possible de choisir autre chose. N’hésitez pas à chercher pour connaître les autres solutions disponibles, la communauté autour d’Ansible étant très active.

Dans le cas où vous n’auriez pas trouvé une solution qui convienne, il sera toujours possible d’écrire votre propre callback pour répondre à votre besoin.

2. Centralisation via Syslog

Une manière assez traditionnelle de centraliser des informations est de passer par le mécanisme de Syslog d’Unix. Par la suite, ce service sera rendu par rsyslog et il écoutera sur le port 514 en mode UDP.

Pour ouvrir la communication entre Ansible et Syslog, il vous faudra :

1. Contexte

Vous avez fait le tour des solutions disponibles avec Ansible ainsi que dans la communauté, mais malheureusement vous n’avez pas trouvé de solution adaptée.

Vous allez donc procéder à l’écriture de votre propre callback. Pour l’essentiel, il s’agit d’écrire un programme en Python. Vous devrez donc, par conséquent, posséder quelques notions sur la programmation Python et sur l’utilisation des notions objets de ce langage.

2. Structure du programme

Avant de voir comment exposer le callback au niveau d’Ansible, vous allez découvrir la structure de ce petit programme.

Ci-dessous, les deux lignes en question :

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

Ci-dessous les déclarations à réaliser :

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

Le callback doit déclarer une classe CallbackModule. Dans le même temps, elle doit hériter de la classe CallbackModule du package ansible.plugins.callback.default.