[Ansible] – comment utiliser les gather_facts et tenir à jour un début de cmdb ?

Ansible regorge d’astuces qu’il faut engranger pour pouvoir aller plus loin et ne pas simplement installer des paquets sur des machines distantes. Par exemple, nous allons voir aujourd’hui une valorisation des gather_facts de ansible. Sur puppet, je crois que la même chose est réalisable avec facter.

Gather_facts c’est la possibilité d’utiliser des variables d’environnement ansible. Ce sont principalement des caractéristiques de la machine (interface, os…). Ces données vous vous en doutez seraient bien utiles dans une cmdb (centralisation d’informations de votre parc de machine).

Pour commencer cette démos nous allons commencer par créer quelques machines à l’aide de mon script maison (vous pouvez aussi le découvrir en vidéo désormais). Dans mon cas, j’ai 2 vm debian qui fonctionnent avec du ssh (merci docker).

└─ $ ▶ ./deploy-centre-sans-proxy-v2.sh --infos
#### Récap des conteneurs de tests ####
=> /oki-deb-vmparc3 - 172.17.0.3 - Utilisteur : oki / mdp:password
=> /oki-deb-vmparc2 - 172.17.0.2 - Utilisteur : oki / mdp:password

Maintenant nous allons configurer notre inventory hosts.yml très simplement :

all:  hosts:    172.17.0.2:    172.17.0.3:

Objectif ?

Notre souhait c’est d’utiliser les gather_facts et faire en sorte que ansible centralise tout cela sous forme de fichiers.html. Ainsi nous pourrons faire de la datavisualisation avec un apache installé localement (attention c’est pour la démo, c’est très moyen d’installer un serveur web sur une machine qui a la main sur tout votre parc).

Enfin, grâce à notre apache on pourra afficher dans un navigateur web. Et vous verrez ce qui compte c’est le principe car derrière c’est assez facile d’avoir des idées pour compléter tout cela pour avoir un bon début de cmdb.

Comment lister les gather_facts à notre dispostion ?

Les gather_facts sont accessibles via le module setup de ansible. Donc pour consulter toutes ces variables voici la commande à réaliser :

ansible all - i hosts.yml -u oki -m "setup"

La liste est assez longue et c’est plutôt une bonne nouvelle.

Faisons nos courses et retenons les variables :

  • inventory_hostname
  • ansible_default_ipv4.alias
  • ansible_architecture
  • ansible_distribution
  • ansible_distribution_version

Et on met tout cela en forme dans un template jinja2 pour générer à terme un fichier html :

<h1>Machine : {{ inventory_hostname }}</h1>
<ul>
<li>Interfaces : {{ ansible_default_ipv4.alias }}</li>
<li>Architecture : {{ ansible_architecture }}</li>
<li>OS : {{ ansible_distribution }}</li>
<li>Version : {{ ansible_distribution_version }}</li>
</ul>

Maintenant le playbook !

Voici le contenu de notre répertoire :

.
├── hosts.yml
├── playbook-cmdb.yml
└── templates
└── listing_ipv4.html.j2

Editons donc le playbook-cmdb.yml de la manière suivante :

---
- name: "[IP v4 listing]"
  hosts: all
  gather_facts: yes
  tasks:
    - name: "[IP v4 listing] - generate html"
      template:
        src: listing_ipv4.html.j2
        dest: "/var/www/html/{{ inventory_hostname }}.html"
      connection: local

Première chose on spécifie l’utilisation des gather_acts. Ensuite on utilise le module template pour faire appel au fichier jinja2. Puis on indique comme destination le répertoire de notre apache /var/www/html/ (de la machine master host). C’est aussi pour cela que nous spécifions connection : local.

Maintenant lançons la commande ansible-playbook :

ansible-playbook -i hosts.yml -u oki playbook-cmdb.yml

Et bingo :

PLAY [[IP v4 listing]] *******************************

TASK [Gathering Facts] *******************************
ok: [172.17.0.3]
ok: [172.17.0.2]

TASK [[IP v4 listing] - generate html] ***************
changed: [172.17.0.3]
changed: [172.17.0.2]

PLAY RECAP *******************************************
172.17.0.2 : ok=2 changed=1 unreachable=0 failed=0 
172.17.0.3 : ok=2 changed=1 unreachable=0 failed=0

Supprimons l’index de notre apache local : rm -f /var/www/html/index.html

Remarque : j’ai confié les droits de ce réprtoire à oki pour cet exercice

Et voici le résultat, une fiche par machine :

fiche-arbre

Puis la fiche de la machine :

fiche-cmdb.png

C’est bon tout ça non ? On comprend mieux l’intérêt des facts avec ce genre d’outils d’orchestration. Et ne vous inquiétez pas vous pouvez aisément pousser les fichier vers une autre machine qui portera un service apache de manière isolée.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s