C’est le printemps ! Les arbres bourgeonnent, le soleil revient, et Rudder arrive avec une nouvelle release, la version 2.10 « Catamaran » !
Qui dit printemps, dit renouveau, et dans cette nouvelle version, nous avons tenté d’apporter un peu de fraîcheur à Rudder, en le rendant plus rapide et scalable tout en ajoutant de nouvelles fonctionnalités.
En résumé, Rudder 2.10 c’est :
- De nombreuses optimisations, particulièrement au niveau de la génération de promesses,
- La possibilité de configurer la fréquence exécution de l’agent,
- Plus de flexibilité pour composer les groupes cible d’une Règle en pouvant maintenant exclure des groupes,
- L’inventaire complet d’un Noeud lorsque que l’on en demande les détails via L’API REST,
- La configuration de la rétention des fichiers sur l’agent,
- Le support d’AIX 5.3+ en tant qu’agent Rudder,
- De nombreuses améliorations de packaging, refactoring et autres petites améliorations d’interface.
Un Rudder beaucoup plus rapide !
Un de nos objectifs principaux dans cette 2.10 a été de corriger et d’optimiser Rudder pour le rendre plus opérationnel à la gestion de très grandes infrastructures.
Plus le nombre de machines à gérer est grand, plus la génération de promesses devenait lente, décalant alors l’application des nouvelles configurations par les nœuds. Pour la 2.10, nous avons identifié et corrigé les étapes rendant le processus de génération plus long. Dorénavant, leur durée est réduite, passant de plusieurs minutes à quelques secondes.
Parmi les autres améliorations, on peut noter :
- Moins de commits des requêtes SQL, ce qui devrait améliorer la réactivité de l’application en général,
- La gestion des inventaires entrants ne va plus bloquer l’interface web lorsque des centaines d’inventaires sont envoyés en même temps,
- Des promesses sur le serveur plus efficaces, plus rapides et demandant moins de trafic réseau
- Moins d’espace disque consommé sur le serveur Rudder (fichiers de logs redondants en moins )
Nous espérons avec toutes ces améliorations rendre Rudder plus agréable à utiliser, particulièrement dans le cadre de grosses installations.
De nouveaux paramètres de configuration pour l’agent Rudder :
L’exécution des agents Rudder se fait par défaut toutes les cinq minutes, cette valeur est intéressante car elle permet de vérifier presque en permanence l’état d’une machine, d’assurer que la configuration y est toujours correcte et de générer des rapports de conformité précis. Néanmoins, nous n’avons pas toujours la possibilité d’envoyer ces rapports toutes les cinq minutes, ou nous voulons réduire le trafic engendré par l’envoi de tous ces rapports. Maintenant, c’est possible directement depuis l’interface de Rudder ! Dans la page « Administration » -> « Settings », une nouvelle section est disponible :
On peut configurer trois choses dans cette interface :
- La fréquence de l’agent : de toutes les cinq minutes à toutes les six heures,
- L’heure à laquelle lancer l’agent pour la première fois,
- Une borne maximum pour l’intervalle aléatoire qui permet de varier le temps d’exécution entre différents noeuds et de répartir ainsi la charge dans le temps au lieu de tout concentrer au même moment.
Une fois le formulaire validé, les promesses sont regénérées et le nouveau planning d’exécution de l’agent sera appliqué dès le prochain lancement de l’agent.
Nous avons également ajouté une nouvelle propriété relative à la gestion de la durée de rétention des fichiers sur l’agent.
Il s’agit de deux dossiers de /var/rudder/cfengine-community: modified-files (un backup des fichiers modifiés par l’agent) et outputs (les résultat d’execution de l’agent).
Auparavant ces fichiers étaient conservés pendant 30 jours, ce qui peut prendre beaucoup de place sur chaque noeud. Aujourd’hui, vous pouvez définir l’âge maximal des fichiers dans ces dossiers.
Sélection des groupes
Actuellement, lorsque l’on applique une Règle à un groupe de noeuds, on doit choisir un ensemble de groupes de noeuds.
Si l’application d’une Règle à un ensemble de noeuds est très rapide, le contrôle dessus est assez faible, on est alors obligés de créer des groupes très précis (donc avec une requête compliquée, difficile à maintenir) pour répondre à un besoin très spécifique.
Pour simplifier l’usage des groupes, nous avons ajouté la possibilité d’exclure complètement des groupes de l’application d’une Règle. Ainsi, vous pouvez choisir votre ensemble de machines (comme vous l’auriez fait auparavant) puis dire que les machines d’un certain groupe groupe ne doivent pas appliquer la Règle.
Prenons un petit exemple : vous avez une configuration particulière à appliquer à vos machines de production. Mais que cette configuration ne doit pas s’appliquer sur les serveurs basée sur Red Hat 5, ni sur les machines du sous réseau 240.125.0.0/16.
En version 2.10, pour représenter ce cas, c’est très simple !
On choisit d’appliquer la règle sur les machines en production (groupe « Prod ») :
Desquelles on exclut les Red Hat 5 (groupe « RHEL 5 only ») et le sous réseau 240.125.0.0/16 (groupe « 240.125 subnet »)
Avant la 2.10, il aurait fallu créer et appliquer la règle à plusieurs groupes, pour pouvoir exclure les machines sous Red Hat 5 sans exclure d’autres machines. De plus, les requêtes sont assez complexes…
Trois groupes pour trouver toutes les machines
Si jamais on veut exclure d’autres machines (par exemple les machines de base de données, identifiées par leur hostname), il fallait auparavant ajouter un nouveau critère aux requêtes de groupes comme ceci :
Ce qui complexifie énormément ces groupes… ce qui aurait été encore plus compliqué à comprendre par la suite.
Avec la 2.10, il suffit d’avoir un seul groupe (« ‘db hosts » ), contenant uniquement les serveurs de base de donnée, et de l’ajouter dans les groupes exclus. Pour l’ajouter, il suffit de passer la souris dessus :
Puis de cliquer sur le symbole rouge avec le signe ‘moins’ :
C’est aussi simple que cela !
Voilà pour cette nouvelle fonctionnalité, nous espérons que vous apprécierez les possibilités qu’elle offre, et nous attendons avec impatience vos retours dessus !
Récupérer les inventaires via l’API
Nous avons décidé d’étoffer un peu les informations fournies sur les noeuds via l’API EST pour le détail d’un noeud en ajoutant la possibilité d’obtenir toutes les données d’inventaires.
La fonction utilisée est la suivante : [GET] /api/nodes/nodeId
Un exemple d’utilisation avec la valeur par défaut :
% curl -X GET 'https://server.rudder.local/rudder/api/4/nodes/root?prettify=true' -k -H "X-API-Token: oLSUU0heydMHQ52tpQ7Gku3lRFat6iuQ"
{
"action": "nodeDetails",
"id": "root",
"result": "success",
"data": {
"nodes": [
{
"architectureDescription": "x86_64-linux-thread-multi",
"ipAddresses": [
"127.0.0.1",
"10.0.2.15",
"192.168.42.80"
],
"managementTechnology": [
{
"name": "CFEngine Community"
}
],
"status": "accepted",
"lastInventoryDate": "2014-04-01 13:05",
"hostname": "server.rudder.local",
"id": "root",
"machine": {
"id": "9095B41C-3A64-4841-9919-5BD769B741D5",
"type": "Virtual",
"provider": "vbox"
},
"ram": 496,
"os": {
"type": "Linux",
"name": "Debian",
"version": "6.0.7",
"fullName": "Debian GNU/Linux 6.0.7 (squeeze)",
"kernelVersion": "2.6.32-5-amd64"
},
"policyServerId": "root"
}
]
}
}
Il existe trois niveaux de détails de base : default (informations pour caractériser un noeud Rudder), minimal (id, hostname, statut) et full (toutes les informations). À ceci, on peut ajouter des filtres supplémentaires permettant de préciser des champs à afficher. Pour préciser ces informations, il faut utiliser le paramètre include, avec comme valeur des niveaux de détails et des champs séparés par des virgules.
Par exemple, si l’on a besoin d’informations de file system uniquement, on peut utiliser le filtre minimal de cette manière et y ajouter les informations de file system ( include=minimal,fileSystems ):
% curl -X GET 'https://server.rudder.local/rudder/api/4/nodes/80F9C2D7-3281-4556-ACDA-807AF6D9A9B4?prettify=true&include=minimal,fileSystems' -k -H "X-API-Token: oLSUU0heydMHQ52tpQ7Gku3lRFat6iuQ"
{
"action": "nodeDetails",
"id": "80F9C2D7-3281-4556-ACDA-807AF6D9A9B4",
"result": "success",
"data": {
"nodes": [
{
"id": "80f9c2d7-3281-4556-acda-807af6d9a9b4",
"hostname": "node1.rudder.local",
"status": "pending",
"fileSystems": [
{
"name": "swap",
"totalSpace": 382
},
{
"name": "vboxsf",
"freeSpace": 87680,
"totalSpace": 295160,
"mountPoint": "/vagrant"
},
{
"name": "ext3",
"freeSpace": 6335,
"totalSpace": 7683,
"mountPoint": "/"
}
]
}
]
}
}
Avec ce nouvel appel de fonction de l’API REST, il est possible d’exporter les données d’inventaires sous format JSON et d’en faire ce que bon vous semble : intégration avec votre base d’inventaire ou CMDB existant, statistiques sur les composants de votre parc, export des groupes de Rudder, …
Autres changements
Un nouvel agent apparaît !
Il est possible de gérer maintenant un des serveurs AIX avec Rudder. Nous maintenons désormais un paquet rudder-agent pour AIX 5.3+. Contactez-nous pour en savoir plus.
Quelques petits liftings d’interface
L’interface d’édition des Règles a été un peu réorganisée, on espère qu’elle sera plus agréable pour vous !
Quelques renommages ont eu lieu dans toute l’interface pour éclaircir certaines fonctionnalités :
- « deployment » -> « policy update » : Les promesses ne sont pas déployées directement par ce processus mais seulement générées. Les noeuds viennent ensuite chercher leurs promesses à jour,
- « change message » -> « change audit log » : Pour que ces messages servent de trace permettant d’expliquer éventuellement ce qu’il s’est passé,
- « No answer » -> « No report » : le terme « no answer » du reporting peut paraître un peu négatif, « no report » représente mieux l’idée qu’il s’agit juste d’un rapport manquant.
Nouveaux comportements
Les noeuds peuvent maintenant avoir des IPs dupliquées entre elles. Auparavant, ceci n’était pas possible pour éviter les doublons mais nous avons décidé d’enlever cette limite. Cela arrive notamment dans le cas où plusieurs ensembles de machines (clusters, déploiements embarqués, …) ont des interfaces privées pour communiquer entre elles, qui sont identiques d’un ensemble à l’autre.
Un nouveau type de reporting « nothing to do », permettant de signifier qu’il n’y a rien eu à faire (par exemple quand un post hook n’a pas eu besoin d’être lancé) a été mis en place. Ceci n’est pas encore le cas dans les techniques, mais serait utile.
Du nouveau pour le packaging
Les fichiers d’init et de config du serveur jetty et du serveur OpenLDAP (slapd) embarqué dans Rudder ont été renommés en leur ajoutant le préfixe ‘rudder-‘. Ainsi, il n’y aura plus de conflit avec ceux de votre système.
Le fichier de config de Jetty (/etc/init.d/rudder-jetty) est maintenant considéré comme un fichier de configuration et ne sera plus automatiquement écrasé à chaque mise à jour.
Une nouvelle version de Jetty est utilisée pour l’interface web (7.6.14).
Un petit nettoyage de printemps
Pas mal de refactoring (API), de code mort nettoyé (dans les techniques principalement), un packaging plus propre (moins verbeux ),… Pas mal de petites tâches pour rendre Rudder plus facile à maintenir et à faire évoluer !
Le mot de la fin
Et voilà pour Rudder 2.10 Catamaran ! La mise à jour vers cette version nécessite de disposer de Techniques adaptées pour CFEngine 3.5. Si vous disposez d’un serveur en version 2.8 ou 2.9, tout est bon, il suffit de mettre à jour votre serveur en 2.9, et les agents peuvent rester en version 2.8. Sinon, il faut avoir mis à jour auparavant votre serveur Rudder vers la dernière 2.6 (à partir de la 2.6.8), puis mettre à jour les agents de tous les noeuds en 2.10, puis finalement mettre à jour le serveur en 2.10. Vous trouverez la procédure complète de mise à jour dans la documentation.
Cette release n’a pas encore été déclarée « stable », mais elle ne saurait tarder à l’être ! Nous testons minutieusement nos nouvelles releases et considérons qu’elles sont prêtes à être déployées en production. Pour être déclarée stable, nous préférons attendre qu’une version ait plusieurs mois d’existence, qu’elle ait pu tourner pendant un temps considérable sur plusieurs systèmes en production.
Nous tenons beaucoup à notre communauté et votre soutien est particulièrement apprécié. Nous sommes preneurs de retours, idées, rapports de bugs, ou autres. Nous sommes à votre écoute ! N’hésitez pas à nous rejoindre sur IRC (#rudder sur Freenode), nous serons très heureux de vous y accueillir, de répondre à vos questions et d’écouter vos retours.
Le changelog complet de la 2.10 est ici.
La documentation de la 2.10 est consultable en ligne (ou directement depuis votre serveur Rudder!)
