Découverte d'Ansible

Comment j'ai découvert Ansible et à quoi ça sert ?

Autant l'annoncer d'entrée de jeu : je n'ai que très peu d'expérience de cette plate-forme.

Cependant, je pense que partager mes premières impressions sur cet outil pourrait intéresser le lecteur avec le même profil débutant que le mien. Il existe bien un rapport d'étonnement pour le nouvel arrivant dans une entreprise.

Ansible : qu'est ce que c'est ?

Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs Wikipedia

C'est un outil libre qui permet l'automatisation des configurations des ordinateurs, à distance le plus souvent. Il a comme concurrent les solutions Puppet et Chef.

Il m'est arrivé de changer plusieurs fois de serveur, histoire de jouer ou d'installer des nouveaux trucs. Le plus souvent pour changer de crèmerie pour des questions de coûts ou d'éthique.

Presque à chaque fois, car je ne me sers que rarement des solutions préconfigurées des hébergeurs (type Wordpress), il faut tout re-configurer. On choisit le système d'exploitation, les caractéristiques de coeur, RAM et espace disque et puis c'est tout ; après c'est un terrain vierge. Je serais bien content si je pouvais ne pas tout refaire à chaque fois.

Exemple de tâches quasi systématiques sur un nouveau serveur :

• générer et copier sur le serveur des clefs SSH
• interdire la connexion root directe sur le serveur
• installer un serveur web
• ...

A quoi ça sert ?

La présentation est faite in extenso sur le site d'Ansible mais voilà ce que j'en ai compris :

Ansible va permettre de créer des modèles de configuration de serveur (on appelle ça des playbooks) et les appliquer autant de fois qu'on le veut à autant de serveur que l'on veut. Ces modèles sont sous la forme de fichiers textes dont la syntaxe obéit au format Yaml (du texte avec des indentations, donc simple).

Il est possible de grouper les serveurs selon leur type, leur fonction, bref de trouver une taxonomie personnelle afin d'y appliquer ce playbook. Du coup, s'il y a beaucoup de serveurs, c'est très pratique.

Possible aussi de détacher les choses à faire décrites dans les playbook par sous-tâches réutilisables, on appelle ça des "roles" je crois.

L'analogie avec les recettes de cuisine est souvent employée pour comprendre tout cela. Un playbook est une recette, les "roles" sont des sous-recettes dont on se sert régulièrement et les ingrédients de base seraient les "modules".

Exemple :

1. Mon playbook - ma recette - est une charlotte aux poires
2. J'ai besoin d'ingrédients de base (les modules) : les poires, le sucre, l'eau, les oeufs
3. Pour faire la charlotte il me faut passer par l'étape - le "role" - des oeufs en neige (prendre des oeufs, les casser, prendre les blancs, les battre)
4. J'itère avec les autres étapes nécessaires et je mélange le tout pour obtenir ma recette à la fin

Il existe d'autres notions comme celle, importante, de "host" qui représente le serveur ou le groupe de serveur que vous voulez configurer. Un peu comme le convive ou la table (avec plusieurs convives) sur laquelle vous allez mettre la charlotte. Et aussi le "handler" qui permet de conditionner certaines actions à des états, un peu comme si je disais "ne pas mélanger les oeufs avec les poires tant que ceux-ci ne sont pas montés". (Bon alors je ne sais pas trop si l'analogie tient jusque là mais c'est l'idée).

Et il existe des bibliothèques de bouquin de cuisine qui se retrouvent sur ce que Ansible appelle sa "Galaxy".

Est ce que c'est pour moi ?

J'ai découvert Ansible parce que les SysAdmin de FAImaison l'utilisaient et que ces fichiers textes semblaient simples.

Je me suis d'abord dit que cela ne me servirait à rien car c'est clairement un outil pour automatiser sur de nombreux serveurs, c'est là que le facteur d'échelle est utile. Moi avec mes deux ou trois serveurs, je ne suis pas sûr que cela vaille la peine de m'y investir. Mais on m'a également fait remarquer que peu importe le nombre de serveur, c'est aussi la portabilité des configurations qui donne sa véritable utilité à la plate-forme. Qu'il y ait une liste avec deux ou deux cent serveurs ne change pas fondamentalement l'affaire (la charlotte aux poires c'est bon et donc c'est utile d'en avoir une recette, après si deux ou deux cents personnes en mangent en même temps, bah c'est autre chose).

Pour garder tout cela au chaud et améliorer au fur et à mesure sans rien perdre en cas de soucis, il convient d'utiliser git comme gestionnaire de version.

Ce que j'aime dans Ansible

• Il n'y a presque rien besoin d'installer à part Ansible lui-même sur la machine qui contrôle les autres. Tout se passe via ssh ; c'est le seul pré-requis.
• Pouvoir sauvegarder ses configurations. Hop, on pourrait donc changer de serveur comme de chemise et l'information importante, la mémoire de vos petits réglages est enfin sauvegardée.
• Un formalisme simple à comprendre, un peu comme les fichiers markdown
• Une description d'un état à atteindre sur un serveur, et la description précise de cet état plutôt qu'un snapshot qui fige un état à un moment donné. Un peu comme si on avait le fichier raw d'une photo numérique plutôt que la photo sur papier (c'est osé)
• Le nombre très élevé de modules et playbooks disponibles sur Galaxy
• C'est libre !
• J'ai même trouvé une recette qui installe Yunohost, même si elle est à l'abandon maintenant

Ce que j'aime moins

• Même si Red Hat, qui soutient le projet, se donne beaucoup de mal pour rendre les choses faciles, la courbe d'apprentissage n'est pas évidente
  • En particulier les différentes notions évoquées plus haut peuvent se compliquer très rapidement
  • J'ai un peu de mal avec les systèmes d'imbrications des roles, hosts, handlers et autres variables, je m'y perds facilement
• Quand bien même je connaitrais mieux Ansible, il faut quand même avoir de bonnes notions d'administration système pour savoir ce qu'il faut mettre dans les playbooks.
• Le temps à filtrer la documentation pour n'y trouver que ce qui m'intéresse.

Le mot de la fin

Bon, je trouve ça cool Ansible. J'aimerais bien m'y mettre plus sérieusement mais beaucoup de choses passent avant.

Je pense qu'il faut que je commence petit pour compliquer petit à petit sans me décourager mais vois bien qu' à un moment je serai limité par mes connaissances en administration système. Et pour l'instant, le système de backup de Yunohost pour une réinstallation sur une nouvelle instance me convient bien.

Enfin, j'ai lu dans Linux Pratique qu'Ansible faisait vraiment partie de la boîte à outil centrale du DevOps (oui c'est logique). Je connais déjà un peu les autres composants (VirtualBox, Git, LetsEncrypt, Docker...) et donc cela me donne envie de me perfectionner. A suivre donc !