Guide complet de la configuration du cache de faits Ansible

Le cache de faits Ansible est utile lorsque vos playbooks passent trop de temps à collecter les mêmes faits d'hôtes à chaque exécution. Si vous gérez des centaines d'hôtes, les appels répétés au module setup peuvent ajouter une surcharge SSH notable avant même que le travail réel ne commence.

Le cache de faits stocke les faits collectés après une exécution réussie, puis les réutilise tant que le cache est valide. Le résultat est un démarrage plus rapide des playbooks pour les workflows qui peuvent tolérer des faits légèrement obsolètes.

Comprendre les faits Ansible et l'impact sur les performances

Ansible collecte les faits avec le module setup, soit explicitement, soit via le comportement par défaut gather_facts: true. Les faits incluent des détails tels que la famille du système d'exploitation, le noyau, les adresses IP, les points de montage, le CPU, la mémoire et les informations sur l'interpréteur Python.

Le gain de performances provient de l'évitement de la collecte répétée à distance lorsque les données en cache sont fraîches. Cela est utile pour les rapports, les templates et la logique conditionnelle qui dépendent de faits qui ne changent pas minute par minute.

Méthodes de configuration pour le cache de faits

Ansible configure le cache de faits dans ansible.cfg. Deux choix pratiques sont les fichiers JSON locaux et Redis. Les noms exacts des plugins sont importants.

1. Cache par fichier JSON (stockage local)

Le cache par fichier JSON stocke les faits sur la machine de contrôle. Il est simple et ne nécessite aucun service externe.

Configuration du cache JSON dans ansible.cfg

Utilisez le plugin de cache jsonfile :

[defaults]
fact_caching = jsonfile
fact_caching_connection = /chemin/vers/cache_faits_ansible
fact_caching_timeout = 600

fact_caching_connection est le répertoire où Ansible écrit les fichiers de cache. Créez-le d'abord et assurez-vous que l'utilisateur exécutant Ansible peut y écrire :

mkdir -p /chemin/vers/cache_faits_ansible

fact_caching_timeout est mesuré en secondes. Après le délai d'expiration, Ansible collecte à nouveau des faits frais lorsqu'un play en a besoin.

2. Cache Redis (stockage partagé haute performance)

Redis fonctionne mieux lorsque plusieurs nœuds de contrôle, utilisateurs ou tâches CI doivent partager le même cache de faits.

Prérequis pour le cache Redis

Vous avez besoin d'un serveur Redis accessible et du client Python Redis disponible dans l'environnement Python utilisé par Ansible :

python -m pip install redis

Configuration du cache Redis dans ansible.cfg

Utilisez une chaîne de connexion Redis :

[defaults]
fact_caching = redis
fact_caching_connection = 127.0.0.1:6379/0
fact_caching_timeout = 3600

Le /0 sélectionne la base de données Redis 0. Utilisez une base de données dédiée ou une instance Redis si d'autres applications utilisent également Redis, et protégez le point de terminaison Redis comme tout autre service d'infrastructure.

Intégration du cache dans les playbooks

Le cache est rempli lorsqu'un play collecte des faits :

- name: Collecter et utiliser les faits
  hosts: serveurs_web
  gather_facts: true
  tasks:
    - name: Afficher la famille du système d'exploitation
      debug:
        msg: "La famille du système d'exploitation est {{ ansible_os_family }}"

Avec le cache de faits activé, Ansible peut réutiliser les faits en cache tant qu'ils sont valides. Si les faits sont manquants ou expirés et que gather_facts: true, Ansible les collecte à nouveau.

Si vous définissez gather_facts: false, Ansible n'exécute pas la collecte de faits pour ce play. Les faits en cache peuvent encore être disponibles via les variables d'hôte s'ils ont déjà été mis en cache, mais ne vous y fiez pas aveuglément pour une logique critique. Un cache manquant peut rendre les variables indéfinies.

Un modèle sûr est de collecter les faits dans un play planifié ou précoce, puis d'utiliser les faits en cache dans des playbooks de rapports ou d'orchestration ultérieurs où l'obsolescence est acceptable.

Gestion du cache de faits

Effacez le cache lorsque les faits d'hôte ont changé et que vous ne voulez pas attendre le délai d'expiration.

Effacement du cache JSON

Supprimez les fichiers dans le répertoire de cache configuré :

rm -rf /chemin/vers/cache_faits_ansible/*

Effacement du cache Redis

Si la base de données Redis est dédiée aux faits Ansible, vous pouvez vider cette base de données :

redis-cli -n 0 FLUSHDB

FLUSHDB supprime toutes les clés de la base de données Redis sélectionnée. Ne l'exécutez pas sur une base de données partagée à moins de savoir que toutes les clés peuvent être supprimées en toute sécurité.

Meilleures pratiques

• Utilisez jsonfile pour une seule machine de contrôle et des workflows locaux simples.
• Utilisez Redis lorsque plusieurs exécuteurs ont besoin du même cache.
• Gardez des délais d'expiration courts pour une infrastructure changeant rapidement et plus longs pour des parcs stables.
• Ne mettez pas en cache des faits personnalisés sensibles dans un emplacement que d'autres utilisateurs peuvent lire.
• Vérifiez quel fichier de configuration Ansible utilise avec ansible --version.
• Testez avec un groupe d'inventaire avant d'activer le cache sur un grand parc.

En résumé

Activez le cache de faits Ansible lorsque la collecte répétée de faits est un coût mesurable et que vos playbooks peuvent tolérer des données en cache. Commencez avec jsonfile, passez à Redis uniquement lorsque le partage du cache résout un problème de workflow réel, et définissez un délai d'expiration qui correspond à la fréquence à laquelle les faits de vos hôtes changent.