Dans quelques semaines sortira RUDDER 5, une nouvelle version majeure conçue à partir d’une réflexion approfondie menée avec nos utilisateurs afin de mieux comprendre les besoins de ceux qui manipulent RUDDER au quotidien.
—
Croissance vs amélioration : la rationalisation comme solution
Depuis que RUDDER a été créé en 2011, la roadmap de RUDDER a toujours été gouvernée par une double volonté :
- Performance : améliorer les fonctionnalités principales utilisées par tous les utilisateurs afin de consolider le positionnement de RUDDER comme un outil robuste et efficace.
- Polyvalence : ajouter des fonctionnalités pour couvrir toujours davantage de cas d’usage différents.
À mesure que de nouveaux utilisateurs ont adopté RUDDER et partagé les spécificités de leur utilisation, la liste des fonctionnalités dédiées à certains cas d’usage moins courants s’est allongée, entrainant le logiciel à se complexifier avec des features dont l’existence n’intéresse finalement qu’une sous-partie des utilisateurs.
La version 5 vient rationaliser la structure de RUDDER afin de mieux concilier ces deux approches.
Des optimisations massivement souhaitées
Dans la continuité des améliorations apportées par les différentes versions mineures de la 4.1 à la 4.3, RUDDER 5 poursuit ce travail de fond d’optimisation et apporte encore davantage de puissance et de confort d’utilisation en améliorant les fonctionnalités existantes :
Workflow de validation localisé
L’un des principaux objectifs de RUDDER a toujours été de combiner une plus grande accessibilité à la puissance de l’infrastructure as code, notamment au travers de fonctionnalités comme l’interface de gestion, la librairie de règles prêtes à l’emploi, le Technique Editor, ou plus simplement l’abstraction des différences d’implémentation entre les différents OS supportés par l’agent.
Cependant, rendre accessible la possibilité de propager des changements sur l’ensemble d’une infrastructure de production en quelques clics n’aurait pas contribué à mieux fiabiliser l’IT si nous n’avions pas constamment le soucis de contrebalancer cette accessibilité par des fonctionnalités de maîtrise des changements afin de rester en contrôle. C’est le cas notamment du mode Audit qui permet de simuler des changements sans modifier les configurations afin d’anticiper leur impact, ou encore du workflow de validation qui impose une deuxième validation des changements (les habitués des “pull requests” sur Github connaissent déjà les bienfaits du peer review).
Avec RUDDER 5, le workflow de validation est amélioré, étant désormais capable de n’être appliqué que de manière ciblée sur un ou plusieurs groupes de machines uniquement, par exemple uniquement les serveurs de production en laissant libre accès à la plateforme de développement, au lieu de l’intégralité des nœuds gérés par le serveurs RUDDER. Cette fonctionnalité prend désormais tout son sens pour les environnements humains pour lesquels elle a été conçu, c’est-à-dire les équipes pluridisciplinaires et multi-niveaux qui se constituent naturellement dans les DSI de grande ampleur.
Nouveau reporting avancé
Le contrôle de conformité dans RUDDER a initialement été conçu afin de permettre la visualisation de l’état actuel d’application des configurations à un instant T.
Le reporting avancé permet d’historiser les données de conformité afin de consulter leur évolution dans la durée via des dashboards personnalisés. Entièrement paramétrables, depuis la période sur laquelle définir l’analyse, jusqu’au groupes de machines ou de règles de configurations concernées, ces dashboards personnalisés peuvent être exportés sous forme de rapport PDF afin de prouver la conformité à un auditeur externe, un client, ou à sa hiérarchie, sans avoir à mener d’inspection préparatoire manuellement.
Cette fonctionnalité fait peau neuve en version 5 avec une toute nouvelle interface.
Authentification externe
Les équipes IT de sociétés bien établies utilisent souvent un système de gestion des utilisateurs basé sur un annuaire (AD, LDAP, etc.) afin de gérer de très nombreux utilisateurs. Cette feature dédiée aux entreprises de plus grande ampleur permet de baser l’authentification des utilisateurs sur une source externe de type LDAP ou RADIUS, directement depuis l’interface web de RUDDER.
Branding
Lorsque RUDDER est déployé sur une infrastructure de grande ampleur, il est courant d’avoir plusieurs serveurs RUDDER, chacun gérant un environnement différent (production/QA/dev, sites différents, etc.). Pour faciliter le quotidien des administrateurs, mais aussi et surtout pour éviter la confusion entre les différents serveurs (ce qui est d’autant plus probable s’ils contiennent des configurations similaires), il est important de pouvoir les distinguer visuellement en un coup d’œil sur l’interface de RUDDER, quel que soit le menu ouvert.
La fonctionnalité de branding, en ajoutant des bandeaux de couleur et une description succincte à toutes les pages, répond à cette problématique simple mais non négligeable.
Droits d’accès (par action)
Cette fonctionnalité ajoute la possibilité d’avoir un token d’API par utilisateur RUDDER, et le support d’ACL précises sur les tokens système (du même type que les droits utilisateurs, avec limitation en lecture/écriture sur les différents items). Le tout est configurable depuis l’interface web. Cela permet de tracer et d’historiser précisément les accès des utilisateurs de RUDDER à la configuration (y compris via l’API), et de restreindre finement les droits donnés aux token d’API système (non lié à un utilisateur) pour une meilleure sécurité et séparation des privilèges.
Intégration
- Centreon
Le monitoring et la gestion de configuration sont deux fonctions clés du maintien en conditions opérationnelles d’un SI. Centreon est un outil de surveillance open source couramment utilisé. L’intégration avec RUDDER permet d’ajouter automatiquement à Centreon les machines dès leur acceptation dans RUDDER. De plus, les politiques de configuration dans RUDDER peuvent inclure une nouvelle méthode qui associe automatiquement le template de monitoring d’une application configurée à la machine. - Zabbix
Zabbix est une autre solution de monitoring open source largement utilisée. Cette intégration fonctionne de manière similaire à celle de Centreon. - iTop
iTop est une CMDB open source fréquemment utilisée. L’intégration entre iTop et RUDDER permet de synchroniser des données entre la CMDB et RUDDER. Il permet notamment de synchroniser les règles de configuration et une partie de l’inventaire des machines dans iTop. - Vault
Vault est un outil de stockage et de gestion de secret (mots de passe, clés, etc.). Cette intégration permet d’utiliser des données stockées dans un serveur Vault dans les politiques de configuration, évitant ainsi de les stocker sur le serveur RUDDER et limitant les accès aux machines concernées. - Slack [beta]
RUDDER produit une flux de changements issue des différents agents connectés à un serveur, en centralisant toutes les actions effectuées ou les erreurs rencontrées. Cette intégration permet de sélectionner des évènements (appartenant à une règle et/ ou à un groupe de machines en particulier), et de générer des messages correspondants sur la messagerie instantanée Slack.
Refonte de la documentation : centralisation des ressources et nouveaux guides de prise en main
L’amélioration qui mérite le plus d’attention pour cette future version 5 n’est peut-être pas à l’intérieur de RUDDER !
En effet, l’équipe RUDDER exauce un souhait maintes fois formulé par les utilisateurs lors des échanges au sujet des améliorations prioritaires à réaliser : une documentation plus complète avec un vrai guide de démarrage,desuse cases précis en exemple, et une structure plus intuitive.
C’est maintenant une réalité grâce à docs.rudder.io, une plateforme conçue comme un véritable hub de ressources d’utilisation qui centralise la documentation de RUDDER et de l’API, le bugtracker, les changelogs, les moyens d’interagir avec la communauté, etc.
Des features communes aux besoins de tous – des plugins pour l’exigence de chacun
À chaque nouvelle version son lot de nouvelles fonctionnalités, et RUDDER 5 n’échappe pas à la règle. Cependant, une réflexion approfondie est venue remettre en question la façon d’intégrer ces nouvelles features au sein du logiciel.
Le modèle initial de RUDDER consistant à ne proposer qu’un seul bloc logiciel embarquant la totalité des features et imposant ainsi à tous les utilisateurs toujours davantage de complexité a atteint ses limites. Nous avons aujourd’hui atteint une compréhension suffisamment fine et profonde du métier, des problématiques et des usages, qui nous fait penser que ce modèle tout-en-un n’est pas, ou plus, le mieux adapté.
C’est la raison pour laquelle le premier objectif de RUDDER 5 a été de remettre au centre des préoccupations l’utilisation commune de RUDDER en segmentant les fonctionnalités afin :
- d’offrir une expérience essentielle simple de RUDDER, avec uniquement les fonctionnalités utiles à tous,
- de laisser le choix d’installer des fonctionnalités avancées à l’unité via des plugins spécifiques, chacun adressant ainsi précisément son besoin.
RUDDER 5 proposera ainsi une expérience plus naturelle et spontanée d’audit et d’automatisation de l’infrastructure.
Un modèle déjà bien rodé
Nous ne pouvons pas nous targuer d’être les inventeurs d’un tel système, c’est notamment sur ce modèle qu’est bâti la plateforme WordPress ou encore Jenkins. Imaginez qu’ils se soient basés sur ce qu’était le modèle de RUDDER jusqu’alors, et que chaque environnement WordPress ou Jenkins embarque systématiquement l’intégralité des plugins existants ; l’utilisation quotidienne et la navigation dans les menus serait grotesque tant elle serait malcommode, et l’adoption par les nouveaux utilisateurs serait sérieusement compromise. Bien sûr, RUDDER n’en est pas à ce niveau de profusion de fonctionnalités annexes, mais il est inutile d’attendre que la situation atteigne ce niveau d’inconfort pour réagir !
Du coup qu’est-ce qui est essentiel et qu’est-ce qui ne l’est pas ? La règle de base est que l’expérience essentielle doit contenir les fonctionnalités dont se servent 80% ou plus des utilisateurs. Les 20% qui restent solutionnent des besoins qui ne sont pas moins importants, seulement moins communs. Si on constate que la majorité des utilisateurs veulent immédiatement désactiver une feature, ignorent son existence / utilité, ou pensent qu’ils ne l’utiliseront jamais, alors il est logique de l’isoler dans un plugin.
Une réorganisation en profondeur du projet RUDDER
Cette rationalisation de RUDDER s’inscrit dans un projet plus large visant à favoriser un développement plus rapide de la solution.
En effet, l’ancien modèle économique était exclusivement centré autour du service (formation, expertise à distance, intervention sur site, support de production, etc.). Or nous savons aujourd’hui que l’attente principale des utilisateurs repose avant tout sur l’évolution du produit. Dans ce contexte, se détourner du service aurait mis en péril la pérennité de l’équipe RUDDER. Ainsi, pour permettre à l’équipe de développement de consacrer tous leurs efforts au produit, il fallait d’abord transformer le modèle économique du projet afin qu’il récompense cette orientation, assurant à la fois la survie et la croissance du projet.
Du coup, vers quel nouveau modèle s’orienter pour à la fois offrir cette expérience simple et modulaire à base d’un écosystème de plugins, tout en assurant la pérennité financière du projet ?
RUDDER a su tirer son épingle du jeu parmi les solutions de gestion de configuration, notamment grâce au Technique Editor, l’éditeur en drag & drop permettant d’adresser simplement les besoins spécifiques non prévus dans la librairie de Techniques prêtes à l’emploi. Alors que ce modèle a fait ses preuves à l’intérieur même de RUDDER, il se révèle tout aussi pertinent autour de RUDDER. C’est la raison pour laquelle nous avons choisi d’isoler les fonctionnalités sophistiquées dans des plugins individuels, afin qu’un besoin spécifique soit résolu par la feature avancée qui lui est dédié.
Commercialement parlant, l’accès à l’ensemble des packages de ces plugins est disponible au sein d’une offre de souscription à la manière de Red Hat qui inclut également un support éditeur, ainsi qu’une maintenance étendue des versions jusqu’à 24 mois. Ce modèle a l’avantage d’être plus juste : jusqu’à présent, un petit nombre d’entreprises finançait la maintenance étendue alors que l’ensemble des utilisateurs en profitaient. Dès lors cette maintenance étendue sera réservée aux souscripteurs.
Les souscripteurs seront également les seuls à recevoir les plugins de features avancées sous forme de paquets RPKG prêts à l’emploi. Le mot d’ordre ici est que ceux qui financent le produit doivent être ceux qui en bénéficient le plus simplement.
Voici un aperçu des changements (pour voir le détail complet de l’offre de souscription : https://rudder.io/fr/souscription/) :
| Avant | RUDDER 5 | |
| INTERFACE DE GESTION | ||
| Interface complète de configuration | ✔ | ✔ |
| Créateur de techniques graphique | ✔ | ✔ |
| Personnalisation interface web (logo, couleur) | ✗ | Optionnel |
| AUDIT ET COMPLIANCE | ||
| Mode “audit only” (aucune modification) | ✔ | ✔ |
| Conformité par nœud et par règles (instantanée) | ✔ | ✔ |
| Agrégation & historique de conformité | ✗ | Optionnel |
| Workflow de validation (change requests) | Obligatoire → application globale uniquement |
Optionnel → configurable par groupe |
| INTÉGRATION | ||
| Gestionnaire de plugins (paquets RPKG) | ✔ | ✔ |
| Inventaire détaillé des nœuds (extensible) | ✔ | ✔ |
| Serveurs relais (pour isolation de zones réseau et montée en charge) | Optionnel | Optionnel → nouveau protocole en 5.x |
| Bonnes pratiques pour la haute-disponibilité | ✗ | Optionnel |
| Import générique de propriétés de nœud depuis sources HTTP externes | Optionnel | Optionnel |
| Authentification externe (LDAP, AD) | Obligatoire → LDAP et AD → hors interface |
Optionnel → LDAP, AD et RADIUS → configurable via l’interface web |
| Gestion des droits d’accès web (par type d’action) | Obligatoire | Optionnel (en 5.x) |
| Gestion des droits d’accès web (par type d’action) | ✗ | Optionnel |
| Gestion des droits d’accès API complets | ✗ | Optionnel |
| Intégration Centreon | ✗ | Optionnel |
| Intégration Zabbix | ✗ | Optionnel |
| Intégration Vault | ✗ | Optionnel |
| Intégration iTop | Optionnel – bêta | Optionnel |
| Intégration GLPI | ✗ | Optionnel |
| Intégration Slack | ✗ | Optionnel – bêta |
Conclusion
Avec RUDDER 5, la solution se recentre sur ses fonctionnalités les plus utilisées (y compris la documentation !) en les améliorant et en les remettant au cœur de l’expérience. C’est la garantie, pour ceux qui n’ont pas les contraintes des grosses équipes hétérogènes et/ou des productions larges et critiques, du maintien d’une expérience simple et directe de l’automatisation de l’infrastructure, non polluée par des features destinées à des use-cases potentiellement jamais rencontrés. Pour les équipes IT aux problématiques spécifiques, les plugins permettent d’adresser individuellement les sujets spécifiques par le biais d’un modèle qui a le double avantage d’être à la fois plus juste, et de favoriser les efforts de développement de l’équipe RUDDER.
Et maintenant ?
Pour découvrir RUDDER 5 par la pratique, un atelier de découverte d’une journée est organisé dans les locaux de Normation à Paris le 23 octobre prochain. En attendant, vous pouvez vous familiariser avec RUDDER 4.3 en :
- vous connectant à une démo en ligne pour découvrir l’interface (mais elle ne vous permettra pas d’appliquer de configuration) ;
- utilisant l’environnement de démonstration basé sur Vagrant pour tester facilement l’application de configuration sur un environnement réel ;
- installant RUDDER avec les paquets fournis et en suivant la documentation d’installation;
- venant discuter et poser vos éventuelles questions directement à l’équipe de développement et à la communauté RUDDER par courriel, sur IRC ou sur Twitter.
