Quand on parle d'automatisation de logiciels avec des développeurs et des DevOps, il y a de fortes chances que les noms de Chef et Puppet arrivent dans la conversation. Mais, au cours des 18 derniers mois, le nom d’un moteur d'automatisation open source est de plus en plus cité : celui d’Ansible. Ansible automatise l'approvisionnement logiciel, la gestion de la configuration et le déploiement applicatif. Fondé en 2013, le projet open source a été racheté par Red Hat en 2015 pour un montant estimé à plus de 100 millions de dollars. Ansible ressemble beaucoup à Chef et à Puppet, mais il semble aujourd’hui que c’est de lui que tout le monde parle. Un coup d’œil rapide sur la liste StackShare des 5 outils devops les plus demandés montre que Ansible se situe en 3e position en terme d'offres d'emploi. StackShare considère l'outil comme une compétence nécessaire, juste derrière GitHub et Docker. Red Hat veut également entretenir la popularité d'Ansible : récemment, Jim Whitehurst, le CEO de Red Hat, a déclaré que Ansible entrait dans un tiers de tous les contrats Red Hat.

Alors, qu'est-ce qui rend Ansible aussi attractif ? Selon Paul Delory, directeur de recherche chez Gartner, la raison pour laquelle l’outil a gagné en réputation depuis son acquisition par Red Hat vient peut-être du rachat lui-même. « Comme nous l’avons constaté, l'acquisition par Red Hat a provoqué un surcroît d'intérêt pour le produit, parce qu’il a gagné en crédibilité dans l'entreprise », a-t-il déclaré. Les développeurs de logiciels et la communauté des dévops avaient probablement le sentiment que le support d'Ansible n'était peut-être pas aussi bon que celui de Puppet ou Chef. « Mais, l’arrivée d’Ansible chez Red Hat a comblé cet écart », a-t-il ajouté. « Le support est un élément important pour les entreprises, et la qualité du support disponible est cruciale », a-t-il encore déclaré.

Un fonctionnement sans agent

Mais la popularité d'Ansible ne tient pas seulement à ces nouvelles conditions de support, même si c’est un élément capital pour les clients. Selon Martin Rusev, DevOps d’une entreprise berlinoise qui travaille pour un grand compte, mais aussi pour plusieurs start-ups, dans ces sociétés de petite taille, une partie de la popularité d'Ansible s'explique peut-être par la facilité de la prise en main et de l’utilisation de l'outil. « Cet aspect est important pour les petites entreprises : elles n’ont pas besoin d'un administrateur système dédié pour faire fonctionner Ansible, car n’importe qui peut l’utiliser », explique ainsi Martin Rusev. « Ce qui n’est pas le cas de Chef et de Puppet : il est nécessaire de bien comprendre chaque outil avant de les mettre en œuvre. Ça demande beaucoup plus de temps ». Cependant, il fait remarquer qu’Ansible est également utilisé dans la grande entreprise pour laquelle il travaille, et que beaucoup de grandes entreprises utilisent souvent Ansible combiné à Chef ou à Puppet.

Pour Paul Delory de Gartner, cela s’explique par le fait que dans sa conception, Ansible est fondamentalement différent de Chef et de Puppet. Plus précisément, Ansible fonctionne sans agent : il communique avec les serveurs qu'il contrôle en leur envoyant des « modules » Ansible. Ces programmes sont des sortes de modèles de ressource, fonction de l'état souhaité du système. Et quand Ansible a exécuté ces modèles (en passant par le protocole SSH par défaut), il les supprime. A contrario, Puppet et Chef utilisent tous deux des agents fonctionnant sur les serveurs qu’ils contrôlent. « Chaque approche a ses avantages et ses inconvénients, mais, parce que Ansible est sans agent, il gère plus facilement les commutateurs et les tableaux de stockage », explique le directeur de recherche de Gartner. « Quand on n’est plus dans le domaine du serveur, l'approche sans agent est plus facile. C'est la raison pour laquelle les équipes réseaux (et stockage) se tournent vers Ansible, et les équipes serveurs préfèrent Puppet et Chef ». De la même façon, les développeurs préfèrent Puppet et Chef, construits en Ruby, alors que les devops préfèrent Ansible, basé sur Python. « Généralement, les devops connaissent bien Python. C’est certainement aussi une des raisons pour laquelle ils ont une préférence pour Ansible ».

Pas adapté pour les grands déploiements

Cependant, Paul Delory fait remarquer qu'il existe des solutions pour atténuer la contrainte des agents. « Si vous êtes suffisamment à l’aise avec ces outils, vous pouvez arriver à obtenir ce que vous voulez », a-t-il déclaré. Par ailleurs, il y a une bonne raison pour laquelle Chef et Puppet utilisent des agents : ils peuvent rendre l'automatisation beaucoup plus réactive. « Certes, avec les agents, il y a plus de code et donc plus de bugs possibles. Mais Ansible n'est pas capable d’atteindre la vitesse offerte par un système qui utilise des agents », convient également Martin Rusev. « S'il y a quelque chose avec laquelle je dois interagir quotidiennement, je préfère utiliser un système avec agent, car il est plus simple ». Il ajoute que les problèmes de performance d’Ansible sont aussi plus visibles quand le traitement dépasse la centaine d'hôtes. « Entre 100 et 500, il est préférable peut-être d’utiliser Puppet ou Chef. À certaines échelles, Ansible devient problématique, car il consomme trop de mémoire », explique-t-il encore.

En conclusion, Ansible a la préférence des DevOps parce que sa prise en main est facile et qu’il est simple à utiliser, qu’il est construit sur Python, que son support est crédible et son architecture sans agent permet de contrôler autre chose que des serveurs. L'inconvénient d’Ansible, c’est qu'il ne peut pas être aussi puissant que Chef ou Puppet à partir d’une certaine échelle, qu’il peut souffrir d’un manque de performances - surtout pour les gros déploiements - et son support est encore un peu en deçà de ce que propose ses concurrents. Pour ces raisons, Paul Delory est convaincu que de nombreuses entreprises vont continuer à utiliser Chef et Puppet avec Ansible. « Il ne faut pas croire que les entreprises pourront tout faire avec un seul outil. Beaucoup utilisent d’ailleurs Chef, Puppet et Ansible, pour des tâches différentes. Enfin, peu importe l'outil que vous choisissez. Il y aura toujours des gens pour vous dire que vous avez fait le mauvais choix ».