Les origines d’Ansible remontent à 2006, lors du passage de Michael Dehaan dans le groupe Emerging Technologies chez Red Hat : un incubateur dans lequel il était possible de travailler sur tout ce qui pouvait être utile aux utilisateurs finaux. Red Hat s’intéresse déjà aux outils de gestion de configuration émergents : Puppet et Chef. Puppet sera utilisé pour l’automatisation d’infrastructure dans plusieurs projets (Fedora par exemple) mettant à jour forces et faiblesses (plus tard pour automatiser OpenStack en particulier).

Après Red Hat, Michael Dehaan ira renforcer les rangs de Puppet et notera que le DSL ruby et la complexité de l’outil est parfois un frein à l’adoption.

Après Puppet, la gestion de configuration reviendra régulièrement dans les projets auxquels il participera. Cela fera naitre des idées et permettra surtout des rencontres avec des personnes du développement et de l’IT qui deviendront des acteurs importants de la scène DevOps.

Finalement, les « lessons learned » chez Red Hat, sur le terrain et dans la création de solutions de management des systèmes informatiques conduira inexorablement à la création d’Ansible début 2012. Le projet open source trouvera une résonnance immédiate au sein de la communauté, la commercialisation de Tower (UI web d’Ansible) permettra d’injecter les fonds nécessaires pour faire progresser le projet jusqu’au rachat par … Red Hat !

Analyse par Olivier Robert – DevOps Consultant chez Agile Partner. 

Carte d’identité

Ansible en bref 

Ansible est un outil de gestion de configuration. Comme ces petits camarades (Chef, Puppet, Saltstack, …) il permet de créer des machines (par exemple sur AWS), de les configurer (en installant des logiciels ou en altérant des configurations). Il est également utilisé pour automatiser les actions nécessaires au déploiement d’une ou plusieurs applications.

Ansible est développé en Python et repose sur SSH pour les communications avec les systèmes. Cela en fait immédiatement un outil extrêmement simple à installer et à utiliser puisque Python et SSH font partie des outils standards livrés sur la plupart des serveurs. Autre point remarquable : il n’y a ni serveur, ni agents à installer. Les commandes Ansible sont exécutables sur n’importe quelle machine reliée au réseau, que ce soit une machine dédiée ou l’ordinateur portable d’un ingénieur lors d’une astreinte.

Ansible est mis à disposition sous license GPL : vous êtes donc libre de l’utiliser, d’étudier sont code, de le modifier et de contribuer vos modifications.

L’interface graphique Tower, par contre, est payante. Elle facilite en particulier la traçabilité, ne couvre pas à 100% ce qui peut être fait à la ligne de commande et n’est pas indispensable dans l’opération d’Ansible.

Afin de structurer les commandes que l’on voudra exécuter sur une machine, on éditera un fichier YAML (dont la syntaxe est très lisible) dans lequel on utilisera les différents modules qui nous permettront de déclarer l’état dans lequel nous souhaitons que la machine cible soit. Ce concept est classique dans les outils de gestion de configuration. Plutôt que d’indiquer les commandes à faire sous forme de scripts bash, perl, python ou autres, une librairie de modules Ansible permet cette déclaration d’état. Dès lors, chaque exécution de ce fichier, qu’on appelle un playbook, est idempotente : ce qui n’existe pas est créé, ce qui existe reste inchangé, ce qui existe et à changer est corrigé. Lancer un playbook régulièrement garantit donc l’état d’une machine.

De même que le playbook structure les commandes, les rôles permettent de structurer le playbook pour un usage plus large, plus générique et surtout réutilisable. Le templates Jinja2 et les injections de variables permettent d’adapter un rôle pour différents besoins (environnements, versions de logiciels, …).

La communauté Ansible partage un grand nombre de rôle sur un hub : Ansible Galaxy. Github est également une bonne source pour les playbooks.

On vous le dit !

L’IT devient de plus en plus complexe, de plus en plus couplé. Les interventions humaines de plus en plus sensibles : une des raisons de l’émergences des pratiques DevOps. L’automatisation permet la structuration, la fiabilisation et la répétabilité.

Si vous démarrez une initiative DevOps, choisissez Ansible pour votre automatisation. Si vous avez déjà fait vos armes ou si vous êtes déjà des experts des pratiques DevOps, testez rapidement Ansible. Je suis certains que la plupart des utilisateurs vont être charmés par sa simplicité de mise en place et sa facilité d’utilisation.

Bien entendu, si vous aussi avez fait l’expérience d’Ansible, n’hésitez pas à venir échanger avec nous sur notre blog !