Ansible par la pratique (1) – Présentation

Début 2024, l’École des Mines d’Alès m’a contacté pour me demander de dispenser un cours sur Ansible à partir de la rentrée. Après mes cours annuels de culture générale autour d’Unix, de Linux et de l’Open Source et mes ateliers pratiques sur Git et sur Docker, ce sera donc le quatrième cours pour les administrateurs et les développeurs en herbe que l’École des Mines me confie. Comme d’habitude, j’ai décidé de publier l’intégralité de mes supports de cours sur ce blog.

À qui s’adresse cette formation ?

• À mes étudiants en troisième année à l’École des Mines d’Alès.
• Plus généralement, à tous les administrateurs système qui souhaitent remplacer leurs configurations manuelles et autres scripts shell par quelque chose de plus moderne.

Dans le bon vieux temps

Nos ancêtres chassaient l’ours à mains nues et administraient leurs serveurs grâce à une panoplie de scripts shell avec un os dans le nez :

• L’installation et la configuration d’un serveur pouvait durer des heures voire des journées entières.
• L’administrateur était familiarisé avec chacune des options dans chacun des fichiers de configuration, dont la plupart étaient d’ailleurs soigneusement documentées dans une série de fichiers README.txt.
• En cas de problème, un gourou Unix pouvait poser la main sur la machine et deviner la source du problème par simple magnétisme chamanique.

Certes, cette façon de procéder avait ses limites :

• Les installations n’étaient pas toujours bien documentées.
• Un service installé sur la machine 10.23.45.10 ne fonctionnait pas tout à fait comme celui de la machine 10.23.45.20, mais ça restait un mystère.
• Ces dérives de configuration agaçantes ont d’ailleurs engendré le terme de snowflake server en vertu du fait qu’il n’existe pas deux flocons de neige identiques sur la planète.
• L’automatisation de la configuration avec les scripts shell ou Perl réservait également son lot de surprises.
• Sans parler du fait que si vous devez gérer un parc conséquent de machines, l’approche manuelle devient tout bonnement ingérable.

Ansible c’est quoi ?

Ansible est un outil qui permet de résoudre tous ces problèmes décrits un peu plus haut :

• Ansible est écrit en Python.
• Les hôtes sont gérés grâce à SSH et ont uniquement besoin de Python.
• Plus concrètement, Ansible fonctionne sans agent et sans le moindre service spécifique sur les systèmes cible.
• Ansible utilise principalement YAML (YAML Ain’t Markup Language) comme langage de configuration.
• Des milliers de modules sont disponibles pour les tâches d’administration courantes et moins courantes.
• Ansible est très bien documenté.

En 2012, Michael DeHaan a présenté la première version d’Ansible. Sa société Ansible Inc. a été rachetée par Red Hat en 2015. Depuis, c’est Red Hat qui gère principalement le développement d’Ansible, ce qui n’est pas plus mal.

Le terme « Ansible » est issu de la science-fiction, et plus précisément des romans d’Ursula Le Guin. Dans ce contexte littéraire, un Ansible est un appareil qui permet de communiquer à une vitesse supérieure à celle de la lumière.

Ce n’est peut-être pas une mauvaise idée de préciser ce qu’Ansible n’est pas :

• Ansible n’est pas un clicodrome. Il est constitué d’une série d’outils en lignes de commande et d’une collection de fichiers de données, et il s’agit avant tout de comprendre et de maîtriser tout ça.
• Ansible n’a pas un niveau d’abstraction très élevé. Autrement dit, vous ne pouvez pas dire à Ansible quelque chose comme « Z’y va, installe-moi un serveur web ». Dans ce cas concret, vous devrez tout lui expliquer étape par étape : « Installe le paquet httpd, lance le service httpd et active-le au démarrage, ouvre les ports 80 et 443 dans le pare-feu firewalld, etc. »

Quelques gros mots pour commencer

Chaque nouvelle technologie vient invariablement avec son lot de termes techniques et autre charabia. Une petite mise au point s’impose ici avant de commencer.

• L’inventaire (inventory) c’est la liste des machines censées être administrées par Ansible. La confection de cette liste fait partie du travail de l’administrateur.
• Les playbooks sont des procédures créées par l’administrateur. Elles décrivent en détail toutes les tâches à effectuer pour atteindre un objectif de configuration.
• Les modules sont en quelque sorte des unités fonctionnelles d’Ansible. Ce sont eux qui font le travail à proprement parler. Chaque étape d’un playbook n’est en fin de compte rien d’autre que l’appel d’un module.
• Les rôles servent avant tout à rendre un grand projet modulaire, de manière à ce que votre travail soit facilement réutilisable.

Ne vous inquiétez pas si tout cela ne vous paraît pas très parlant pour l’instant. Vous aurez l’occasion d’assimiler tous ces concepts dans une série d’ateliers pratiques.

Lire la suite : Un labo pour Ansible.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.