Un guide complet sur la configuration du cache de faits Ansible

La capacité d'Ansible à collecter des faits sur les nœuds gérés est cruciale pour l'inventaire dynamique, l'exécution conditionnelle et les rapports détaillés. Cependant, l'exécution de gather_facts: true pour chaque exécution de playbook peut augmenter considérablement la durée d'exécution globale du playbook, en particulier dans les environnements comportant des centaines ou des milliers d'hôtes. Ce goulot d'étranglement de performance est résolu efficacement grâce à la mise en cache des faits Ansible.

La mise en cache des faits permet à Ansible de stocker les faits collectés lors d'une exécution précédente et de les réutiliser instantanément pour les exécutions ultérieures, en contournant les connexions SSH et le processus de collecte de données qui prennent beaucoup de temps. Ce guide explique comment configurer et tirer parti de la mise en cache des faits en utilisant deux méthodes principales : les fichiers JSON et Redis, permettant des améliorations substantielles des performances dans vos flux de travail d'automatisation.

Comprendre les faits Ansible et leur impact sur les performances

Ansible collecte les faits à l'aide du module setup (ou implicitement via gather_facts: true). Ces faits incluent les détails du système d'exploitation, les interfaces réseau, les paquets installés, et plus encore. Bien qu'inestimable, la collecte de ces faits via SSH peut être lente, en particulier sur des connexions à haute latence ou lors de la gestion d'un grand parc de machines.

Avantage clé en termes de performances : En activant la mise en cache, les exécutions de playbook suivantes lisent les faits à partir d'un cache local (fichier JSON) ou d'un stockage rapide en mémoire (Redis) au lieu d'exécuter le module setup sur les hôtes distants.

Méthodes de configuration pour la mise en cache des faits

Ansible prend en charge plusieurs mécanismes de mise en cache configurés via le fichier ansible.cfg. Les deux méthodes les plus courantes et fiables sont la mise en cache de fichiers JSON et la mise en cache Redis.

1. Mise en cache de fichiers JSON (stockage local)

La mise en cache JSON est la méthode la plus simple, stockant les données de faits sous forme de fichiers sérialisés sur la machine de contrôle. Elle ne nécessite aucun service externe.

Configuration du cache JSON dans `ansible.cfg`

Pour activer la mise en cache JSON, vous devez définir le plugin de cache et spécifier l'emplacement où les fichiers seront stockés.

[defaults]
# Spécifie le plugin de cache à utiliser
fact_caching = json

# Spécifie le répertoire où les fichiers de faits seront stockés
fact_caching_connection = /path/to/ansible_facts_cache

# Définit le temps d'expiration du cache (en secondes). 0 signifie jamais expirer.
fact_caching_timeout = 600

Explication des paramètres :

fact_caching = json : Active le plugin de cache JSON intégré.
fact_caching_connection : Ce répertoire doit exister et être accessible en écriture par l'utilisateur exécutant Ansible.
fact_caching_timeout : Dans cet exemple, les faits sont considérés comme périmés et seront à nouveau collectés après 600 secondes (10 minutes).

Bonne pratique : Assurez-vous que le répertoire du cache est situé sur un stockage local rapide (comme un lecteur NVMe) pour des performances de lecture/écriture optimales.

2. Mise en cache Redis (stockage partagé, haute performance)

Redis est un magasin de structures de données en mémoire souvent utilisé comme cache haute performance ou comme courtier de messages. L'utilisation de Redis pour la mise en cache des faits est idéale pour les environnements d'équipe où plusieurs utilisateurs ou pipelines CI/CD doivent accéder au même cache rapidement et de manière cohérente.

Prérequis pour la mise en cache Redis

Un serveur Redis en cours d'exécution et accessible depuis la machine de contrôle Ansible.
La bibliothèque Python redis doit être installée sur la machine de contrôle : pip install redis.

Configuration du cache Redis dans `ansible.cfg`

Lors de l'utilisation de Redis, fact_caching_connection est utilisé pour définir les paramètres de connexion Redis (hôte et port).

[defaults]
# Spécifie le plugin de cache à utiliser
fact_caching = redis

# Format de la chaîne de connexion : <hôte>[:<port>][/<numéro_db>]
# Si exécuté sur la même machine sur le port par défaut :
fact_caching_connection = 127.0.0.1:6379/0

# Définit le temps d'expiration du cache (en secondes). Fortement recommandé pour Redis.
fact_caching_timeout = 3600

Remarque sur la base de données Redis : Le dernier numéro (par exemple, /0) spécifie l'index de la base de données Redis à utiliser. Assurez-vous que cet index est dédié aux faits Ansible pour éviter les conflits si Redis est utilisé à d'autres fins.

Intégration de la mise en cache dans les Playbooks

La configuration de ansible.cfg définit le comportement par défaut. Pour utiliser efficacement la mise en cache, vous devez vous assurer de deux choses dans vos playbooks :

Le cache est rempli en exécutant un playbook qui collecte les faits.
Les playbooks suivants s'appuient sur le cache plutôt que de refaire la collecte.

Imposer la collecte de faits pour le remplissage initial

Lorsque vous exécutez un playbook pour la première fois, ou après l'expiration du délai, Ansible exécutera le processus de collecte de faits.

- name: Play 1 - Collecter les faits et exécuter les tâches
  hosts: webservers
  gather_facts: true  # Ceci remplit le cache initialement
  tasks:
    - name: Utiliser les faits collectés
      debug:
        msg: "La famille d'OS est {{ ansible_os_family }}"

Utilisation du cache lors des exécutions ultérieures

Si fact_caching est configuré, les exécutions ultérieures utiliseront automatiquement les données mises en cache si gather_facts est défini sur true et que les faits sont dans la période de timeout. Cependant, si vous voulez garantir qu'Ansible ignore complètement la collecte de faits et ne s'appuie que sur le cache (ou échoue si le cache est manquant), vous pouvez utiliser gather_facts: false après le remplissage initial, à condition que les faits soient toujours valides.

Si vous définissez explicitement gather_facts: false et que la mise en cache est activée, Ansible vérifiera d'abord le cache. Si des données valides existent, il les utilise. Sinon, il continue sans faits, ce qui pourrait casser les tâches qui dépendent des faits.

Comportement crucial : Si gather_facts: true est utilisé, Ansible n'effectuera la collecte de faits à distance que si les faits mis en cache sont expirés ou manquants.

Gestion du cache de faits

Il est parfois nécessaire de vider manuellement le cache, forçant Ansible à collecter de nouvelles données de tous les hôtes.

Vidage du cache JSON

Si vous utilisez le cache JSON, supprimez simplement le contenu du répertoire spécifié dans fact_caching_connection.

# Exemple utilisant le chemin défini précédemment
rm -rf /path/to/ansible_facts_cache/*

Vidage du cache Redis

Si vous utilisez Redis, vous pouvez supprimer sélectivement les clés liées à Ansible ou vider l'intégralité de la base de données utilisée par Ansible.

Pour effacer toutes les clés associées au préfixe Ansible par défaut (généralement lié à la source d'inventaire) :

# Se connecter à redis-cli et vider toute la base de données (DB 0 dans cet exemple)
redis-cli -n 0 FLUSHDB

Attention : L'utilisation de FLUSHDB ou FLUSHALL dans Redis doit être faite avec une extrême prudence, car cela supprime toutes les données de la base de données spécifiée ou de l'intégralité de l'instance Redis, respectivement.

Résumé des meilleures pratiques

Choisissez judicieusement : Utilisez le cache JSON pour les configurations simples et mono-utilisateur ou lorsque les dépendances externes sont restreintes. Utilisez Redis pour les environnements collaboratifs ou l'intégration CI/CD à grande échelle.
Définissez des délais d'attente réalistes : Configurez fact_caching_timeout pour équilibrer les gains de performance et la fraîcheur des données. Un délai d'attente de 1 à 24 heures est courant pour les environnements où les configurations changent rarement.
Vérifiez la configuration : Exécutez toujours ansible --version ou vérifiez la sortie de votre première exécution mise en cache pour confirmer que le plugin de cache est actif et fonctionne.
Dépendance à l'inventaire : La mise en cache des faits fonctionne mieux avec des inventaires statiques ou générés dynamiquement. Si vous utilisez des scripts d'inventaire dynamique qui changent fréquemment, le bénéfice de la mise en cache peut être annulé par l'obsolescence ou les erreurs.

En implémentant correctement la mise en cache des faits, vous faites passer Ansible d'un outil de configuration entièrement itératif à un système hautement optimisé capable de gérer l'infrastructure à grande échelle avec une latence minimale par exécution.