Pas vraiment. Rudder remplit une fonction similaire à Ansible, dans le sens où il gère des configurations, mais le fonctionnement est très différent : pour commencer, Rudder fonctionne avec des agents locaux à chaque machine gérée (agent léger et très performant, écrit en C), là où Ansible se connecte en SSH ou similaire pour exécuter des commandes distantes. Il en résulte une panoplie de différences, la décentralisation et l'autonomie de chaque machine notamment, la charge réseau, la capacité de passer à l'échelle sur des dizaines de milliers de noeuds, etc.
Le mode "dry-run", Rudder l'a aussi (tout comme Ansible d'ailleurs) mais Rudder va bien plus loin en remontant une vraie conformité sur chaque item. Là où un mode dry-run "essaie" tout mais ne fait rien, la conformité dans Rudder va remonter un rapport propre à chaque configuration avec un status (OK, réparé, erreur, sommairement), donc beaucoup plus fin qu'un mode dry-run. Sur une machine, ca ne change pas grand chose, certes, la puissance réside en la capacité d'agréger ces rapports pour avoir une vision d'ensemble sur un parc.
Un cas d'exemple : on veut savoir si un élément de sa politique de sécurité, disons l'auto-logout du terminal, est bien appliqué sur un parc, on crée la config dans Rudder en mode "audit", il vérifie sur tous les noeuds, dit qqch comme "OK à 96%", et là 1) on sait où on en est, et 2) on peut décider de forcer la config (passage en mode "enforce") sur les 4% restants si c'est des machines où on accepte le risque, et ainsi l'appliquer partout. Ensuite, la config est vérifiée en continu, et on a une alerte dès qu'une machine n'est pas OK.
Le paramétrage peut être graphique, oui, il peut aussi être fait en CLI ou via l'API REST complète. En pratique, on a tendance à écrire les modules plutôt en dehors de l'interface graphique, puis on assemble des modules avec leurs paramètres dans l'interface graphique. L'idée fondamentale étant de faire des modules très génériques (contenu d'un fichier, état d'installation d'un paquet, existence d'un utilisateur, etc - comme les modules d'Ansible, et oui il y en a moins, mais ca suffit dans beaucoup de cas :-) ) et de batir avec ces briques les configurations plus complexes.
Une vidéo vaut peut être mieux qu'un long discours, c'est une démo sur la version précédente, mais ca montre les concepts qui sont les mêmes : https://www.youtube.com/watch?v=_N_Xbs_yRaw
[^] # Re: Objectif du logiciel
Posté par Jonathan Clarke . En réponse à la dépêche RUDDER 4.3 : une nouvelle version qui consolide les fonctionnalités majeures. Évalué à 7.
Pas vraiment. Rudder remplit une fonction similaire à Ansible, dans le sens où il gère des configurations, mais le fonctionnement est très différent : pour commencer, Rudder fonctionne avec des agents locaux à chaque machine gérée (agent léger et très performant, écrit en C), là où Ansible se connecte en SSH ou similaire pour exécuter des commandes distantes. Il en résulte une panoplie de différences, la décentralisation et l'autonomie de chaque machine notamment, la charge réseau, la capacité de passer à l'échelle sur des dizaines de milliers de noeuds, etc.
Le mode "dry-run", Rudder l'a aussi (tout comme Ansible d'ailleurs) mais Rudder va bien plus loin en remontant une vraie conformité sur chaque item. Là où un mode dry-run "essaie" tout mais ne fait rien, la conformité dans Rudder va remonter un rapport propre à chaque configuration avec un status (OK, réparé, erreur, sommairement), donc beaucoup plus fin qu'un mode dry-run. Sur une machine, ca ne change pas grand chose, certes, la puissance réside en la capacité d'agréger ces rapports pour avoir une vision d'ensemble sur un parc.
Un cas d'exemple : on veut savoir si un élément de sa politique de sécurité, disons l'auto-logout du terminal, est bien appliqué sur un parc, on crée la config dans Rudder en mode "audit", il vérifie sur tous les noeuds, dit qqch comme "OK à 96%", et là 1) on sait où on en est, et 2) on peut décider de forcer la config (passage en mode "enforce") sur les 4% restants si c'est des machines où on accepte le risque, et ainsi l'appliquer partout. Ensuite, la config est vérifiée en continu, et on a une alerte dès qu'une machine n'est pas OK.
Le paramétrage peut être graphique, oui, il peut aussi être fait en CLI ou via l'API REST complète. En pratique, on a tendance à écrire les modules plutôt en dehors de l'interface graphique, puis on assemble des modules avec leurs paramètres dans l'interface graphique. L'idée fondamentale étant de faire des modules très génériques (contenu d'un fichier, état d'installation d'un paquet, existence d'un utilisateur, etc - comme les modules d'Ansible, et oui il y en a moins, mais ca suffit dans beaucoup de cas :-) ) et de batir avec ces briques les configurations plus complexes.
Une vidéo vaut peut être mieux qu'un long discours, c'est une démo sur la version précédente, mais ca montre les concepts qui sont les mêmes : https://www.youtube.com/watch?v=_N_Xbs_yRaw