Résolution des états 'Changed' inattendus et des échecs de collecte de faits

Deux problèmes Ansible nuisent rapidement à la confiance : les tâches qui signalent changed alors que rien de significatif n'a changé, et la collecte de faits qui échoue avant même que le vrai travail ne commence. Le premier problème rend chaque exécution suspecte. Le second bloque les playbooks qui dépendent des faits du système d'exploitation, du réseau, des paquets ou du matériel. Les deux sont réparables une fois que vous séparez les vrais changements d'état des tâches bruyantes et les échecs de connexion des échecs de configuration.

Comprendre la cause racine de ces problèmes est crucial pour maintenir une automatisation Ansible robuste et fiable. Qu'il s'agisse d'un problème subtil de permissions de fichier, d'un handler déclenché involontairement, ou d'une conditionnelle peu fiable, identifier la raison exacte d'un statut changed inattendu ou d'une collecte de faits échouée peut faire gagner un temps de débogage considérable. Nous explorerons ces scénarios avec des explications claires et des exemples concrets.

Comprendre l'état 'Changed' dans Ansible

Dans Ansible, une tâche est signalée comme changed si le module qu'elle utilise a modifié l'état du système. C'est le comportement attendu lorsqu'une tâche applique avec succès une configuration. Cependant, parfois une tâche peut signaler changed même si la configuration prévue était déjà en place ou si aucune modification n'a réellement été effectuée.

Causes courantes des états 'Changed' inattendus

1. Problèmes d'idempotence

Les modules Ansible sont conçus pour être idempotents, ce qui signifie que les exécuter plusieurs fois doit avoir le même effet que de les exécuter une fois. Si un module n'est pas parfaitement idempotent, ou s'il est utilisé d'une manière qui contourne ses vérifications d'idempotence, il peut signaler un changement même si l'état souhaité est déjà atteint. Cela est souvent dû à la façon dont le module vérifie l'état actuel par rapport à l'état souhaité.

2. Permissions et propriété des fichiers

Des permissions ou une propriété de fichier incorrectes sur le nœud de contrôle Ansible ou sur les nœuds gérés peuvent entraîner des changements inattendus. Par exemple, si Ansible doit écrire un fichier, mais ne dispose pas des permissions d'écriture nécessaires, il peut échouer et signaler une erreur. Inversement, si Ansible vérifie l'existence d'un fichier et le trouve, mais que ses métadonnées (comme l'heure de modification ou les permissions) ne correspondent pas à un modèle, il peut réappliquer le fichier, le marquant comme changé.

• Exemple : Considérons un playbook qui copie un fichier de configuration. Si la propriété ou les permissions sur le fichier cible sur le nœud géré sont légèrement différentes de ce qu'Ansible attend (par exemple, un horodatage différent dû à une modification manuelle antérieure ou un propriétaire différent), Ansible peut signaler un changement même si le contenu est identique.

  - name: Assurer que le fichier de configuration est en place
    copy:
      src: /chemin/vers/local/config.conf
      dest: /etc/app/config.conf
      owner: appuser
      group: appgroup
      mode: '0644'
  

  Si /etc/app/config.conf existe déjà avec le contenu correct mais des permissions légèrement différentes (par exemple, 0664), Ansible le signalera comme changed car le paramètre mode ne correspond pas. Pour éviter cela, assurez-vous que votre paramètre mode reflète précisément l'état souhaité, ou envisagez d'utiliser des modules plus conscients du contenu.

3. Handlers déclenchés involontairement

Les handlers sont des tâches spéciales qui ne s'exécutent que lorsqu'elles sont notifiées par d'autres tâches, généralement lorsqu'un changement se produit. Si un handler est notifié par une tâche qui signale changed de manière incorrecte, le handler s'exécutera également, provoquant potentiellement d'autres changements ou opérations non intentionnels. Cela peut créer un effet en cascade de changements signalés.

• Exemple : Si une tâche copy (comme montré ci-dessus) signale incorrectement changed en raison d'une différence de permission mineure, et que cette tâche notifie un handler pour redémarrer un service, le service redémarrera même si le contenu du fichier de configuration n'a peut-être pas réellement changé.

  - name: Redémarrer le serveur web
    service:
      name: nginx
      state: restarted
    listen: "notifier redémarrage serveur web"
  

  Et la tâche copy le notifierait :

  - name: Assurer que le fichier de configuration est en place
    copy:
      src: /chemin/vers/local/config.conf
      dest: /etc/app/config.conf
    notify: "notifier redémarrage serveur web"
  

  Astuce : Examinez attentivement quelles tâches notifient les handlers et assurez-vous que les tâches de notification ne signalent changed que lorsqu'une modification de configuration significative a eu lieu. Utilisez changed_when: false judicieusement si vous savez qu'une tâche ne devrait jamais signaler de changement, ou ajustez les paramètres du module pour améliorer l'idempotence.

4. Logique conditionnelle peu fiable

Les instructions conditionnelles (clauses when:) sont puissantes mais peuvent conduire à un comportement inattendu si elles ne sont pas soigneusement construites. Si une condition s'évalue incorrectement ou est basée sur un fait instable, une tâche peut s'exécuter quand elle ne le devrait pas, ou ne pas s'exécuter quand elle le devrait, conduisant potentiellement à des états changed ou à des opportunités manquées de configuration réelle.

• Exemple : Se fier à un fait qui n'est pas toujours présent ou cohérent peut causer des problèmes.

  - name: Configurer l'application si la fonctionnalité est activée
    lineinfile:
      path: /etc/app/settings.conf
      line: "FEATURE_ENABLED=true"
    when: ansible_facts['some_custom_fact'] == "enabled"
  

  Si some_custom_fact est parfois manquant ou a une valeur légèrement différente (par exemple, Enabled au lieu de enabled), la condition when peut échouer de manière inattendue, ou la tâche peut s'exécuter quand elle ne le devrait pas. Validez toujours les conditions et les faits dont elles dépendent.

  Astuce : Utilisez des tâches debug: pour afficher les valeurs des faits et des variables utilisées dans les conditions when afin de vérifier leur état pendant l'exécution du playbook.

Dépannage des échecs de collecte de faits

La collecte de faits d'Ansible est le processus par lequel Ansible collecte des informations (faits) sur les nœuds gérés, telles que les adresses IP, le système d'exploitation, la mémoire et l'espace disque. Ces faits sont ensuite disponibles pour une utilisation dans les playbooks. Les échecs de collecte de faits peuvent empêcher les playbooks de s'exécuter correctement ou d'utiliser des informations essentielles.

Causes courantes des échecs de collecte de faits

1. Problèmes de connexion

Les faits sont collectés via SSH (pour Linux/Unix) ou WinRM (pour Windows) par défaut. Si Ansible ne peut pas établir de connexion avec le nœud géré, il ne peut pas collecter les faits. C'est souvent la cause la plus directe d'un échec de collecte de faits.

• Symptômes : Le playbook se bloque ou échoue immédiatement avec des erreurs liées à la connexion (par exemple, ssh: connect to host ... port 22: Connection refused, timeout, Authentication failed).
• Résolution : Vérifiez la connectivité SSH/WinRM, assurez-vous que les paramètres de connexion corrects ansible_user, ansible_ssh_private_key_file et autres sont correctement définis dans votre inventaire ou ansible.cfg. Vérifiez les règles du pare-feu.

2. Permissions insuffisantes sur les nœuds gérés

Pour qu'Ansible collecte les faits, l'utilisateur avec lequel Ansible se connecte doit disposer des permissions appropriées sur le nœud géré. Cela signifie généralement pouvoir exécuter certaines commandes et accéder à des répertoires spécifiques.

• Symptômes : La collecte de faits peut se terminer partiellement ou échouer avec des erreurs de permission refusée lors de la tentative d'exécution de commandes comme uname, df, lsblk, ou d'accès aux entrées du système de fichiers /proc.

• Résolution : Assurez-vous que l'utilisateur de connexion dispose des privilèges sudo sans nécessiter de mot de passe (si nécessaire pour des commandes spécifiques) ou que l'utilisateur a un accès direct en lecture aux informations système requises.

  # Exemple de comment s'assurer que sudo est disponible pour la collecte de faits
  - name: Collecter les faits
    setup:
    # Si des commandes spécifiques nécessitent sudo, assurez-vous que l'utilisateur a un sudo sans mot de passe configuré
  

  Astuce : Pour l'élévation de privilèges pendant la collecte de faits, Ansible s'appuie souvent sur la directive become. Si votre utilisateur de connexion a besoin de privilèges élevés pour exécuter des commandes pour la collecte de faits, configurez become: yes et become_method: sudo (ou équivalent) dans votre playbook ou inventaire. Assurez-vous que le become_user (souvent root) dispose des permissions nécessaires.

3. Interpréteur Python incompatible

Les modules Ansible, y compris le module setup utilisé pour la collecte de faits, dépendent souvent d'un interpréteur Python sur le nœud géré. Si l'interpréteur Python par défaut est incompatible (par exemple, Python 3 alors qu'Ansible s'attend à Python 2, ou vice-versa, selon la version d'Ansible et les exigences du module) ou manquant, la collecte de faits peut échouer.

• Symptômes : Erreurs liées à l'exécution de Python, ImportError, ou échecs de module pendant la collecte de faits.

• Résolution : Spécifiez l'interpréteur Python correct en utilisant ansible_python_interpreter dans votre inventaire ou ansible.cfg. Assurez-vous qu'une version compatible de Python est installée sur les nœuds gérés.

  # exemple de fichier d'inventaire
  [my_servers]
  server1.example.com ansible_python_interpreter=/usr/bin/python3
  server2.example.com ansible_python_interpreter=/usr/bin/python2.7
  

4. Répertoire /etc/ansible/facts.d corrompu ou manquant

Ansible peut également collecter des faits personnalisés à partir de fichiers dans le répertoire /etc/ansible/facts.d sur les nœuds gérés. Si ce répertoire ou son contenu est corrompu ou inaccessible, cela peut interférer avec le processus de collecte de faits, bien que cela soit moins courant pour la collecte de faits standard.

• Symptômes : Erreurs mentionnant spécifiquement des problèmes avec /etc/ansible/facts.d.
• Résolution : Vérifiez les permissions et le contenu de /etc/ansible/facts.d sur les nœuds gérés. Assurez-vous qu'il s'agit d'un répertoire et qu'Ansible a les permissions de lecture dessus.

5. gather_facts: no ou restrictions gather_subset

Dans certains playbooks, gather_facts peut être défini sur no pour accélérer l'exécution, ou gather_subset peut être utilisé pour limiter les faits collectés. Si vous essayez ensuite d'utiliser des faits qui n'ont pas été collectés, cela apparaîtra comme un échec.

• Symptômes : Variables non définies lors de l'accès aux faits, ou erreurs comme AttributeError: 'dict' object has no attribute '...'.

• Résolution : Assurez-vous que gather_facts: yes (ou le comportement par défaut) est activé pour le play, ou activez explicitement les sous-ensembles de faits que vous avez l'intention d'utiliser. Si gather_facts: no est intentionnel, alors les faits ne doivent pas être utilisés ou doivent être définis manuellement.

  - name: Mon Play
    hosts: all
    gather_facts: yes # Ou omettez cette ligne pour utiliser la valeur par défaut (oui)
    tasks:
      - name: Afficher la famille OS
        debug:
          msg: "Exécution sur {{ ansible_os_family }}"
  

  Si vous n'avez besoin que d'un sous-ensemble de faits, vous pouvez optimiser avec le module setup dans une tâche :

  - name: Mon Play optimisé pour les faits
    hosts: all
    gather_facts: false
    tasks:
      - name: Collecter uniquement les faits réseau
        ansible.builtin.setup:
          gather_subset:
            - '!all'
            - network
  
      - name: Afficher les interfaces réseau
        debug:
          msg: "Interfaces : {{ ansible_interfaces }}"
  

Un chemin de triage pratique

Lorsqu'un playbook est bruyant, commencez par un hôte et une tâche suspecte. Exécuter l'ensemble du play sur l'ensemble de l'inventaire rend la sortie plus difficile à lire et peut déclencher des handlers que vous n'aviez pas l'intention de tester.

ansible-playbook -i inventory.ini site.yml --limit app01.example.com --check --diff

--diff est particulièrement utile pour les tâches de fichiers. Si une tâche de modèle ou de copie signale changed, le diff indique souvent si le contenu a changé, le mode a changé, ou seulement un horodatage généré a changé. Les horodatages générés sont une source classique de faux changements :

# Généré le {{ ansible_date_time.iso8601 }}

Cette ligne garantit que le fichier rendu est différent à chaque exécution. Si l'application n'a pas besoin de l'horodatage, supprimez-le. Si les humains ont besoin de savoir que le fichier est géré, utilisez un commentaire stable :

# Géré par Ansible. Les modifications locales peuvent être écrasées.

Pour les tâches de commande et de shell, supposez qu'elles ne sont pas idempotentes jusqu'à preuve du contraire. Une tâche comme celle-ci signalera généralement changed à chaque fois :

- name: Reconstruire le cache de l'application
  ansible.builtin.command: /opt/app/bin/rebuild-cache

Si la commande n'est qu'une vérification, marquez-la honnêtement :

- name: Vérifier l'état du cache de l'application
  ansible.builtin.command: /opt/app/bin/cache-status
  register: cache_status
  changed_when: false

Si la commande ne doit s'exécuter que lorsqu'un fichier est manquant, utilisez creates :

- name: Initialiser la base de données de l'application
  ansible.builtin.command:
    cmd: /opt/app/bin/init-db
    creates: /var/lib/app/.db_initialized

Si elle ne doit s'exécuter que lorsqu'un fichier existe, utilisez removes. Ces gardes sont meilleures que changed_when: false car elles empêchent également une exécution inutile.

Les handlers ont besoin de la même discipline. Un handler de redémarrage doit être notifié par des tâches qui modifient la configuration effective du service, et non par des tâches non liées qui touchent par hasard un répertoire. Si un rôle redémarre Nginx à chaque exécution, inspectez chaque tâche de notification avec --diff. La tâche bruyante est souvent un modèle avec des espaces instables, une discordance de mode de fichier, ou une tâche de commande qui signale toujours changed.

Les échecs de collecte de faits sont plus faciles si vous séparez les tests de connexion des tests de faits :

ansible app01.example.com -i inventory.ini -m ping
ansible app01.example.com -i inventory.ini -m setup -a "filter=ansible_distribution*"

Si ping échoue, vous avez un problème de connexion, d'authentification, de privilège ou de démarrage Python. Si ping fonctionne mais que setup échoue, le problème est plus probablement dans la collecte de faits : commandes manquantes, permissions restreintes, interpréteur Python cassé, ou faits personnalisés problématiques.

Sur les images Linux minimales, Python peut être manquant ou installé à un endroit qu'Ansible ne détecte pas automatiquement. Définissez ansible_python_interpreter explicitement :

[app]
app01.example.com ansible_python_interpreter=/usr/bin/python3

Évitez de coder en dur /usr/bin/python2.7 sauf si vous gérez vraiment d'anciens systèmes qui en ont besoin. La plupart des distributions Linux actuelles utilisent Python 3 pour l'exécution des modules Ansible.

Les faits personnalisés peuvent échouer de manière surprenante car ils s'exécutent pendant la configuration. Vérifiez-les directement sur l'hôte géré :

sudo find /etc/ansible/facts.d -maxdepth 1 -type f -ls
sudo /etc/ansible/facts.d/example.fact

Les fichiers .fact exécutables doivent renvoyer des données JSON valides ou de style INI. Un script qui imprime un avertissement avant le JSON peut casser l'analyse. Un script qui se bloque en appelant un service interne peut faire ressembler la collecte de faits à un délai d'attente SSH.

Si la collecte de faits est lente plutôt que cassée, réduisez la portée au lieu de désactiver les faits partout. Désactivez la collecte automatique au niveau du play et appelez setup uniquement là où vous en avez besoin, avec un sous-ensemble ou un filtre. Cela maintient les tâches ultérieures honnêtes : elles ne peuvent pas dépendre accidentellement de faits que le play n'a jamais collectés.

L'objectif n'est pas de forcer chaque exécution à afficher changed=0. Certains changements sont réels. L'objectif est la confiance. Lorsqu'Ansible dit changé, vous devriez pouvoir pointer vers le fichier, le service, le paquet ou le résultat de commande qui a changé. Lorsque la collecte de faits échoue, vous devriez savoir si Ansible n'a pas pu se connecter, n'a pas pu exécuter Python, n'a pas pu lire les données système, ou n'a pas pu analyser un fait personnalisé.