Les Customs Facts Ansible

Dans le cadre de la gestion des infrastructures avec Ansible, l’un des défis fréquents est d’adapter les configurations et les déploiements aux spécificités de chaque hôte. Ansible, par défaut, collecte une grande quantité d’informations sur les systèmes gérés, appelées Facts, qui sont ensuite utilisées pour prendre des décisions dans les playbooks. Cependant, ces Facts ne couvrent pas toujours tous les besoins spécifiques d’une infrastructure complexe. C’est ici qu’interviennent les Customs Facts.

Ces facts personnalisés permettent de créer et d’ajouter des variables spécifiques à votre environnement, que ce soit pour identifier des rôles de serveurs, définir des configurations particulières, ou toute autre information pertinente pour vos déploiements. En d’autres termes, les Customs Facts vous offrent la possibilité d’enrichir les données que vous exploitez dans vos playbooks, rendant votre automatisation encore plus flexible et puissante.

Création de Customs Facts

Les Customs Facts sont des fichiers simples qui retournent des informations au format ini ou json. Ils doivent être placés dans le répertoire /etc/ansible/facts.d/ sur chaque hôte. Ce répertoire est reconnu par Ansible, qui l’analyse lors de l’exécution des playbooks pour y découvrir les facts personnalisés.

Format INI

Voici un exemple d’un fichier preference.fact utilisant le format INI :

[general]
function=War
family=Destruction

Format JSON

Dans cet exemple, nous aurions pu utiliser également le langage json :

{
  "general": {
    "function": "War",
    "family": "Destruction"
  }
}

Utilisation de scripts

On peut tout à fait utiliser un script écrit dans le langage de votre choix tant qu’il retourne de l’information sous le format json ou ini.

• Par exemple en bash qui retourne du json :

#!/bin/bash
DATE=$(date)
echo {\"date\" : \"${DATE}\"}

ou en python qui retourne de l’ini :

#!/usr/bin/env python3

import os
import subprocess
from datetime import datetime

def get_last_reboot():
    """Returns the date and time of the last reboot."""
    try:
        last_reboot_time = subprocess.check_output(['who', '-b']).decode().strip().split(' ')
        last_reboot_date = last_reboot_time[2] + ' ' + last_reboot_time[3]
        return last_reboot_date
    except Exception as e:
        return f"Error fetching last reboot time: {str(e)}"

def get_last_update():
    """Returns the date of the last package update based on log files."""
    try:
        if os.path.exists('/var/log/dpkg.log'):
            last_update_time = subprocess.check_output(
                "grep 'upgrade' /var/log/dpkg.log | tail -1 | awk '{print $1}'",
                shell=True
            ).decode().strip()
        elif os.path.exists('/var/log/yum.log'):
            last_update_time = subprocess.check_output(
                "grep 'Updated' /var/log/yum.log | tail -1 | awk '{print $1}'",
                shell=True
            ).decode().strip()
        else:
            return "No update logs found"

        return last_update_time
    except Exception as e:
        return f"Error fetching last update time: {str(e)}"

def generate_custom_facts_ini():
    """Generates custom facts in INI format and returns them as a string."""
    custom_facts = (
        "[general]\n"
        f"last_reboot={get_last_reboot()}\n"
        f"last_update={get_last_update()}\n"
    )

    return custom_facts

if __name__ == "__main__":
    facts = generate_custom_facts_ini()
    print(facts)

Vérification des valeurs retournées

Après avoir créé les Customs Facts, il est important de vérifier qu’ils sont correctement détectés par Ansible. Vous pouvez le faire en exécutant une commande ansible qui affiche tous les facts disponibles sur un hôte :

ansible -m setup  <nom de l'hote dans l'inventaire>

Cette commande retournera un grand nombre de données, parmi lesquelles vous pourrez vérifier si vos Customs Facts sont bien présents. Cherchez des champs commençant par ansible_local pour valider leur présence.

        "ansible_local": {
            "date": {
                "date": "Fri Aug 30 07:10:36 UTC 2024"
            },
            "infos": {
                "general": {
                    "last_reboot": "2024-08-29",
                    "last_update": "2024-08-30"
                }
            }
        },

Récupération optimisés des Customs Facts

Lors de l’utilisation d’Ansible pour gérer des hôtes distants, l’une des premières étapes consiste souvent à récupérer des Facts, c’est-à-dire des informations détaillées sur chaque hôte. Ces Facts comprennent des données telles que l’adresse IP, le système d’exploitation, la configuration matérielle, et bien d’autres éléments. Par défaut, Ansible collecte un ensemble complet de Facts, ce qui peut parfois être coûteux en termes de temps et de ressources, surtout lorsque vous gérez un grand nombre d’hôtes.

Pour optimiser la récupération des Facts et ne collecter que les informations essentielles, Ansible propose l’option gather_subset. Cette option permet de spécifier exactement quels sous-ensembles de Facts doivent être récupérés. Une des commandes les plus efficaces pour une récupération rapide et optimisée est la suivante :

ansible -m setup -a 'gather_subset=!all,min' 10.2.2.10

• gather_subset : Cette option permet de contrôler quels Facts sont collectés. Voici ce que signifient les paramètres utilisés dans notre commande :

  • !all : Ce paramètre indique à Ansible de ne pas collecter l’ensemble des Facts disponibles. C’est une façon de désactiver la collecte par défaut qui inclurait tous les Facts possibles, souvent plus nombreux que nécessaire.

  • min : Ce paramètre indique à Ansible de ne collecter que les Facts minimaux, c’est-à-dire les informations de base et essentielles comme le nom d’hôte, l’architecture du système et quelques autres détails rapides à obtenir.

En combinant !all et min, cette commande optimise la collecte des Facts en ne récupérant que les informations les plus importantes, évitant ainsi de surcharger le réseau ou de perdre du temps à collecter des données superflues.

Utiliser cette méthode de collecte de Facts présente plusieurs avantages significatifs, notamment :

• Gain de Temps : La collecte des Facts minimaux est plus rapide, ce qui peut accélérer l’exécution de vos playbooks, en particulier dans des environnements à grande échelle où de nombreux hôtes sont impliqués.
• Amélioration des Performances : Pour des tâches simples qui ne nécessitent pas un ensemble complet de Facts, cette méthode permet d’améliorer les performances globales des playbooks Ansible.

Cette approche de récupération optimisée est idéale dans plusieurs scénarios :

• Gestion de Grands Environnements : Lorsque vous gérez un grand nombre d’hôtes et que vous souhaitez minimiser le temps de collecte d’informations tout en maintenant un niveau d’information suffisant.

• Exécutions Fréquentes : Si vous avez besoin de collecter des Facts régulièrement, mais que seules les informations de base vous intéressent, utiliser gather_subset=!all,min vous fera gagner du temps à chaque exécution.

• Tâches de Vérification : Pour des tâches simples de vérification ou des opérations où les détails avancés ne sont pas nécessaires, la collecte minimale est idéale.

Où et comment créer des Customs Facts

Les Customs Facts dans Ansible sont des variables personnalisées définies pour enrichir les informations disponibles sur les hôtes gérés. Ces facts peuvent être créés à plusieurs étapes de la gestion de l’infrastructure, en fonction de vos besoins et de votre flux de travail. Voici les trois principales approches pour créer des Customs Facts : lors de la création des images de machines virtuelles (VM) avec Packer, lors du provisionnement avec le **provider Ansible pour Terraform **, ou directement au moment de la configuration des instances avec Ansible.

Création de Customs Facts avec Packer

Packer est un outil utilisé pour automatiser la création d’images de machines virtuelles. Il peut être intéressant de définir des Customs Facts dès la création de ces images, surtout si vous souhaitez que ces facts soient disponibles dès le démarrage de la VM.

Dans le fichier de configuration de Packer, vous pouvez ajouter un script de provisionnement qui crée les Customs Facts sous forme de fichiers dans le répertoire /etc/ansible/facts.d/.

  provisioner "shell" {
    inline = [
      "mkdir -p /etc/ansible/facts.d",
      "echo '{\"general\": {\"environment\": \"production\", \"role\": \"webserver\"}}' > /etc/ansible/facts.d/infos.fact"
    ]
  }

Lorsque l’image est construite, le fichier JSON contenant les Customs Facts est inclus dans l’image de la VM. Chaque instance créée à partir de cette image disposera automatiquement des facts définis. Plus d’infos sur Packer

Création de Customs Facts lors du provisionnement avec Terraform

Terraform est un outil d’infrastructure as code qui permet de déployer et gérer des ressources sur diverses plateformes. En utilisant Ansible comme provider pour Terraform, vous pouvez automatiser la création de Customs Facts lors du provisionnement des instances.

Dans votre fichier de configuration Terraform, configurez Ansible comme provider et créez un playbook qui déploiera les Customs Facts.

- hosts: all
  tasks:
    - name: Créer les Customs Facts
      copy:
        dest: /etc/ansible/facts.d/infos.fact
        content: |
          {
            "custom_fact": {
              "environment": "production",
              "role": "webserver"
            }
          }

Création de Customs Facts avec Ansible

Enfin, vous pouvez créer des Customs Facts directement lors de la configuration des instances avec Ansible. Cette méthode est flexible et peut être appliquée à tout moment, indépendamment du processus de création d’image ou de provisionnement.

Lors de la configuration des instances, ajoutez une tâche dans votre playbook Ansible qui crée les Customs Facts nécessaires.

- hosts: all
  tasks:
    - name: Créer le répertoire des Customs Facts
      file:
        path: /etc/ansible/facts.d
        state: directory
        mode: '0755'

    - name: Déployer les Customs Facts
      copy:
        dest: /etc/ansible/facts.d/infos.fact
        content: |
          {
            "general": {
              "environment": "production",
              "role": "database"
            }
          }

Quand utiliser chaque méthode ?

• Packer : Idéal pour des environnements où les Customs Facts ne changent pas souvent et doivent être disponibles dès le lancement de la VM. C’est une approche “bake-time”, où les informations sont intégrées directement dans l’image.
• Terraform + Ansible : Utile lorsque vous souhaitez définir ou modifier des Customs Facts lors du provisionnement des instances. Cette méthode est plus dynamique et permet d’adapter les facts aux besoins du moment.
• Ansible direct : Convient lorsque les Customs Facts doivent être définis ou modifiés après la création des instances, ou lorsqu’une flexibilité maximale est requise pour ajuster les facts en fonction de la configuration actuelle.

En fonction de vos besoins spécifiques et de votre flux de travail, vous pouvez choisir l’une de ces approches pour créer et gérer efficacement les Customs Facts dans vos environnements Ansible.

Bonnes pratiques pour l’utilisation des Customs Facts

Les Customs Facts sont un outil puissant dans Ansible, permettant d’ajouter des informations spécifiques à vos hôtes et d’enrichir vos playbooks. Cependant, pour tirer le meilleur parti de ces facts personnalisés et assurer une gestion efficace de votre infrastructure, il est essentiel de suivre certaines bonnes pratiques. Voici quelques recommandations pour une utilisation optimale des Customs Facts dans Ansible.

Une organisation claire et cohérente des Customs Facts est essentielle pour éviter les conflits, faciliter la maintenance et assurer la lisibilité de vos configurations.

• Utiliser des noms explicites : Les clés utilisées dans vos Customs Facts doivent être claires et explicites. Par exemple, utilisez environment au lieu de env pour indiquer l’environnement (production, staging, etc.), ou is_database_server pour indiquer le rôle du serveur.

• Regrouper les Facts par fonction : Si vous avez plusieurs Customs Facts liés à une même fonctionnalité, regroupez-les sous une même clé principale. Par exemple, vous pourriez avoir un fichier JSON avec des clés comme database, webserver, ou reverse_proxy pour regrouper des facts spécifiques à ces rôles.

• Éviter les redondances : Ne dupliquez pas les informations dans vos Customs Facts. Si une donnée est déjà disponible via les Facts par défaut d’Ansible, il est préférable de l’utiliser directement plutôt que de la recréer dans un Custom Fact.

• Automatiser la mise à jour des Customs Facts : Utilisez des crons ou des playbooks Ansible pour mettre à jour les Customs Facts à intervalles réguliers ou lorsque des changements importants surviennent dans votre infrastructure. Cela garantit que les informations restent pertinentes et à jour.

• Définir des permissions strictes : Les fichiers de Customs Facts doivent avoir des permissions restreintes pour éviter qu’ils ne soient modifiés par des utilisateurs non autorisés. Par exemple, définissez les permissions à 0755 pour que seuls les utilisateurs ayant les droits appropriés puissent les lire ou les modifier.

• Stocker les facts sensibles de manière sécurisée : Si vos Customs Facts contiennent des informations sensibles (comme des mots de passe ou des clés d’API), envisagez d’utiliser des outils de gestion des secrets ou de chiffrer ces informations avant de les stocker.

• Documenter les Customs Facts : Maintenez une documentation claire et à jour des Customs Facts utilisés dans votre infrastructure. Cela inclut des informations sur les clés disponibles, leur signification et comment elles sont utilisées dans les playbooks.

• Rendre les Customs Facts faciles à retrouver : Si vous utilisez des Customs Facts complexes ou répartis sur plusieurs fichiers, assurez-vous que leur localisation et leur structure soient bien documentées et accessibles à tous les membres de l’équipe.

• Tester les Facts dans un environnement de staging : Déployez d’abord vos Customs Facts dans un environnement de test ou de staging pour vérifier leur bon fonctionnement. Cela vous permet de détecter d’éventuels problèmes avant de les introduire en production.

• Utiliser des outils de validation : Vous pouvez utiliser des outils de validation JSON ou INI pour vérifier que vos fichiers de Customs Facts sont bien formatés et qu’ils seront correctement interprétés par Ansible.

• Limiter la taille des Customs Facts : Évitez de surcharger les Customs Facts avec des informations non essentielles. Plus un fichier de Customs Facts est volumineux, plus il prendra de temps à être traité par Ansible.

• Utiliser des Customs Facts uniquement lorsque nécessaire : Ne créez des Customs Facts que lorsque vous avez besoin d’informations spécifiques qui ne peuvent pas être obtenues autrement. Si une information est déjà disponible via les Facts standard d’Ansible, il est souvent préférable de l’utiliser directement.

Conclusion

Les Customs Facts sont un élément puissant et flexible d’Ansible, permettant de personnaliser et d’enrichir les informations disponibles sur vos hôtes gérés. En créant et en utilisant ces facts personnalisés, vous pouvez adapter vos playbooks à des besoins spécifiques, améliorer la gestion de votre infrastructure et automatiser des processus complexes de manière plus efficace.

Cependant, comme tout outil puissant, l’utilisation des Customs Facts nécessite une attention particulière pour garantir leur efficacité et leur sécurité. En suivant les bonnes pratiques que j’ai détaillé, telles que la structuration claire des Facts, leur mise à jour régulière et la gestion stricte des permissions, vous pouvez maximiser leur utilité tout en minimisant les risques.

Que vous choisissiez de créer des Customs Facts lors de la création des images de machines virtuelles avec Packer, au moment du provisionnement avec Terraform, ou directement pendant la configuration des instances avec Ansible, il est essentiel de bien comprendre les implications de chaque approche pour faire le meilleur choix en fonction de votre environnement.

En résumé, les Customs Facts ajoutent une dimension supplémentaire à votre gestion de configuration, vous permettant de mieux répondre aux défis uniques de votre infrastructure. En les intégrant de manière réfléchie et stratégique, vous pourrez non seulement optimiser vos processus, mais aussi gagner en efficacité opérationnelle tout en maintenant un contrôle rigoureux sur votre environnement.