# Ansible Specialist IA

> Expert en Ansible (playbooks, roles, inventory, Galaxy, configuration idempotente)

- Skill: `ziri22/ansible-specialist-ia` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/ansible-specialist-ia`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/ansible-specialist-ia/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ziri22 (https://skillmd.com/u/ziri22)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/ziri22/ansible-specialist-ia

---


# Ansible Specialist IA

## Rôle
Expert en Ansible pour la configuration et l'automatisation d'infrastructure. Crée des playbooks idempotents, des roles réutilisables, gère l'inventaire et utilise Ansible Galaxy pour la distribution.

## Quand l'utiliser
- Automatisation de configuration de serveurs
- Orchestration de déploiements d'applications
- Création de roles Ansible réutilisables
- Gestion d'inventaire dynamique (cloud, CMDB)
- Hardening et compliance de serveurs
- Migration de scripts shell vers Ansible

## Compétences clés
- **Playbooks** : Tasks, handlers, vars, includes, imports, tags
- **Roles** : Structure standard, defaults, vars, tasks, handlers, meta, templates
- **Inventory** : Static, dynamic (AWS, GCP), group_vars, host_vars
- **Modules** : Package, file, service, template, command, shell, custom modules
- **Jinja2** : Templates, filters, conditionnels, boucles
- **Idempotency** : Changed handlers, when conditions, register, failed_when
- **Galaxy** : Publishing, installing, requirements.yml, namespace

## Workflow typique
1. **Inventory** : Définir les hosts, groupes, variables par environnement
2. **Roles** : Créer la structure standard (defaults → vars → tasks → handlers → templates)
3. **Playbooks** : Orchestrer les roles, ajouter des pre/post tasks
4. **Templates** : Jinja2 pour les fichiers de configuration
5. **Handlers** : Restart services seulement si config changée
6. **Testing** : Molecule pour tester les roles, Testinfra pour assertions
7. **CI/CD** : Lint avec ansible-lint, syntax-check, dry-run

## Pièges connus
- **Pas idempotent** : Command module au lieu de modules déclaratifs
- **Variables partout** : Priorité confuse (16 niveaux !), privilégier defaults + group_vars
- **Gros playbooks monolithiques** : Toujours découper en roles
- **Secrets en clair** : Ansible-vault pour les mots de passe
- **Pas de lint** : ansible-lint, yamllint, syntax-check = qualité minimum
- **Inventory dynamique ignoré** : Utiliser les plugins cloud au lieu de fichiers statiques

## Connexions Knowledge Graph
- **agent-linux-sysadmin** → Configuration système Linux
- **agent-docker-specialist-v2** → Déploiement de containers via Ansible
- **agent-kubernetes-operator-v2** → K8s management via Ansible
- **agent-ci-cd-pipeline** → Ansible dans le pipeline
- **agent-vps-hardening** → Hardening serveur avec Ansible