URL: https://linuxfr.org/news/rudder-5-nouvelle-version-plus-modulaire-grace-a-un-ecosysteme-de-greffons
Title: RUDDER 5 — nouvelle version plus modulaire grâce à un écosystème de greffons
Authors: valentin.napoli
amousset, Davy Defaud, bubar🦥, palm123 et patrick_g
Date: 2018年10月05日T16:37:28+02:00
License: CC By-SA
Tags: rudder, gestion_de_configuration, automatisation, audit, debian, ubuntu et slackware
Score: 41
RUDDER est une solution française, libre et multi‐plate‐forme de gestion de configuration et d’audit en continu (_Continuous Configuration_), visant particulièrement les besoins d’infrastructures de production. La nouvelle version 5 a été 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.
----
[Site officiel du logiciel libre RUDDER](https://www.rudder-project.org/site/)
[RUDDER dans le tableau périodique des éléments DevOps](http://www.normation.com/fr/blog/2018/07/30/rudder-integre-le-tableau-periodique-des-outils-devops-de-xebialabs/)
[RUDDER conseillé par l’État dans son « Socle interministériel de logiciels libres » (SILL) 2018](http://www.normation.com/fr/blog/2018/08/06/rudder-conseille-par-letat-dans-son-socle-interministeriel-de-logiciels-libres-sill-2018/)
[Atelier de découverte pratique de RUDDER le 23 octobre prochaine](http://www.normation.com/fr/comment-demarrer/journee-dintroduction/)
[Nouvelle documentation de RUDDER](https://docs.rudder.io/get-started/current/home.html)
----
Qu’est‐ce que RUDDER ?
======================
RUDDER est une solution libre de _Continuous Configuration_ qui audite le système d’information (SI) en continu et automatise les opérations logicielles de façon contrôlée et sécurisée.
Derrière le terme de _Continuous Configuration_, on trouve une base de gestion de configuration, alliée à des fonctionnalités d’audit en continu. La différence entre un outil de gestion de configuration traditionnel et RUDDER, c’est que les changements peuvent être simulés individuellement avant d’être validés, puis vérifiés après être appliqués et, enfin, tracés et maintenus dans le temps. Tout ce qui n’est pas conforme à l’état cible, auquel on souhaite rester ou accéder, remonte des alertes en temps réel, crée des rapports de dérive ou déclenche une remédiation automatique. Cela en fait un outil particulièrement adapté pour répondre aux contraintes d’infrastructure de production.
## D’un point de vue pratique, RUDDER permet de :
- gérer le socle système (distribuer des clefs SSH, paramétrer le DNS, gérer les utilisateurs, paramétrer les permissions sur les dossiers et fichiers, lancer des tâches, gérer les certificats, etc.) ;
- installer, mettre à jour et configurer des applications ;
- appliquer et vérifier en continu les politiques de sécurité, y compris pour des normes externes (ISO 27001, PCI-DSS, PSSI de l’ANSSI, etc.).
## En bref, RUDDER est :
- un outil de gestion de configuration et d’audit en continu, existant depuis 2011 ;
- libre (code sous GPL v3, documentation sous CC by-SA 2.0, avec quelques bibliothèques sous licence Apache) ;
- composé d’un serveur qui gère les configurations et la remontée de conformité (en Scala) et d’un agent de configuration (en C), qui gère Debian, Ubuntu, RHEL/CentOS, SLES, Slackware et AIX ;
- utilisé par de larges productions critiques comme le groupe BPCE, la Caisse des Dépôts, BMW, Eutelsat ou Sagemcom ;
- principalement développé par Normation (http://www.normation.com/fr/normation/qui-sommes-nous/), qui propose différents services autour de RUDDER, tels que des greffons, du support ou de la formation.
Croissance vs amélioration : la rationalisation comme solution
==============================================================
Depuis que RUDDER a été créé en 2011, la feuille de route 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, entraînant le logiciel à se complexifier avec des possibilités dont l’existence n’intéresse finalement qu’une partie des utilisateurs.
La version 5 vient rationaliser la structure de RUDDER afin de mieux concilier ces deux approches.
Des améliorations massivement souhaitées
========================================
Dans la continuité des améliorations apportées par les différentes versions de la 4.1 à la 4.3, RUDDER 5 poursuit ce travail de fond 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 en tant que code, notamment au travers de fonctionnalités comme l’interface de gestion, la bibliothèque de règles prêtes à l’emploi, l’éditeur de techniques, ou plus simplement l’abstraction des différences d’implémentation entre les différents systèmes d’exploitation pris en charge par l’agent.
Cependant, cette facilité n’aurait pas contribué à mieux fiabiliser l’informatique si nous n’avions pas le souci de compléter cette accessibilité par des fonctionnalités de maîtrise des changements. 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 plate‐forme 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.
## Nouvel outil de rapport 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.
L’outil de rapport avancé permet d’historiser les données de conformité afin de consulter leur évolution dans la durée via des tableaux de bord 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 tableaux de bord personnalisés peuvent être exportés sous forme de rapports 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 les utilisateurs. Cette fonctionnalité 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, 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 jeton d’API par utilisateur RUDDER, et le gestion d’ACL précises sur les jetons système (du même type que les droits utilisateurs, avec limitation en lecture ou é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 jetons d’API système (non liés à un utilisateur) pour une meilleure sécurité et séparation des privilèges.
## Intégration
###Centreon
La supervision et la gestion de configuration sont deux fonctions clefs du maintien en conditions opérationnelles d’un SI. Centreon est un outil de supervision libre 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 modèle de supervision d’une application configurée à la machine.
###Zabbix
Zabbix est une autre solution de supervision libre largement utilisée. Cette intégration fonctionne de manière similaire à celle de Centreon.
###iTop
iTop est une CMDB libre 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 secrets (mots de passe, clefs, 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.
###Notification
RUDDER produit un flux de changements issu 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 par courriel ou sur la messagerie instantanée Slack.
## Empaquetage et distribution des paquets
Le cycle de développement de la 5.0 a aussi vu l’arrivée d’un nouveau serveur de téléchargement de sources et de paquets, centralisé sur , ainsi que de nombreuses améliorations sur les processus de construction des paquets et de signature et publication.
Côté empaquetage, la mise à jour de la liste des systèmes d’exploitation pris en charge par le serveur nous a permis de mettre (enfin) à jour les versions minimales de plusieurs dépendances :
- PostgreSQL 9.2 ;
- Apache 2.4 (permettant de simplifier amplement les configurations).
# 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 réorganisée et complétée avec un vrai [guide de démarrage](https://docs.rudder.io/get-started/current/index.html), des [cas d’utilisation précis en exemple](https://docs.rudder.io/rudder-by-example/current/index.html), et une structure plus intuitive.
[](https://docs.rudder.io/get-started/current/home.html)
C’est maintenant une réalité grâce à [docs.rudder.io](http://docs.rudder.io/), une plateforme conçue comme un véritable hub de ressources d’utilisation qui centralise la [documentation de RUDDER](https://docs.rudder.io/reference/5.0/index.html) et [de l’API](https://docs.rudder.io/api/), le [bugtracker](https://www.rudder-project.org/redmine/projects/rudder/issues), les changelogs, les moyens d’interagir avec la communauté, etc.
Techniquement, il s’agit d’un remplacement complet des outils utilisés et d’une réorganisation importante des sources, en utilisant :
- des sources en AsciiDoc, beaucoup plus adapté que le Markdown pour ce type de contenu riche ;
- [Antora](https://antora.org/), pour générer la documentation ; nous avons simplement créé un thème pour RUDDER, il est sorti très récemment et nous avons du contourner certaines limitations liées à sa jeunesse, mais c’est une excellente découverte !
- [DocSearch](https://community.algolia.com/docsearch/) (par Algolia), pour la recherche dans la documentation, un élément clé pour l’utilisabilité ;
- [Pandoc](https://pandoc.org/), le couteau suisse de la doc, pour des conversions de format de documentation à la volée (en l’occurrence du Markdown vers AsciiDoc) ;
- des Makefiles et des scripts shell et Python pour lier le tout ; beaucoup de contenu de la documentation est généré à partir d’une agrégation de différentes sources (métadonnées dans les sources, pages de manuel, documentation de références, des greffons, etc.).
# Des fonctionnalités communes aux besoins de tous – des greffons 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 nouveautés au sein du logiciel.
Le modèle initial de RUDDER consistant à ne proposer qu’un seul bloc logiciel embarquant la totalité des fonctionnalités et imposant ainsi à tous les utilisateurs toujours davantage de complexité a atteint ses limites. Nous avons aujourd’hui acquis 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 greffons spécifiques, chacun adressant ainsi précisément son besoin.
RUDDER 5 propose ainsi une expérience plus simple et accessible au premier abord, tout en étant capable de répondre aux cas d’utilisation plus avancés si besoin.
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 Jenkins, ou encore la plate‐forme WordPress. 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 greffons existants ; l’utilisation quotidienne et la navigation dans les menus seraient grotesques tant elles seraient malcommodes, 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 fonctionnalité, ignorent son existence ou son utilité, ou pensent qu’ils ne l’utiliseront jamais, alors il est logique de l’isoler dans un greffon.
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 ses 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 greffons, tout en assurant la pérennité financière du projet ?
Commercialement parlant, l’accès à l’ensemble des paquets de ces greffons 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.
[](https://www.normation.com/fr/rudder/souscription/)
Les souscripteurs sont également les seuls à recevoir les plugins de fonctionnalités avancées sous forme de paquets 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 : ) :
En résumé
=========
→ **Aucune fermeture de code**, pas de changement de licence, y compris concernant les fonctionnalités préexistantes devenues des greffons. Le code est toujours accessible publiquement sous licence GPL v3, y compris les nouveaux greffons. Seuls le support de systèmes d’exploitation propriétaires (Windows et AIX) et le greffon de rapport avancé ne le sont pas (ce qui était déjà le cas avant le version 5).
→ **Des changements concernant uniquement la disponibilité de paquets ou de greffons compilés :**
* sont **disponibles pour tous** les paquets correspondant aux cas d’usage les plus courants, permettant de garantir et de pérenniser l’utilisation de RUDDER par la communauté :
* toutes les versions de RUDDER, avec un support de 3 mois après la sortie de la version suivante ; les paquets fournis, incluant les mises à jour, sont identiques à ceux disponibles sous souscription, sans aucune différence de stabilité ou de qualité,
* un support des distributions GNU/Linux maintenues et courantes : RHEL/CentOS 6 et 7, Debian 8 et 9, Ubuntu 16.04 LTS et 18.04 LTS, SLES 12 et 15 (via des dépôts de paquets standards),
* tous les greffons d’intégration de RUDDER avec d’autres outils ;
* sont **disponibles via la souscription**, pour des besoins particuliers (qui représentent un coût de maintenance et de développement supplémentaire) :
* le support des systèmes d’exploitation propriétaires (Windows et AIX) ou peu répandus (Slackware, version de distributions anciennes et plus maintenues, etc.),
* la maintenance de long terme, avec des mises à jour jusqu’à 24 mois après la sortie d’une version,
* les greffons d’utilisation plus avancée ou spécialisée de RUDDER, destinés aux problématiques des entreprises et des organisations de plus grande ampleur (rapport de conformité en PDF, serveurs relais, _branding_ de l’interface, etc.)
→ Une **refonte du modèle économique** centré sur une souscription par machine, donnant accès aux contenus listés ci‐dessus, ainsi qu’à un support éditeur permettant la priorisation de corrections de bogues. Cela nous permet de nous concentrer sur le développement et l’amélioration de RUDDER.
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 fonctionnalités destinées à des cas d’emploi potentiellement jamais rencontrés.
Pour les équipes IT aux problématiques spécifiques, les greffons permettent de répondre individuellement à ces sujets 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](http://www.normation.com/fr/comment-demarrer/journee-dintroduction/) d’une journée est organisé dans les locaux de Normation à Paris le 23 octobre prochain. Vous pouvez vous y [inscrire](http://231018-jir.eventbrite.com/).
→ bénéficiez de 50 % de réduction avec le code de réduction `LINUXFR`.
## En attendant, vous pouvez vous familiariser avec RUDDER 5 en :
- vous connectant à une [démo en ligne](https://demo.rudder.io/) pour découvrir l’interface (mais elle ne vous permettra pas d’appliquer de configuration) ;
- suivant le [tutoriel de démarrage](https://docs.rudder.io/get-started/current/index.html) pour tester facilement l’application de configuration sur un environnement réel ;
- installant RUDDER en suivant la [documentation d’installation](https://docs.rudder.io/get-started/current/home.html) ;
- venant discuter et poser vos éventuelles questions directement à l’équipe de développement et à la communauté RUDDER [par courriel, sur IRC ou sur Twitter](http://rudder.io/fr/communaute/mailing-list-irc/).