IT Toolbox AI
Ansible · Bonnes pratiques

Bonnes pratiques et Troubleshooting

Appliquez un workflow de production prudent et diagnostiquez méthodiquement inventory, SSH, privilèges, YAML et idempotence.

Leçon disponible
20 min

Objectifs

  • Appliquer les bonnes pratiques essentielles en production.
  • Utiliser syntax-check, check, limit, tags et verbosité.
  • Reconnaître dix problèmes Ansible fréquents.
  • Suivre une méthode de diagnostic en dix étapes.

Bonnes pratiques et Troubleshooting

Une automatisation fiable réduit le périmètre, rend l’état attendu explicite et produit un résultat relisible. En production, la prudence commence par l’inventory, la version du code, la revue, la simulation lorsqu’elle est supportée et une cible limitée.

Le troubleshooting efficace progresse du contexte général vers la tâche précise. Il collecte des preuves sans relancer aveuglément le playbook sur tout le parc.

Checklist de production

Privilégiez les modules déclaratifs et idempotents. Les commandes shell et command restent utiles, mais seulement lorsqu’aucun module ne décrit correctement le besoin et avec un statut changed maîtrisé.

  • Utiliser les FQCN et des noms de tâches explicites.
  • Éviter shell et command lorsqu’un module dédié existe.
  • Structurer les responsabilités réutilisables avec des rôles.
  • Versionner playbooks, inventories non sensibles et dépendances.
  • Séparer les inventories de développement, test et production.
  • Tester --syntax-check puis --check sur une cible --limit.
  • Utiliser des tags documentés pour sélectionner une partie du playbook.
  • Protéger les secrets avec Vault ou un gestionnaire adapté, jamais en clair.
  • Appliquer le moindre privilège à SSH et become.
  • Relire changed, failed, skipped et recap après chaque exécution.
Contrôles avant exécution
ansible --version
ansible-inventory -i inventory.ini --graph
ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --check --limit web01
Exécuter un tag sur une cible limitée
ansible-playbook -i inventory.ini site.yml --tags nginx --limit web01

Dix problèmes fréquents

Le message d’erreur et la première tâche en échec orientent l’enquête. Cherchez d’abord quelle couche échoue plutôt que de modifier plusieurs paramètres à la fois.

  • 1. Hôte ou groupe absent de l’inventory actif.
  • 2. Nom DNS ou adresse ansible_host incorrecte.
  • 3. Port SSH inaccessible ou connexion refusée.
  • 4. Clé, compte ansible_user ou host key incorrects.
  • 5. Python absent ou interpréteur incompatible sur la cible.
  • 6. become refusé ou privilèges insuffisants.
  • 7. Indentation YAML ou syntaxe de playbook invalide.
  • 8. Module, collection ou rôle introuvable ou incompatible.
  • 9. Variable indéfinie, mauvaise précédence ou type inattendu.
  • 10. Tâche non idempotente, handler inattendu ou service qui refuse sa configuration.

Méthode de diagnostic en dix étapes

Conservez un périmètre réduit tout au long du diagnostic. -vvv augmente le détail, mais sa sortie peut contenir des chemins, adresses ou valeurs sensibles : nettoyez-la avant tout partage.

  • 1. Confirmer le dépôt, le playbook, l’environnement et la version Ansible utilisés.
  • 2. Afficher l’inventory avec --graph et vérifier le groupe ciblé.
  • 3. Inspecter l’hôte et ses variables résolues sans divulguer de secrets.
  • 4. Tester ansible.builtin.ping sur un seul hôte avec --limit.
  • 5. Vérifier séparément DNS, réseau, port SSH et identité de connexion.
  • 6. Valider le YAML et lancer --syntax-check.
  • 7. Lancer --check sur une cible de laboratoire si les modules le supportent.
  • 8. Rejouer avec -vvv et identifier la première tâche réellement en échec.
  • 9. Vérifier module, arguments, variables, become, service et logs de la cible.
  • 10. Corriger une cause à la fois, rejouer sur la cible limitée puis élargir progressivement.
Tester une seule cible
ansible web -i inventory.ini -m ansible.builtin.ping --limit web01
Vérifier la syntaxe
ansible-playbook -i inventory.ini site.yml --syntax-check
Simuler sur une cible
ansible-playbook -i inventory.ini site.yml --check --limit web01
Augmenter la verbosité
ansible-playbook -i inventory.ini site.yml --limit web01 -vvv

IT Toolbox AI n’exécute aucune de ces commandes : copiez-les uniquement vers un terminal et un environnement que vous êtes autorisé à administrer.

Corriger sans créer une nouvelle panne

Une correction minimale et observable est plus facile à valider. Ajoutez un test qui reproduit le problème, relisez le diff, sauvegardez les configurations importantes et prévoyez un retour arrière adapté au service.

  • Ne désactivez pas globalement la vérification des host keys pour masquer une erreur.
  • Ne remplacez pas une erreur de privilège par un compte trop puissant.
  • Ne divulguez pas les secrets en ajoutant debug ou --diff sur une tâche sensible.
  • Documentez la cause, la correction, la validation et le périmètre final.

Mini résumé

  • Modules idempotents, FQCN, rôles, inventories séparés et Vault rendent l’automatisation plus sûre.
  • Syntax-check, check, limit, tags et revue réduisent le risque d’exécution.
  • Les dix problèmes fréquents couvrent inventory, réseau, SSH, Python, become, YAML, dépendances, variables et idempotence.
  • Le diagnostic progresse sur une cible limitée, une preuve et une correction à la fois.

Outils associés

Générer un playbook Ansible

Utilisez Ansible Playbook Generator pour préparer une base YAML locale, puis relisez et adaptez chaque tâche avant utilisation.

Ouvrir l’outil

Construire une commande Ansible

Utilisez Ansible Command Builder pour composer une commande ad-hoc ou de diagnostic et comprendre ses options sans l’exécuter.

Ouvrir l’outil

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Quel réflexe réduit le périmètre d’un premier test ?
2. Quelle option aide à détailler un échec de connexion ou de tâche ?
3. Quelle approche est la plus fiable pendant le troubleshooting ?