CLAPI on Zwindler's Reflection

Module Ansible ansible-module-clapi : automatiser la configuration dans Centreon

Tue, 20 Dec 2016 13:00:49 +0000

Avant de parler de ansible-module-clapi

Cet article fait parti d’une suite d’articles ayant trait à l’automatisation de la configuration de la supervision Centreon à l’aide de CLAPI et d’Ansible, dont 2 que j’avais lu sur monitoring-fr. Dans l’article précédent, j’avais montré comment aller encore un peu plus loin que ce que Cédric Temple nous avait présenté.

A la fin de l’article, j’introduisais le fait qu’Ansible n’est pas seulement un outil permettant d’exécuter des tâches. Ansible est surtout un gestionnaire de configuration (comme Puppet, Salt, …).

Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

Le but est de garantir qu’un ensemble de serveurs donnés, on a toujours la même configuration.

Si on utilise Ansible de cet manière, le playbook n’a plus vocation a être utilisé « one shot » après installation d’un serveur. La gestion de la configuration de supervision devient un sous ensemble des configurations par défaut qui sont régulièrement vérifiées. Les playbooks qui définissent le SI sur l’ensemble des serveurs pour s’assurer qu’ils sont tous « conformes », tout est automatique et on élimine ainsi le risque d’erreurs humaines (type « oublis » ou « suppression accidentelle »).

Quelle conséquence sur nos playbooks ?

Car bien entendu, cela demande un peu plus de travail et de réflexion.

Les exécutions multiples

Si on exécute plusieurs fois le même playbook sur un serveur, -il faut impérativement que les commandes de ce playbook n’aient aucune incidence sur l’état du serveur si celui ci est déjà correctement configuré.

J’insiste… La modification ne doit ce faire que si nécessaire. Dans le langage Ansible, on dit d’une commande qu’elle est idempotent. Retenez bien, c’est important ;-).

Prenons pour exemple l’ajout d’une ligne dans le fichier /etc/sudoers pour permettre à notre client NRPE d’avoir le droit de réaliser un sudo pour avoir l’exhaustivité des informations renvoyées par multipath. On pourrait « naïvement » réaliser la tâche suivante dans Ansible de la façon suivante :

---
- hosts: all
tasks:
- shell: 'echo 'nrpe ALL = NOPASSWD: /sbin/multipath' >> /etc/sudoers'

Ce playbook fonctionnerait parfaitement.

Vraiment ?

Pour autant, à chaque exécution du playbook, une ligne sera ajoutée dans chaque serveur et on se retrouvera potentiellement avec des effets de bords à force de modifications successives.

On peut repérer ces changements à l’aide du récapitulatif en fin d’exécution qui serait toujours en changed.

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=11 changed=1 unreachable=0 failed=0

En fait, il est recommandé d’éviter d’utiliser les modules shell et command d’Ansible lorsqu’il existe des modules pour réaliser la même action. Typiquement dans ce cas là, l’idéal sera plutôt d’utiliser le module lineinfile, qui permet de s’assurer qu’une ligne bien précise est présente ou non, et de ne surtout rien faire (et donc ne rien modifier) si la ligne est déjà présente.

---
- hosts: all
tasks:
- lineinfile: 'dest=/etc/sudoers state=present line='nrpe ALL = NOPASSWD: /usr/sbin/pvs, /sbin/multipath''

Pour vérifier que votre playbook est idempotent, le plus simple est donc de lancer plusieurs fois un même playbook et de vérifier que le résultat à la seconde exécution est bien du type :

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=12 changed=0 unreachable=0 failed=0

Les erreurs

Il ne faut pas non plus que les commandes renvoient un code erreur lorsqu’elles s’exécutent pour la 2ème fois. Auquel cas, l’exécution du playbook sera arrêtée en cours de route.

Si j’exécute une première fois le playbook centreon_add_host.yml, j’obtiendrais le retour suivant.

TASK [monitor : centreon add host] *********************************************
changed: [srv-nouveau-01 -> superviseur.company.lan]

Tout va bien, mon hôte apparaît dans Centreon. Par contre, si je l’exécute une seconde fois …

TASK [monitor : centreon add host] *********************************************
fatal: [srv-nouveau-01 -> superviseur.company.lan]: FAILED! => {'changed': true, 'cmd': '/usr/bin/centreon -u admin -p admin -o HOST -a add -v \'srv-nouveau-01;srv-nouveau-01;192.168.1.12;generic-host;central;Ping_LAN\'', 'delta': '0:00:00.098198', 'end': '2016-07-25 17:17:01.268410', 'failed': true, 'rc': 1, 'start': '2016-07-25 17:17:01.170212', 'stderr': '', 'stdout': 'Object already exists (srv-nouveau-01)', 'stdout_lines': ['Object already exists (srv-nouveau-01)'], 'warnings': []}

Ignorer les erreurs

La méthode la plus simple pour gérer ce problème serait d’ignorer les erreurs. Ici CLAPI ne renvoie une erreur que pour m’informer que l’hôte existe déjà. Donc la gestion des erreurs et ici l’ajout multiple d’un même hôte est correctement géré par CLAPI.

Ansible le permet à l’aide de l’option ignore_errors: True. Dans ce cas là, l’exécution de la commande CLAPI qui renvoie une erreur sera ignoré dans le cas où l’hôte est déjà présent.

Mais la solution n’est pas satisfaisante : on peut se retrouver à masquer de vraies erreurs. Par exemple, si je n’ai pas fourni le bon chemin d’accès au binaire, l’erreur sera cachée et je ne saurai pas que mon playbook ne fonctionne jamais correctement. On peut imaginer plein d’autres cas d’erreurs qui nous laisseraient penser que l’ajout d’hôte se fait bien alors qu’en fait l’erreur est juste masquée.

A l’inverse, on peut trouver des cas où masquer l’erreur peut être légitime. Vous pouvez donc aller voir ici pour plus de renseignements.

Tester préalablement la présence de l’hôte

Toujours dans l’esprit idempotent, le mieux est donc de vérifier préalablement que le serveur n’est pas déjà renseigné avant de réaliser l’action d’ajout dans Centreon.

Malheureusement, à date, il n’existe pas de fonction dans CLAPI permettant de faire une recherche dans un seul hôte. Je le leur soufflerais peut être ;-). En attendant, on peut quand même s’en sortir grâce à la fonction show qui affiche une liste de tous les serveurs et un grep.

En fonction de la présence ou non de la ligne, on obtiendra un code retour de 0 ou 1, ce qui nous permet de valider la présence ou non du serveur.

- name: centreon check presence
shell: /usr/bin/centreon -u '{{ clapi_username }}' -p '{{ clapi_password }}' -o HOST -a show | grep '{{ inventory_hostname }};' >/dev/null
delegate_to: '{{ centreon_poller }}'
register: centreon_output
- name: centreon add host
shell: /usr/bin/centreon -u '{{ clapi_username }}' -p '{{ clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_poller }};Ping_LAN'
delegate_to: '{{ centreon_poller }}'
when: centreon_output.rc != 0

Cette solution fonctionne mais est loin d’être optimale. D’abord, elle se base sur grep, un binaire externe à CLAPI, pour valider la présence du serveur. Ça peut ne pas marcher à tous les coups !

Ensuite, le module shell à la fâcheuse caractéristique de ne pas être idempotent (c’est une obsession). A chaque exécution, Ansible considérera que le simple fait d’exécuter la commande change le système et affichera toujours « changed » même quand en réalité vos serveurs n’auront pas été modifiés !

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=10 changed=1 unreachable=0 failed=0

Avec shell il n’y a pas vraiment de parade au niveau Ansible. L’idéal serait donc pouvoir disposer d’un module Ansible capable d’interagir avec CLAPI tout en étant idempotent. #Teasing ;-)

Créer un nouveau module Ansible

Heureusement il est très facile de créer un nouveau module dans Ansible. Un exemple est proposé sur le site officiel avec des guides pour la proposition de module pour ajout dans les « extra modules ». Et j’ai également pas mal utilisé ce site pour me guider (blog.toast38coza.me, lien mort pas sauvegardé dans Internet Archive).

J’ai donc développé pour mon usage personnel des modules Ansible qui utilisent CLAPI et qui permettent pour l’instant de :

ajouter/supprimer un hôte
ajouter/supprimer des templates d’hôtes à un hôte
ajouter/supprimer un groupe d’hôtes
ajouter/supprimer des serveurs dans un groupe d’hôtes
régénérer la configuration et redémarrer un poller pour prise en compte des modifications

Et le code est disponible ici sur mon Github dans le projet ansible-module-clapi sous licence GPLv3.

Une fois les sources récupérées, vous pouvez exécuter ces modules Ansible complémentaires en créant un dossier librairie au même niveau que vos playbooks et en collant les fichiers Python du dépôt.

Un dossier test_suite contient le fichier hosts de cet article, le dossier group_vars avec les variables par groupes, ainsi qu’un playbook de test qui réalisera les actions suivantes :

ajouter un hôte dans centreon
supprimer ce même hôte de centreon
le resupprimer pour vérifier que la suppression d’un hôte déjà supprimé ne provoque pas d’erreur car l’hôte n’existe plus
supprimer un groupe testgroup qui n’existe pas pour voir si une erreur est renvoyée
ajouter le groupe testgroup
ajouter le groupe testgroup pour voir si cela génère une erreur à la 2ème exécution
ajouter l’hôte au groupe testgroup
ajouter un template à l’hôte
si un template d’hôte a été ajouté (oui, on vient de le faire)
- déclencher un « handler » => appliquer à l’hôte l’ensemble des templates de services liés au template d’hôte
et si n’importe laquelle de ces actions a provoqué une modification sur la base de Centreon (toutes en réalité)
- déclencher un « handler » => régénérer la configuration et redémarrer le moteur

Conclusion

Ceci vous permet d’avoir une vue d’ensemble des fonctionnalités disponibles pour l’instant. Ce n’est bien entendu qu’un début et je continuerai d’ajouter des fonctionnalités à partir de l’API CLAPI qui propose beaucoup plus de fonctionnalités.

Pour autant, ce module me permet aujourd’hui automatiser complètement l’ajout et la suppression des hôtes dans mon serveur Centreon. Actuellement pratiquement 120 serveurs sont gérés de cette manière :

J’attends bien entendu vos remarques, que ce soit sur le blog ou directement sur Github, avec impatience !

Automatisation de la supervision avec Centreon et Ansible (3)

Wed, 07 Dec 2016 13:00:47 +0000

Articles précédents sur Centreon et Ansible

Cet article fait suite aux deux articles rédigés en mai 2015 par Cédric Temple (ici et ici) qui donnent des pistes pour automatiser l’ajout de nœuds à superviser dans un console Centreon grâce à Ansible et CLAPI.

Pour ceux qui ne connaissent pas Ansible, je vous invite fortement à vous documenter sur cet outil de déploiement et de gestion de configuration très complet et qui bénéficie en ce moment d’un fort engouement, surtout depuis qu’Ansible a été racheté par RedHat ;-).

Et pour ceux qui ne connaissent pas CLAPI, il s’agit d’une API mise à disposition avec Centreon. Elle est installée par défaut dans les dernières versions. Elle permet de réaliser la totalité des opérations pouvant être faites depuis la console web en ligne de commande.

Les deux articles sur Monitoring-fr que je cite au début sont une bonne base pour appréhender ces deux sujets. Pour autant, on peut encore aller un peu plus loin et c’est pourquoi je vous propose de repartir de là où s’arrête l’article précédent.

L’exemple de l’ajout de l’hôte

A la fin de l’article précédent, on sait donc :

installer automatiquement les clients de supervision sur un nouvel hôte
et réaliser de manière unitaire via Ansible et des playbooks l’ajout et la modification d’hôtes dans Centreon.

J’aimerai revenir sur l’ajout d’hôtes dans Centreon. Pour reprendre l’exemple du playbook d’ajout d’hôtes de Cédric :

cat centreon_add_host.yml
- name: centreon add host
shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;central;ALL_HOST'
delegate_to: superviseur.company.lan

Et voici le fichier d’inventaire dans lequel on déclare l’ensemble de nos serveurs, triés par groupes.

cat /etc/ansible/hosts #fichier hosts d'Ansible
#ne pas confondre avec le hosts d'un serveur Linux
[serveurs-centreon]
superviseur.company.lan
pollerprod.company.lan
[serveurs-prod]
srv-prod-01
srv-prod-02
[serveurs-rect]
srv-rect-01
srv-rect-02
[nouveaux]
srv-nouveau-01
srv-nouveau-02
[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

Dans cet exemple simple, la première chose qu’on se dit si on regarde un peu rapidement, c’est qu’on aurait pu réaliser cet ajout à la main (ou via un script) avec CLAPI.

Le gain apporté par Ansible se situe « seulement » dans l’apport des variables inventory_hostname et ansible_default_ipv4.address.

Ici on tire partie de la faculté qu’a Ansible de récupérer des « facts » sur les machines, telle que l’adresse IP, que nous n’avons pas eu à renseigner.

C’est déjà un bon point par rapport à un script ou une commande à la main … mais on peut faire mieux !!

Aller plus loin : avec les variables de groupes

La première chose que je vais montrer dans cet article est qu’on peut également affecter aux groupes d’hôtes dans Ansible des variables.

Dans notre exemple, je vais donc créer un répertoire group_vars dans lequel je vais créer des fichiers de configuration dédiés à chaque groupe. J’en créé un par groupe (ou pas), et Ansible analysera automatiquement le répertoire group_vars et appliquera à mes hôtes toutes ces variables en fonction de ses groupes.

cat /etc/ansible/group_vars/serveurs-linux.yml
#NRPE Servers
nrpe_servers: ['192.168.100.10', '192.168.100.11']
#Poller Centreon
centreon_server: 'superviseur.company.lan'
centreon_pollername : 'Central'
centreon_clapi_username : 'admin'
centreon_clapi_password : 'admin'
centreon_clapi_path : '/usr/share/centreon/www/modules/centreon-clapi/core/centreon'

Je modifie donc mon playbook de la façon suivante :

cat centreon_add_host.yml
---
- name: centreon add host
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'

Le playbook est beaucoup plus réutilisable qu’avant. Qu’est ce qui a changé ?

J’ai variabilisé le chemin vers le binaire d’appel de CLAPI, qui était quand même vraiment long (Même si on préfèrera probablement plutôt ajouter le chemin dans le PATH, simplement) !
Je n’ai plus à renseigner le username et le mot de passe pour CLAPI à chaque appel.
Si j’ai plusieurs serveurs Centreon (plusieurs réseaux distincts par exemple), je n’ai qu’à créer un groupe et un fichier de variables dans group_vars dans lequel je renseignerai « centreon_server », « clapi_username » et « clapi_password » différents. Mon playbook restera inchangé.
Si j’ai plusieurs pollers (pollerprod pour la prod dans cet exemple), je peux affecter le serveur directement au bon poller avec la variable « centreon_pollername ».

Encore un peu plus loin : avec les groupes et l’héritage

Dans la configuration exemple que je donne plus haut, vous aurez peut être remarqué le groupe serveurs-linux qui regroupe tous les serveurs des groupes serveurs-prod, serveurs-rect et nouveaux.

[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

De cette manière, tous les paramètres communs à tous les serveurs linux peuvent être configurés au niveau serveurs-linux. Les variables seront héritées lors de l’exécution du playbook.

On peut aussi utiliser les groupes comme conditions de l’exécution d’un playbook. Ainsi, le playbook suivant ne s’exécutera que si le serveur fait parti du groupe serveurs-prod.

cat centreon_add_host_prod.yml
---
- name: centreon add host when in serveurs-prod
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'
when: "'serveurs-prod' in group_names"

Toujours plus loin : avec les variables et les templates

Les variables sont vraiment un gros plus !

Elles me permettent notamment de configurer les fichiers nrpe.conf (ou ntpd.conf, snmpd, resolv.conf, …) pour accepter les connexions des bons serveurs en fonction de la localisation ou du groupe.

La fonctionnalité la plus utile dans ce cas là est l’utilisation de templates. Il s’agit de fichiers de configurations variabilisés qui sont déployés uniquement si nécessaire sur les serveurs cibles en fonction de leurs variables.

Exemple d’un template de fichier nrpe.conf

{{ ansible_managed }}
cat nrpe.conf.j2
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts={% for i in nrpe_servers %} {{ i }}, {% endfor %}
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Le playbook suivant permettra de le déployer sur l’ensemble de mes serveurs CentOS et Redhat le package du client nrpe et ses dépendances et configurer le fichier nrpe.cfg en fonction du contexte (pour ceux qui n’ont pas encore ce fichier ou une version différente).

cat nrpe.yml
---
- hosts: all
tasks:
- yum: name={{ item }} state=installed
with_items:
- nrpe.x86_64
- net-snmp
- sysstat
- ...
- template: src=nrpe.cfg.j2 dest=/etc/nagios/nrpe.cfg

Une fois exécuté avec la commande suivante, Ansible balayera l’ensemble des serveurs renseignés dans le fichier /etc/ansible/hosts, vérifiera qu’ils ont tous les packages nrpe d’installés, puis déploiera sur les serveurs nécessaires le fichier de configuration en fonction des variables de chacun.

ansible-playbook -i /etc/ansible/hosts /etc/ansible/nrpe.yml

Et dans mon exemple on obtiendra un fichier de la forme suivante :

# Ansible managed: nrpe.cfg.j2 modified on 2016-08-14 10:52:51 by ansible on hostname
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=192.168.100.10, 192.168.100.11,
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Mais Ansible est avant tout un gestionnaire de configuration

Ansible ne sert pas uniquement à déployer des applications sur un serveur ou à exécuter des tâches automatisables. Au delà de ces rôles qu’il rempli à merveille, Ansible est surtout un gestionnaire de configuration (comme Puppet, Salt, …).

Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

On le voit avec mon dernier exemple : le but est de garantir qu’un ensemble de serveurs donnés, on a toujours la même configuration.

C’est le principe fondamental des outils de gestion de configuration et on comprend vite le gain :

Si une modification est réalisée par erreur, elle sera automatiquement corrigée au prochain passage du playbook => on n’aura pas besoin d’attendre qu’un administrateur passe par hasard sur un serveur pour remarquer une anomalie sur le NTP par exemple.

Appliqué à la supervision et Centreon

Je garanti que tous les serveurs inscris dans Ansible sont automatiquement ajoutés dans Centreon, en fonction de leur groupe. Si un administrateur oublie d’ajouter un serveur ou en supprime un, il sera ré-ajouté à l’exécution d’après sans intervention manuelle.

C’est donc de cette manière qu’il est conseillé d’utiliser Ansible. Le playbook n’est pas là pour être joué une fois par serveur, au fil de l’eau, car c’est source d’erreur ou d’oublis. On préférera plutôt exécuter régulièrement l’ensemble des playbooks qui définissent le SI sur l’ensemble des serveurs pour s’assurer qu’ils sont tous « conformes », sur tous les aspects dont la supervision.

Le réel gain en terme d’automatisation ce trouve ici.

Et dans l’article qui va suivre ?

Et c’est sur cette deuxième partie que nous nous attarderons dans le prochain article : la gestion de playbook pour automatiser la configuration de la supervision pour l’ensemble de nos hôtes via des playbooks idempotent (#teasing) !