Avec Ansible 2.0, Red Hat dope les capacités de son outil d'automatisation

Avec un coeur entièrement réarchitecturé, Ansible, désormais sous le contrôle de Red Hat affiche ses ambitions sur le marché de l'automatisation des infrastructures IT. LeMagIT fait le point sur la dernière mouture de l'outil

Ansible 2.0, la première version majeure de l’outil d’automatisation de datacenter open source publiée sous l’égide de Red Hat veut devenir une référence dans les grands déploiements et les déploiements cloud.

En développement depuis près d’un an, cette nouvelle mouture a nécessité une refondation du back-end du logiciel afin d’atteindre ses objectifs ambitieux en matière de support des déploiements à grande échelle. Elle apporte également de nouvelles fonctions tout en tentant de préserver la compatibilité avec les versions antérieures.

Comme l’explique Andrew Smith, un analyste de Technology Business Research, il paraît naturel d’assumer que Red Hat n’a pas joué un rôle important dans la restructuration de la base de code d’Ansible, l’éditeur au chapeau rouge n’ayant acquis Ansible qu’en octobre 2015. Selon Smith, Red Hat devrait continuer à laisser les équipes d’Ansible relativement libre de définir leurs roadmap dans l’avenir.

Une version réarchiecturée pour supporter des déploiements à très grande échelle

La restructuration du cœur du code d’Ansible était vue comme une étape obligée par les porteurs du projet mais il y a encore pas mal de travail à effectuer pour ouvrir Ansible et renforcer la roadmap en collaboration avec la communauté d’utilisateurs de l’outil estime Serge van Ginderachter, le fondateur de Ginsys, une SSII belge spécialisée dans l’automatisation de l’exploitation IT. Van Ginderachter contribue au code d’Ansible depuis plus de trois ans.

Ansible Tower, le tableau de bord permettant la supervision de l’outil est actuellement un logiciel propriétaire développé par Ansible au-dessus du cœur Open source du produit. L’outil fournit une couche d’administration supportant la gestion par rôle, l’audit des opérations, le suivi des changements, etc. Mais les contributeurs clés d’Ansible ont encore un trop fort contrôle sur la roadmap de l’outil estime van Ginderachter. Si l’on s’en réfère aux pratiques passées de Red Hat, cela pourrait évoluer. Ansible pourrait se convertir au modèle 100 % open source de Red Hat, qui rend le code de l’outil librement disponible mais contraint les utilisateurs à payer pour des packages de support.

Ansible 2.0 inclut plus de 150 nouveaux modules issus de la communauté et des contributeurs cœurs de la plate-forme. Certains de ces modules permettent à l’outil de mieux interagir avec VMware vSphere et avec les architectures cloud d’Amazon AWS, de Microsoft Azure ou de Google Cloud Platform, ainsi qu’avec OpenStack et Windows Server. L’acquisition par Red Hat devrait d’ailleurs ouvrir un peu plus Ansible au monde de Windows et surtout à celui de Microsoft Azure.

Si Ansible est traditionnellement déployé dans des datacenters, la version 2.0 met en avant des liens plus étroits avec les grands fournisseurs de services clouds, dans la perspective de répondre aux demandes des entreprises qui souhaitent pouvoir automatiser des architectures de cloud hybrides.

Parmi les autres améliorations on note aussi une meilleure gestion des erreurs, un reporting amélioré pour la découverte des problèmes, de nouveaux modes d’exécution permettant des mises à jour non séquentielles à l’échelle d’une ferme de serveurs, et aussi une portabilité accrue.

Ansible : un maillon de la chaine d'automatisation de l'IT

Le principal atout d’Ansible reste sa simplicité. Les administrateurs systèmes qui créent des scripts shell peuvent automatiser des tâches aussi simplement qu’un développeur maîtrisant des langages plus sophistiqués.

Le modèle en mode push d’Ansible « est excellent pour déployer des applications indique Stein Inge Morisbak, le gérant de Bekk Consulting AS, qui travaille avec plus grands acteurs du secteur public et privé en Norvège. L’apprentissage de l’outil est selon lui facile et l’absence d’agents fait que l’on peut utiliser Ansible sans disposer d’un accès root à l’infrastructure. Morisbak utilise actuellement la dernière version, la 2.0.0.2, pour la plupart de ses projets, même s’il a dû faire un rollback vers la version 1.9x pour un projet spécifique du fait d’un problème avec les grandes arborescences de fichiers dans un playbook avec la dernière version.

La difficulté n’est pas dans la création d’un script d’automatisation explique Morisbak, mais plutôt dans la modélisation de tâches et dans la gestion de systèmes IT complexes. Il souhaite notamment voir émerger des fonctions améliorées de gestion de cycle de vie des applications dans des outils comme Ansible.

L’un des atouts d’Ansible est que comme l’utilisateur n’a pas à apprendre un langage spécifique, l’outil peut être largement partagé à l’échelle d’une organisation par des profils d’utilisateurs très différents. Comme d’autres outils devOps tels que Chef ou Puppet, Ansible s’intègre bien avec des outils d’intégration continue comme Jenkins, même s’il peut aussi être utilisé de façon autonome. Les grandes entreprises marient aussi fréquemment Ansible avec d’autres outils de gestion de processus comme ServiceNow, HEAT or BMC Remedy. Ansible s’intègre également dans la stratégie Cloud de Red Hat du fait des liens étroits avec OpenStack explique Smith.

Van Ginderachter, confirme aussi la capacité d’Ansible a s’intégrer avec d’autres outils : « Il est facile de démarrer des tâches simples avec Ansible, mais l’outil est aussi capable de fonctionner à une échelle bien plus vaste ». Pour l’instant, il explique qu’il utilise majoritairement Ansible 1.9, tout en testant occasionnellement  la version 2.0. Il estime préférable d’attendre la version 2.0.1 ou 2.0.2 avant d’adopter la nouvelle version à plus grande échelle.

Notons que la sortie d’Ansible 2.0 coïncide avec la mise à jour de l’interface utilisateur Ansible Galaxy. Lancé à l’origine en 2014, permet aux utilisateurs d’Ansible de partager des scripts et des réalisations. À ce jour plus de 4 000 rôles ont été partagés via Galaxy, par près de 1 200 auteurs. Le supermarché Chef, une communauté similaire pour les recettes (ou « Cookbook » de Chef) compte près de 2 700 recettes et près de 66 000 membres.

Pour améliorer l’automatisation et l’administration de leurs systèmes, de nombreuses grandes entreprises choisissent l’un ou l’autre des grands outils de configuration comme Chef, Puppet, Salt ou Ansible, explique Smith. Il explique que Chef et Puppet proposent chacun une déclinaison « entreprise » de leur plate-forme en complément de la version open source communautaire.

Quel évolutions futures pour Ansible ?

Intégré à Red Hat, Ansible devrait à terme soigner son intégration avec Satellite afin de gérer l’orchestration du changement sur la plate-forme Red Hat mais aussi s’intégrer avec CloudForms pour simplifier la gestion et l’automatisation de clouds. Smith estime toutefois que les outils resteront séparés : « La couche de gestion des configurations est une couche clé pour l’avenir de Red Hat, c’est pourquoi la firme devrait laisser une grande liberté à Ansible pour développer sa roadmap ». En maintenant Ansible et Satellite séparés, Red Hat peut incuber les meilleures idées et choisir les innovations qui intéressent le plus ses clients.

Morisbak s’attend de son côté à voir émerger plus de modules pour gérer les infrastructures en cloud. Parmi ses vœux figure en priorité l’émergence d’outils plus simples pour automatiser la configuration de services de type RESTful. Red Hat, de son côté, ne s’exprime pour l’instant pas sur les intégrations qui pourraient intervenir entre ses différents outils dans la roadmap d’Ansible.

Pour approfondir sur Administration de systèmes