En start-up il y a souvent tout à faire. Des choses qu’on aime faire, d’autres qu’on aime moins. Des choses qu’on sait faire, d’autres qu’on maîtrise moins. Mon métier, c’est le développement, et je suis beaucoup moins à l’aise quand il s’agit de gérer une production et donc une infrastructure.
J’ai récemment revu en profondeur l’infrastructure que je gère pour mettre en place de la redondance. Je ne me voyais pas configurer les serveurs à l’identique manuellement, d’abord parce que ça prend du temps et puis parce qu’ils n’auraient justement pas été identiques…
Je me suis donc tourné vers les outils d’automatisation de gestion de machines et mon choix s’est rapidement porté vers Ansible. Et je dois bien avouer que c’est un véritable coup de cœur.
Simple et bien pensé
Comme pour tous les outils, au départ c’est un peu difficile parce qu’il faut comprendre le concept. Mais Ansible c’est simple. Une fois qu’on a compris les 3 choses suivantes, on a tout ce qu’il faut pour commencer :
- Comment déclarer l’inventaire de l’infrastructure (inventory, machines et des groupes de machines)
- Comment modéliser les actions (playbooks) qu’Ansible doit jouer sur les machines
- Comment Ansible se connecte aux machines
Installation facile
Ansible s’installe très facilement et peut s’exécuter depuis sa propre machine. La seule contrainte est que cette machine doit être en mesure de se connecter aux différents serveurs en SSH via une clé (sans demander le mot de passe).
Un écosystème riche
Ansible fournit de base un riche ensemble de modules permettant d’effectuer les tâches les plus courantes très facilement. Installer un paquet système ? Il y a bien entendu ce qu’il faut. Il y a également tout ce qu’il faut pour installer un package npm, redémarrer un service ou bien modifier un fichier de configuration. La documentation est plutôt bien faite et contient pas mal d’exemples.
Facile à prendre en main
On est ainsi rapidement en mesure de configurer une machine vierge sans y accéder manuellement par SSH. Et pas seulement d’ailleurs ! Une fois que la machine est installée, Ansible est capable de la faire évoluer. En effet, un scénario Ansible ce n’est pas une simple succession d’instructions comme on le ferait dans un script. Plutôt que de définir des commandes, on décrit des états. Par exemple, je veux que tel paquet soit installé ou que tel fichier n’existe pas ou contienne telles lignes. Tous les modules Ansible fonctionnent sur ce principe et agissent seulement si il y a quelque chose à faire. Et si le résultat attendu est déjà là, tant mieux il n’y a rien à faire. Gérer ça manuellement dans un script, c’est très difficile. Avec Ansible, c’est automatique !
Pensé pour les développeurs
Avec Ansible, c’est un peu comme si on décrivait son infrastructure dans du code via un DSL (basé sur YAML en l’occurrence). Pour un développeur c’est cool parce que c’est ce qu’on est habitué à faire et, accessoirement, on peut versionner cette configuration. On est d’ailleurs confrontés à des problématiques similaires, notamment la réutilisation de certaines parties. A travers les rôles, Ansible propose une solution élégante et efficace pour factoriser des briques communes et, là encore le développeur s’y retrouve facilement parce que ça ressemble beaucoup à concepts de programmation qu’on utilise au quotidien.
Gérer plusieurs machines simultanément
Les playbooks Ansible sont des opérations à appliquer sur un ensemble de machines. Lorsqu’on lance un playbook, Ansible va se connecter à tous les serveurs concernés en parallèle et jouer les différentes étapes du scénario.
On peut ainsi en une seule commande configurer intégralement une nouvelle machine. Ou peut également appliquer des changements sur l’ensemble ou une partie seulement des machines du par, par exemple exécuter le playbook de configuration d’une machine de type base de données sur l’ensemble des machines du groupe correspondant.
En utilisant des fonctionnalités plus avancées, on peut également jouer des scénarios plus complexes comme la mise à jour d’un parc de machine en rolling release pour éviter toute coupure de service.
Le mot de la fin
J’ai essayé Ansible et je l’ai immédiatement adopté. C’est un véritable coup de cœur, un outil simple à prendre en main et conçu pour répondre aux enjeux majeurs de l’automatisation d’infrastructure.
Je m’y suis mis petit à petit et je gère désormais l’ensemble de mon infrastructure grâce à lui et il me fait gagner beaucoup de temps au quotidien.
De par sa conception il ne nécessite pas que les machines aient été installées ou configurées préalablement via son intermédiaire. On peut très facilement l’utiliser au début pour effectuer quelques petites tâches simples comme l’installation des mises à jour sur l’ensemble des machines du parc.
L’image d’en-tête provient de Wikimedia Commons.
As-tu déjà zieuté vers Pyinfra ? https://github.com/Fizzadar/pyinfra Le mec s’inspire fortement d’Ansible, mais on déclare tout en pur Python. Ça me paraît une bonne solution pour commencer à gérer une infrastructure, au lieu de me plonger dans la doc Ansible.
Merci pour ce commentaire !
Non, je ne connais pas Pyinfra. Je viens d’y jeter un coup d’œil, et d’après ce que je comprends, la principale différence c’est qu’on utilise un DSL en Python plutôt qu’en YAML pour décrire l’infrastructure.
Je n’ai pas une grande expérience avec Ansible, mais je n’ai pas vraiment vécu de frustration par rapport au fait qu’on décrit l’infrastructure en YAML. Qu’est-ce qui te ferait pencher pour une déclaration en Python plutôt qu’en YAML ? Pour ce qui concerne la lecture de la documentation, tu crois que ce serait vraiment plus simple en Python ?
Eh bien le « DSL en python » n’est pour moi pas un DSL, d’où l’intérêt 🙂 C’est une contrainte en moins dès le départ, et ça supprime les limitations qu’on pourrait avoir avec un DSL, puisqu’on écrit le python qu’on veut. J’ai lu des articles râlant sur des limitations d’Ansible de l’époque, à priori corrigées (des répétitions obligatoires, etc), ce qui aurait été dépassable en python. Écrire du python me permettrait d’être plus flexible pour aller chercher de la conf à droite et à gauche, écrire quelques règles métiers, etc. Enfin quoi, il me semble que c’est bienvenu. Chef et Puppet sont l’un en Ruby l’autre avec son propre DSL, Ansible en yaml est déjà mieux… Pyinfra est peut être souhaitable pour les dévs python.
Ok, je vois l’idée. Je ne sais pas comment était Ansible il y a quelques années, et j’ai moi aussi lu pas mal de choses concernant ses limitations en terme de répétitions / duplications.
Lorsque j’ai pris en main Ansible, j’étais contraint de faire pas mal de duplication, je ne savais pas faire autrement. En cherchant, j’ai vite trouvé la possibilité d’inclure des fichiers (ça fait un peu comme un appel de fonction en programmation) via le module include. Mais je n’étais toujours pas très satisfait du résultat. En continuant de creuser, j’ai découvert les rôles, c’est assez récent je crois et ça m’a permis de résoudre beaucoup de problématiques de partage de code. Maintenant que je maîtrise mieux ce concept, j’arrive à faire à peu près tout ce que je veux sans duplication et donc sans frustration.
Je pense que les rôles ont pas mal changé la donne. Cela dit, c’est aussi tout à fait possible que mes cas d’utilisation soient assez simples et que dans des situations plus complexes j’aurais plus besoin d’expressivité. Je n’ai pas suffisamment de recul sur cette question pour le dire. En tout cas à chaque fois que j’avais à faire quelque chose que je ne savais pas bien faire, j’ai bidouillé un peu au début avec ce que je savais faire puis j’ai trouvé une solution adaptée au problème qui était souvent simple, élégante et efficace.
Ok merci ! Si jamais j’apprends des avantages pratiques à pyinfra je reviens ici ou sur le journal du hacker 🙂
Ok, super ! Ça m’intéresse ! Pyinfra a sans doute d’autres avantages, notamment la rapidité d’exécution d’après ce que j’ai compris. Et même si ça ne m’a pas gêné, le manque d’expressivité est peut-être un problème pour d’autres.