valentin.napoli a écrit 3 commentaires

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.

C’est une vaste question qui mériterait un article à part entière tant les différences sont nombreuses. Mais afin que la question ne reste pas sans réponse ici, allons-y ! :)

--

1) Côté opérationnel

A] Conformité en continu

Rudder se distingue de Puppet sur 2 axes :

• fonctionnel
• technique

D’un point de vue fonctionnel, ça se traduit en premier lieu par une vérification en continu de la conformité, avec remédiation automatique → Puppet a récemment raccroché les wagons sur ce point, mais il reste 2 différences avec Rudder : l’une se trouve au point suivant ; l’autre est le mode “ audit “ qui permet à Rudder d’auditer un parc sur la base de l’état cible visé sans pour autant faire la moindre modification. Ce mode audit peut être défini pour l’ensemble de Rudder, comme pour une sous-partie des machines gérées et/ou seulement certaines règles.

Techniquement, ce qui permet cette vérification continue, c’est avant tout :

• l’agent en C plutôt qu’en Ruby comme sur Puppet → il est du coup plus léger (10 à 20 Mo de RAM) et plus rapide (il peut appliquer une centaine de règles sur une machine en moins de 10 secondes). Rudder est ainsi capable de fonctionner sur des machines aux capacités restreintes sans perturber leur fonctionner là où l’ampleur et les performances de la stack Ruby ne facilitent pas la gestion continue des matériels historiques et/ou embarqués.
• une architecture distribuée → les agents récupèrent leur configuration auprès du serveur central (ou de serveurs relais), pour répartir la charge ce qui permet à un seul serveur Rudder de gérer plus de 10 000 agents.

B] Une solution d’équipe vs un outil d’expert

En parallèle de cette orientation conformité en continu, Rudder a été conçu pour être utilisé pour l’intégralité d’une équipe IT, et pas seulement un expert en infra-as-code.

Fonctionnellement ça se traduit par :

• une interface web de gestion avec templates inclus et éditeur drag & drop (là où l’interface de Puppet ne permet que de la consultation d’information, et de créer des configurations depuis l’interface sans avoir à développer.) Bien entendu, l’interface n’est pas imposée, il est possible d'écrire du code directement.
• un workflow de validation des changements qui permet de laisser la main à un junior, un nouveau membre de l’équipe, un développeur, etc. sur certains sujets / agent seulements, et avec une double validation d’un pair avant application.
• la possibilité d’exporter des rapports de conformité en PDF pour un auditeur, un client, son RSSI, etc.)

Du coup Rudder s’adresse aussi bien :

• au Responsable qui souhaite visualiser l'état réel du parc sur des graphiques clairs et concis, pour s'assurer que la politique de sécurité est bien appliquée sur l'ensemble du parc,
• pour l’Ingénieur qui doit construire une chaîne d'outils capables d’interagir entre eux grâce à l'API.
• pour l’Administrateur qui configure les machines au quotidien via l'interface web de gestion qui ne nécessite jamais de devoir écrire du code, y compris pour les besoins métier les plus spécifiques, grâce à un éditeur de configuration en drag & drop.

2) Côté business

Enfin, en marge du côté opérationnel, Rudder se distingue aussi par son modèle économique plus proche de l’esprit du Logiciel Libre que du modèle à deux vitesse Open Core vs Enterprise et ses effets pervers. Rudder n’existe qu’en version libre. Des fonctionnalités à destination des très grosses structures et/ou spécifiques à des cas d’utilisation moins courants, sont disponibles dans des plugins payants.

Les fonctions centrales de Rudder comme l’interface de gestion et l’éditeur en drag-&-drop ne seront jamais rendues payantes, là où l’interface de Puppet est propriétaire.

--

Pfiou ! J’avais prévenu que ça serait long ! Au moins j’espère avoir su répondre de manière complète sur les différences avec Puppet. Après je ne connais pas aussi bien Puppet que Rudder, et je ne suis pas forcément l'évolution du produit au jour près, mais dans les grandes lignes je pense que ce sont les points sur lesquels les deux logiciels se distinguent.

Pour un événement de ce type, vu le lieu, le prix me semble pas exorbitant par rapport à ce qui se pratique ailleurs : https://techbeacon.com/best-devops-conferences-2017
Et pas sûr qu'on y retrouve le confort des gros sièges en cuir du Grand REX pour profiter des confs ;)

Quand aux talks, à devops REX aucun sponsor n'a le droit de faire un talk, contrairement à beaucoup (trop) d'événements IT. Après j'entends que les titres font un peu pub à tes yeux, mais faut bien rendre ça attractif, sinon ils s'appelleraient tous " Retour d'expérience devops chez machin " - " Mise en place devops chez bidule " - " Comment on a mis devops chez truc ". Mais voilà, au delà de l'enrobage marketing ici et là, l'important c'est que le contenu soit des REX authentiques.