Re: Objectif du logiciel

Ansible et Rudder n'abordent pas l’automatisation de l’infrastructure avec la même approche :

• Ansible est davantage conçu pour reproduire facilement des actions ponctuelles à grande échelle, là où Rudder permet de définir un état cible pour un ensemble de machines, sans avoir à prendre en compte les différences d’implémentation entre les différents OS, ce qui facilite grandement la maintenance des configurations sur les parcs complexes avec de nombreux OS / distributions / versions.
• Rudder permet de switcher du mode Audit au mode Configuration en un clic pour un ensemble de règles ou de machines, là où Ansible nécessite de créer des jobs différents. Sur les parcs à très large volumétrie, ne pas avoir à faire deux fois le travail est appréciable.
• Côté réseau, Ansible plus lourd en utilisation continue avec exécution régulière puisqu’il transfère l’agent et l’intégralité de sa configuration en SSH à chaque exécution, là où l’architecture distribuée de Rudder avec ses agents autonomes qui ne récupèrent que le différentiel de leur configuration en pull a permis à certains utilisateurs de bénéficier de l’automatisation sur du réseau mobile avec une bande passante très limitée. Si on s’en tient à ça, on pourrait penser que les outils permettent d’aboutir aux mêmes résultats, juste avec une approche ou des échelles différentes.

Cependant, au delà de la dimension conceptuelle, il y a aussi de véritables spécificités fonctionnelles :

• Rudder étant orienté Configuration Continue, il ne peut pas fonctionner en mode Agentless comme Ansible, et donc du coup ne peut gérer d’équipement réseau. C’est le revers de la médaille d’avoir toute l’intelligence dans l’agent. Après comme il est écrit en C, il est léger et rapide ce qui lui permet d’être utilisé jusque dans de l’embarqué.
• Ansible est un outil d’infra-as-code qui nécessite d’écrire du code pour automatiser. Rudder dispose d’une interface de gestion avec un éditeur en drag-&-drop qui permet à les administrateurs de tout niveau et toute spécialisation d’utiliser la solution. Avec AWX, Ansible dispose d’une interface de planification et de visualisation, mais toujours pas d’édition.
• Dans le prolongement de ça, Rudder a vraiment été conçu comme une solution destinée à une équipe IT, et pas seulement un expert en infra-as-code. Du coup, au delà de l’interface de gestion, un workflow de validation des changements permet de laisser la main à un junior, un nouveau membre de l’équipe, un développeur, etc. sur certains sujets ou agents seulement, avec une double validation d’un pair avant application.

Après c’est peut-être un détail suivant l’utilisation mais je pense que ça peut compter à partir d’une certaine criticité et/ou volumétrie dans le parc géré : Rudder est une solution professionnelle utilisée par de nombreux clients ce qui donne au logiciel une meilleure stabilité par rapport au mode upstream d’AWX.

Dans la pratique, on découvre d’autres différences, mais pour faire une réponse pas trop longue, je pense que ce sont les principales. Au final ce qu’il faut retenir, c’est que les deux outils sont davantage complémentaires que concurrents. Une bonne partie des utilisateurs Rudder utilisent les deux outils. Il existe d’ailleurs un plugin Ansible permettant de se connecter à Rudder afin d’utiliser les groupes construits sur les données d’inventaires plus complètes que Rudder récupère.