Face aux problématiques toujours plus complexes de croissance, fiabilité et sécurité de l’infrastructure, une approche continue de l’automatisation s’impose peu à peu comme la réponse à ces évolutions. En cause dans cette complexité, une gestion difficile de la double hétérogénéité à laquelle doit faire face le responsable d’infrastructure : celle des technologies système, et celle des spécialisation des membres de son équipe.
Or pour bénéficier des avantages liés à l’automatisation, celle-ci ne peut être cantonnée à une unique plateforme ou à une sous-partie de l’équipe : une solution d’automatisation ne délivre ce qu’elle promet que lorsqu’elle est déployée sur l’ensemble des systèmes d’exploitations utilisés et accessibles à tous les acteurs de leur maintenance.
C’est pourquoi un des piliers de la vision qui sous-tend RUDDER est la capacité de l’outil à s’adapter à son utilisateur, qu’importe son système de prédilection ou son niveau d’expertise.
La concrétisation la plus visible de ce principe est la possibilité d’utiliser RUDDER avec la même étendue et la même granularité, que ce soit via l’interface web, la ligne de commande ou l’API. Mais ce n’est pas la seule feature qui découle de cette volonté : l’abstraction pour l’utilisateur des différences d’implémentations selon les systèmes d’exploitation fait également écho à ce leitmotiv. C’est de ce dernier point dont il est question dans cet article.
Jusqu’à maintenant, le support des systèmes Microsoft Windows par RUDDER était assuré par un agent tiers, CFEngine Enterprise, édité par Northern.tech. Cette solution présentait des limitations :
- les développeurs de RUDDER n’ayant pas accès code source du fait de la licence propriétaire de cet agent tiers, les développements étaient plus complexes, plus longs mais aussi moins bien optimisés que ceux sur les plateformes libres,
- le coût répercuté sur les directions informatiques dû à l’utilisation de cet agent tiers était un frein à l’utilisation de la solution sur les systèmesWindows.
C’est dans le but de soustraire RUDDER à ces limitations que nous avons noué un partenariat technique avec Microsoft France afin de développer un nouvel agent RUDDER utilisant la technologie native Microsoft PowerShell Desired State Configuration (DSC).
Quels sont les impacts en matière d’utilisation de RUDDER ?
Que ce soit au sein de l’interface web, de la CLI, ou même de l’API, tout reste identique : les règles de configuration destinées aux systèmes Windows s’utilisent de la même manière que celles pour les Linux et autres systèmes Unix. C’était déjà le cas avec l’ancien agent Windows. La seule différence d’usage que l’on peut identifier serait de l’ordre des performances de l’agent, la technologie native étant plus efficace.
Le support de Windows nécessite cependant l’installation au préalable d’un plugin sur le serveur qui met à disposition les briques de configuration (la version 1.0 du plugin apporte 32 generic methods et 4 techniques, et leur nombre augmentera au fil des versions) ainsi que la possibilité de générer des règles de configuration pour des nœuds Windows.
Sur les nœuds gérés, comme sous systèmes Unix, un agent est installé, et va appliquer les configurations. Cet agent est compatible avec Windows 2008R2 et suivants, et nécessite la présence de PowerShell 4. Le plugin installé sur le serveur nécessite un RUDDER 4.2 (sorti le 28/09/2017, voir https://www.rudder-project.org/doc-4.2/install-server.htmlpour la documentation d’installation).
La gestion des machines est identique aux nœuds Unix du point de vue utilisateur. La principale différence vient du fait que certaines Techniques ne sont pas compatibles avec Windows (comme la gestion des packages) et inversement, incompatible avec Unix (Gestion des Registres).
Dans le Technique Editor, la compatibilité des Generic Methods avec le nouvel agent se matérialise par la présence d’un icône DSC sur la méthode , ainsi que par le présence d’un filtre sur la liste des méthodes :
Cela permet de composer des techniques pour Windows :
Des techniques compatibles sont aussi disponibles, annotée avec le même icône :
L’ensemble des configurations disponibles pour Windows sont compatibles aussi bien avecle mode Audit qu’avec lemode Enforce.
L’agent sur le nœud fonctionne comme l’agent Unix, et la sortie affichée est comparable :
Sous le capot du nouvel agent
Le fonctionnement de l’agent lui même est très similaire à celui de Linux et AIX – il fonctionne par définition de l’état cible, l’agent récupère cet état cible auprès du serveur RUDDER (via le protocole HTTP(S)), puis vérifie en local si chaque item est dans le bon état, et le corrige et/ou remonte un rapport (mode audit) sinon. Les rapports sont pour l’instant envoyés avec le protocole syslog (via le journal d’évènements Windows). L’envoi de l’inventaire et l’exécution de l’agent sont effectués via des tâches planifiées.
DSC (pour Desired State Configuration) est un outil de gestion de configuration basé sur un langage déclaratif intégré à Powershell.
Au niveau des politiques de configurations, tout passe par les generic methods, qui servent d’interface commune aux nœuds Windows et Linux. Les techniques compatibles avec Windows utilisent directement les generic methods dans leur implémentation.
Le plugin installé sur le serveur contient les politiques de configuration interne à RUDDER spécifiques à Windows (aussi appelées techniques système), le generic methods compatibles avec Windows, ainsi que les techniques spécifiques à Windows. Il permet également d’ajouter la logique de génération des configurations pour les agents DSC, absente du produit de base.
L’agent contient l’outil d’inventaire, les scripts de gestion de l’application des configurations, les tâches planifiées, ainsi que les politiques par défaut appliquées à l’installation.
Aller plus loin
Pour en savoir plus sur RUDDER et la gestion des systèmes Windows, vous pouvez :
- contacter Alexandre au 01 85 08 88 08 ou sur abr@normation.com
- regarder la vidéo de démo
