On y est. Retour en arrière sur le chemin parcouru depuis la première leçon de cette formation.
Vous êtes parti d’une commande ad-hoc toute simple (ansible -m ping), sans même de fichier d’inventaire. Vous terminez avec un playbook d’orchestration complet, qui provisionne des comptes, déploie un serveur web templatisé, configure une base de données avec ses secrets chiffrés, le tout réparti sur plusieurs groupes de machines, avec des tags pour ne rejouer que ce qui est nécessaire.
Entre les deux, une idée a traversé absolument toutes les sections de cette formation, et c’est elle qu’il faut retenir avant tout le reste : décrire un état voulu, jamais une suite d’actions. C’est ce qui distingue un playbook Ansible d’un script shell — et c’est cette idée qui aurait évité, chez Nordika, la nuit où un script à moitié exécuté a laissé la moitié du parc dans un état incohérent.
Ce que vous savez faire maintenant
- Comprendre pourquoi Ansible est agentless, et ce que ça change concrètement au quotidien.
- Construire un inventaire propre, avec la bonne variable au bon endroit —
host_vars,group_vars, ou directement dans l’inventaire, selon ce qui est réellement partagé. - Écrire un playbook idempotent, et savoir reconnaître quand il ne l’est plus.
- Adapter un playbook au contexte réel de chaque machine, avec les facts et les conditions.
- Générer des configurations dynamiques avec Jinja2, plutôt que de dupliquer des fichiers statiques.
- Structurer votre travail en rôles réutilisables, et savoir quand piocher dans Ansible Galaxy plutôt que réinventer.
- Gérer des comptes, des clés SSH, et des droits sudo sur toute une flotte en une seule exécution.
- Protéger vos secrets avec Vault, sans jamais les laisser en clair dans Git.
- Orchestrer un déploiement multi-groupes, avec la prudence nécessaire (
serial) pour ne pas tout risquer d’un coup.
Ce qui reste à explorer, si vous voulez aller plus loin
Cette formation vous donne une base solide pour administrer votre propre parc, mais Ansible est un écosystème large. Quelques pistes pour la suite, si l’envie vous prend :
- Molecule : tester un rôle de façon automatisée, avant de le déployer sur de vraies machines.
- AWX / Semaphore UI : une interface web par-dessus
ansible-core, pour planifier des exécutions, gérer les accès en équipe, et suivre l’historique des runs — vous en trouverez d’ailleurs sur ce site, dans les catégories dédiées. - Les inventaires dynamiques : générer l’inventaire automatiquement depuis une source externe (un cloud provider, une CMDB) plutôt que de le maintenir à la main.
- La certification RHCE : si vous voulez valider ces compétences plus formellement, c’est la référence côté Red Hat pour Ansible.
Un dernier mot
Rappelez-vous l’histoire du tout début de cette formation : ce script shell qui plantait à 3h du matin, laissant un parc de serveurs dans un état inconnu. Ce n’était pas un manque de compétence, juste le mauvais outil pour le problème. Avec ce que vous venez d’apprendre, ce genre de nuit blanche n’a plus lieu d’être.
Merci d’avoir suivi cette formation jusqu’au bout. Il ne reste qu’une dernière étape : le grand TP final, où vous allez mettre en pratique l’ensemble de ce parcours sur un scénario complet.