Rudder est un logiciel de gestion de configuration basé sur CFEngine 3 et FusionInventory. Il permet de visualiser les inventaires des serveurs de votre système informatique, de créer des règles pour les configurer, et de voir leur état d'application en temps réel, le tout dans une interface web. L'interface graphique est écrite en Scala, tandis que l'agent de configuration (CFEngine 3) est écrit en C (et est donc très léger). Le tout s'installe très simplement grâce à des paquets tout faits sur de nombreux OS, sous licence libre (licence AGPLv3).
La première bêta de la nouvelle version 2.4 vient de sortir et inclut de nombreuses nouveautés, dont :
- Une API REST
- Gestion simple des autorisations dans l'UI
- Affichage détaillé du reporting niveau par niveau de l'état d'application des règles de configuration sur le SI
- Inventaire des machines virtuelles, variables d'environnement et processus de chaque nœud géré
- Import/export de toutes les configurations via archive ZIP ou dépôt git
- Suivi de toutes les modifications dans l'UI, avec détails et messages de changements
- Très nombreuses améliorations d'ergonomie et de présentation dans l'UI
Utilisation
Rudder peut-être utilisé pour automatiser ou vérifier toute configuration sur des systèmes Linux. Les règles couramment appliquées permettent d'installer des paquets, de vérifier le contenu de fichiers de configuration, d'automatiser la mise à jour d'applications web, d'imposer des politiques de sécurité… En gros, à peu près tout ce qu'on peut imaginer avec les outils de gestion de configuration existants comme CFEngine, Puppet ou Chef.
Mais la différence avec Rudder, c'est de pouvoir faire cela dans une interface web. Pas de langage de configuration à apprendre, à peu près n'importe qui peut s'en servir (des templates de paramétrage prêts à l'emploi sont fournis, nommés Techniques, et peuvent être étendus). Et une fois toutes les règles mises en place, on a la satisfaction de voir d'un simple coup d'œil que le parc est à 100 % bien configuré…
Installation
C'est là un des points forts du projet - tout a été fait pour faciliter l'installation. Des paquets existent pour CentOS/RHEL 5 et 6, Debian Lenny et Squeeze, Ubuntu 11.10 et 12.10 et SLES 10 et 11.
Il faut installer sur une machine le serveur (qui s'installe d'un simple aptitude install rudder-server-root ou équivalent), et installer l'agent Rudder (qui est en réalité un paquet qui regroupe CFEngine, FusionInventory et un peu de configuration) sur chaque machine à gérer (ou « nœud » dans la terminologie du projet), d'un simple aptitude install rudder-agent (ou équivalent). Et c'est tout.
Le projet a aussi mis à disposition une configuration Vagrant, pour déployer une installation de test (deux machines virtuelles : un serveur et un nœud) très rapidement.
Aller plus loin
- Site communautaire (600 clics)
- Documentation complète avec captures d’écran (708 clics)
- Code source sur GitHub (47 clics)
- Annonce officielle de la version 2.4.0~beta3 (25 clics)
- Configuration Vagrant (sur GitHub) (49 clics)
- Présentation de la gestion de configuration avec Rudder (salon Solutions Linux) (569 clics)
- Trucs & Astuces à l'utilisation (270 clics)
# Quelqu'un l'utilise ?
Posté par M.Poil (site web personnel) . Évalué à 4.
Y-a-t-il des gens qui l'utilise quotidiennement?
Comment se comporte l'appli sur 2 ans avec un ou plusieurs milliers de serveurs ? (pour une gestion des dns, route, filtre ldap, sshd_config …)
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Quelqu'un l'utilise ?
Posté par Francois Bayart (site web personnel) . Évalué à 6.
je l'utilise en production, donc au quotidien, mais pour le moment pour sur une partie seulement des serveurs; un retour sur 2 ans semble difficile vu l'age du projet.
En soit c'est avant tout , selon moi, une interface à cfengine mais pas forcément un éditeur de cfengine, la phrase peut semble un peu confuse mais disons que Rudder va permettre de donner la main à une équipe de niv.1 pour désigner sur quel serveur appliquer quelle politique de configuration en définissant quelques variables mais dans aucun cas créer une "promesse" cfengine complète.
La 2.4 introduit des correctifs qui vont palier quelques faiblesses de la 2.3 pour tourner sur une production en toute tranquilité.
Le produit fait bien son job mais bon après tout c'est cfengine derrière qui lui est mature.
# Question ?
Posté par Mr Kapouik (site web personnel) . Évalué à 2.
J'imagine que le moteur est basé sur CFEngine mais je ne vois pas trop le rapport avec fusioninventory si votre agent est en C ?
Sinon vous sortez une version 2.4 d'un logiciel qui se base sur deux projets très jeunes (pour CFEngine je ne dit seulement que la version 3 est jeune) : Vous avez sorti la première version de votre logiciel en 2.2 ? Le projet à combien d'année d'existence ?
Sinon je vois que ce projet proviens d'une entreprise (ce qui peut apporter un gage de confiance pour des décideurs pressés), mais question communauté : avez vous beaucoup de contributeurs externes à l'entreprise ?
[^] # Re: Question ?
Posté par Jonathan Clarke . Évalué à 2.
Rudder utilise CFEngine pour appliquer les configurations: c'est lui qui est en C, et qui est le seul bout qui tourne régulièrement, donc qui est vraiment impactant pour l'utilisation de RAM. Mais il fait aussi un inventaire de chaque serveur (matériel, CPU, RAM, version d'OS, réseau, logiciels installés…) qui est visible dans l'interface web de Rudder, et ca c'est FusionInventory qui le fournit.
C'est un projet démarré dans l'entreprise Normation mi-2010. Les premières versions (0.1, 0.2… 1.0…) étaient du prototypage, beaucoup de code qui n'a pas été gardé (ou du moins qui ne devait pas l'être). Ensuite une grosse réécriture a fait passer Rudder en version 2.0 (puis 2.1, 2.2) mais ces versions n'ont jamais été publiées. On a mis les repos git en ligne avec la version 2.3 en octobre dernier. C'était sûrement pas la meilleure approche (on le voit avec le recul), cf "release early release often", mais on apprend de ses erreurs…
Actuellement il y a 6 contributeurs (ayant soumis des patchs pour la documentation, le packaging, les techniques, etc mais peu sur le code de l'appli web) et une petite vingtaine de "bug reporters" (n'ayant pas soumis de patch), en plus des développeurs chez Normation.
[^] # Re: Question ?
Posté par Mr Kapouik (site web personnel) . Évalué à 1.
Donc si je comprend bien il faut deux agents sur les clients : l'agent CFEngine et celui de fusion inventory ?
Et pour que l'agent de fusion inventory fonctionne il faut utiliser aussi leur partie serveur ou vous avez réimplémenté ça dans votre applicatif web (parce que ça peut révéler une grosse dépendance pas forcement acceptable pour tout le monde) ?
[^] # Re: Question ?
Posté par David DURIEUX . Évalué à 2. Dernière modification le 22 août 2012 à 16:40.
Le début du code de l'agent Fusioninventory pour la partie inventaire ordinateur/serveur date de 2006 quand même!
Oui mais il n'y a que l'agent CFEngine qui tourne en permanence, après ça peut etre aussi le cas pour FusionInventory si vous l'utilisez avec un GLPI (l'agent FusionInventory peut communiquer avec plusieurs serveurs)
Non la partie serveur a été implémenté dans Rudder, donc pas de soucis là dessus.
[^] # Re: Question ?
Posté par Jonathan Clarke . Évalué à 1.
Effectivement et le projet Rudder fournit un paquet unique (nommé rudder-agent) qui intègre les deux, ainsi que les configurations pour "bootstrapper" une machine à gérer, pour rendre le déploiement plus simple.
# LDAP ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Ce n'est pas précisé dans la dépêche mais Rudder semble s'appuyer sur un annuaire LDAP (schémas spécifiques ?) pour stocker sa (ou partie de) configuration.
A-t-il déjà été envisagé de se rapprocher des projets GOsa² ou OpenDirectory ?
[^] # Re: LDAP ?
Posté par Jonathan Clarke . Évalué à 3.
Effectivement, Rudder utilise des schémas LDAP pour stocker deux choses : 1) les données d'inventaire sur une machine (matériel, logiciel, réseau, etc), et 2) la configuration de Rudder elle-même (règles de configuration, groupes, etc).
Pour le 1, Rudder et le projet FusionDirectory (fork de GOsa) collaborent pour trouver un schéma commun.
# Rudder 2.4 - Gestion de configuration dans une UI
Posté par shutdown76 . Évalué à 0.
Bonjour, j'ai 60 postes clients nomade à migrer sous linux. Rudder pourrait-il être un bon moyen pour gérer ces clients ?
[^] # Re: Rudder 2.4 - Gestion de configuration dans une UI
Posté par Kokus . Évalué à 0.
Oui, probablement ! Il n'y a pas besoin que les postes soient en contact permanent avec le serveur, car chaque noeud utilise un "cache" des règles qu'il doit appliquer. Du coup, il est tout à fait envisageable de ne connecter qu'épisodiquement les clients au serveur pour récupérer les updates de règles.
[^] # Re: Rudder 2.4 - Gestion de configuration dans une UI
Posté par shutdown76 . Évalué à 0.
Je vais faire une maquette de tout ça. Merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.