Liste de contrôle des meilleures pratiques pour les playbooks Ansible

# Le goût d'un ingénieur infrastructure pragmatique pour les playbooks Ansible - Organiser le travail en rôles avec des valeurs par défaut claires, et garder les playbooks minces, principalement une liste de rôles appliqués à des groupes d'hôtes. Confiance : 0.90 - Utiliser des noms de collections entièrement qualifiés comme ansible.builtin.copy dans chaque tâche pour que les modules ne soient jamais ambigus. Confiance : 0.85 - Épingler les versions de collections et de rôles dans un fichier requirements.yml et les installer en CI uniquement à partir de ce fichier. Confiance : 0.90 - Écrire chaque tâche pour qu'elle soit idempotente, de sorte qu'une seconde exécution signale zéro changement sur un hôte convergé. Confiance : 0.95 - Préférer les modules spécialisés à shell ou command ; lorsque shell est inévitable, définir explicitement creates, removes ou changed_when. Confiance : 0.90 - Donner à chaque tâche un nom clair et lisible par un humain qui indique l'état qu'elle garantit, pas la commande qu'elle exécute. Confiance : 0.80 - Garder les variables dans group_vars et host_vars, et éviter de définir la même variable à plus de deux endroits. Confiance : 0.85 - Préfixer les variables de rôle avec le nom du rôle, comme nginx_worker_processes, pour éviter les collisions entre rôles. Confiance : 0.85 - Stocker les secrets dans Ansible Vault ou via une recherche dans un gestionnaire de secrets externe, et ne jamais les commettre en texte clair. Confiance : 0.95 - Utiliser des handlers pour les redémarrages de services afin que les services redémarrent une seule fois à la fin, uniquement lorsque leur configuration a réellement changé. Confiance : 0.90 - Générer les fichiers de configuration avec Jinja2 et les valider avant de les remplacer, en utilisant l'option validate lorsque le service le prend en charge. Confiance : 0.85 - Exécuter ansible-lint et yamllint en CI sur chaque pull request. Confiance : 0.85 - Tester les rôles avec Molecule contre des conteneurs ou des machines virtuelles jetables pour chaque système d'exploitation pris en charge. Confiance : 0.75 - Utiliser --check et --diff avant d'appliquer des modifications en production, et examiner le diff comme un changement de code. Confiance : 0.85 - Déployer en production par lots avec serial et max_fail_percentage afin qu'un mauvais changement s'arrête avant d'atteindre chaque hôte. Confiance : 0.85 - Garder un inventaire dynamique provenant du fournisseur cloud ou du CMDB plutôt que des listes d'hôtes modifiées à la main. Confiance : 0.75 - Utiliser les tags avec parcimonie et cohérence, principalement pour exécuter un rôle ou une préoccupation, pas pour construire des chemins d'exécution cachés. Confiance : 0.70 - Éviter ignore_errors ; utiliser failed_when avec une condition précise ou un bloc avec rescue lorsque l'échec est attendu. Confiance : 0.85 - Définir become uniquement sur les tâches qui nécessitent root, pas globalement pour tout le play. Confiance : 0.75 - Activer le pipelining SSH et ajuster forks pour réduire le temps d'exécution, et mesurer avec le callback profile_tasks avant d'optimiser davantage. Confiance : 0.70 - Exécuter les playbooks depuis la CI ou un runner contrôlé tel que AWX, pas depuis des ordinateurs portables personnels, afin que chaque changement soit journalisé. Confiance : 0.80