J'avoue que j'aimerais m'en servir pour mettre à jours un certains nombres de raspberry pi (quand le client raspbian serait prêt) + quelques machines et vérifier que les services n'ont pas été cassé.
Par contre c'est étonnant que pour un logiciel dont on vante le côté français il ne soit pas traduit en français (ni sa doc) :P
Il n'y a actuellement pas de version traduite (ou en cours de traduction) de Rudder ou de la documentation, principalement parce qu'il y a peu de demande (beaucoup d'utilisateurs ne sont pas francophones, et la plupart des utilisateurs francophones lisent l'anglais). En plus, ça demanderait beaucoup de ressources, qu'on estime pour l'instant mieux utilisées à améliorer la documentation existante.
Quelles sont les pré-requis matériel/bandwidth pour genre 10 machines, 100 machines, 1000 machines ?
La documentation d'installation donne contient une estimation pour la RAM et le disque nécessaires sur le serveur.
Il n'y a pas de métrique de bandwith documentée, mais il existe notamment un mode Changes only qui permet de n'envoyer de rapports d'exécution que sur les modifications effectuées (et pas sur les composants qui sont déjà corrects et n'ont pas été modifiés), permettant de réduire fortement la consommation réseau de la remontée de rapport utile sur des environnements avec des contraintes réseau (connexion mobile, etc.).
L'export des backups est-il automatisable via cron ?
Il faut vraiment passer par la modification de /opt/rudder/etc/rudder-users.xml pour changer le password de l'admin? Rien dans la WEBUI de prévu?
Il est aussi possible d'utiliser un serveur LDAP pour l'authentification (mais la gestion des autorisations se fait pour l'instant toujours dans /opt/rudder/etc/rudder-users.xml).
Peut-on exécuter des commandes sur une ou plusieurs machines (par exemple apt-get update) ?
Un certain nombre de Techniques (installation de paquet, modification d'un fichier, etc.) permettent l'exécution d'une commande quand un changement est effectué (installation ou mise à jour du package, modification du fichier). On peut aussi exécuter des commandes de façon plus générale (notamment dans le Technique Editor, quand on définit un bloc de configuration). Cependant, ce n'est en général pas l'objectif, et on préfère autant que possible définir des états à atteindre plus que des actions (comme des commandes), pour obtenir des configurations plus fiables et plus souples. Pour reprendre l'exemple du apt-get update, il est effectué automatiquement quand des paquets sont gérés par Rudder sur la machine, et l'utilisateur n'a qu'à configurer les paquets à installer et leurs versions (donc définir un état à atteindre).
Pour exécuter des commandes qui demandent une synchronisation entre plusieurs machines, il est préférable d'utiliser un outil plus adapté aux actions ponctuelles comme Rundeck ou Ansible, qui peuvent utiliser les informations présentes dans Rudder (liste de machines, groupes, etc.).
Peut-on déployer des scripts (par exemple j'ai un script maison gérant des tunnels SSH a lancer au boot) ?
Oui, par exemple avec la Technique "File download (Rudder server)" qui permet de télécharger sur les nœuds un fichier (ou dossier) présent dans /var/rudder/configuration-repository/shared-files sur le serveur Rudder.
L'équivalent d'un ansible-role semble être une Technique. L'équivalent du ansible-workbook est une config graphique dans Rudder.
Effectivement, un playbook correspond plus ou moins à une Règle dans Rudder (qui est configurée via l'interface Web ou l'API). Une Règle regroupe des éléments de configurations issus de Techniques ("configuration de nginx", "configuration du serveur SSH", etc.) en un ensemble qui a un sens métier ("serveur de cache Web", "serveur de base de données", etc.), et les associe à un groupe de machines.
Je n'ai pas trouvé la doc expliquant comment rajouter une Technique et si il y a des contraintes (e.g. FAUT utiliser ncf ?)
en utilisant le Technique Editor (accessible dans https://demo.rudder-project.org/, Utilities -> Technique editor) qui est une interface Web de construction de techniques à partir de méthodes de base ("s'assurer de la présence d'un package", "s'assurer qu'un service est démarré", etc.). Il est intégré à Rudder et très simple d'utilisation, tout en permettant d'établir des liens entre les actions (n'exécuter une action que si une autre est en erreur, ou quand un fichier a été modifié, etc.) ou de manipuler des variables. C'est la solution conseillée en général.
en écrivant du code de configuration, ainsi qu'un fichier de description des paramètres en entrée (ce qui correspond au contenu du dépôt https://github.com/Normation/rudder-techniques). C'est la méthode la plus souple, mais elle demande un apprentissage particulier (notamment le framework de configuration ncf).
Plus précisément, Ansible peut utiliser Rudder comme inventaire dynamique, pour récupérer la liste des noeuds et leurs propriétés (groupe, variables clé-valeur associées). Rudder et Ansible peuvent ainsi être utilisés de manière complémentaire, avec Rudder pour le maintien du socle (gestion des programmes installés, configuration système: utilisateurs, sécurité, etc.) et Ansible pour l'exécution d'actions ponctuelles et de tâches d'orchestration (déploiement, etc.).
La modification des configurations me paraît aussi peu probable sur mobile, mais potentiellement plus la consultation de l'état de l'infrastructure (conformité, changements effectués).
En plus, l'aspect responsive, sans aller jusqu'au mobile, est utile pour s'adapter à des matériels aux résolutions diverses (ou simplement pouvoir passer l'interface sur une moitié d'écran sans qu'elle ne devienne inutilisable ;)).
[^] # Re: Merci pour la dépêche
Posté par amousset (site web personnel) . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 2.
Un package de test (compatible Raspberry 2 et +) pour Raspbian est maintenant disponible : http://www.rudder-project.org/temporary/rudder-agent_4.1.1_armhf.deb, et nous sommes preneurs de retours de tests :)
[^] # Re: Retour premier essai
Posté par amousset (site web personnel) . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 2.
Il n'y a actuellement pas de version traduite (ou en cours de traduction) de Rudder ou de la documentation, principalement parce qu'il y a peu de demande (beaucoup d'utilisateurs ne sont pas francophones, et la plupart des utilisateurs francophones lisent l'anglais). En plus, ça demanderait beaucoup de ressources, qu'on estime pour l'instant mieux utilisées à améliorer la documentation existante.
La documentation d'installation donne contient une estimation pour la RAM et le disque nécessaires sur le serveur.
Il n'y a pas de métrique de bandwith documentée, mais il existe notamment un mode Changes only qui permet de n'envoyer de rapports d'exécution que sur les modifications effectuées (et pas sur les composants qui sont déjà corrects et n'ont pas été modifiés), permettant de réduire fortement la consommation réseau de la remontée de rapport utile sur des environnements avec des contraintes réseau (connexion mobile, etc.).
Il est possible de récupérer les archives de configuration via l'API, c'est donc facilement automatisable dans un script.
Il est aussi possible d'utiliser un serveur LDAP pour l'authentification (mais la gestion des autorisations se fait pour l'instant toujours dans
/opt/rudder/etc/rudder-users.xml).[^] # Re: Merci pour la dépêche
Posté par amousset (site web personnel) . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 2.
Un certain nombre de Techniques (installation de paquet, modification d'un fichier, etc.) permettent l'exécution d'une commande quand un changement est effectué (installation ou mise à jour du package, modification du fichier). On peut aussi exécuter des commandes de façon plus générale (notamment dans le Technique Editor, quand on définit un bloc de configuration). Cependant, ce n'est en général pas l'objectif, et on préfère autant que possible définir des états à atteindre plus que des actions (comme des commandes), pour obtenir des configurations plus fiables et plus souples. Pour reprendre l'exemple du
apt-get update, il est effectué automatiquement quand des paquets sont gérés par Rudder sur la machine, et l'utilisateur n'a qu'à configurer les paquets à installer et leurs versions (donc définir un état à atteindre).Pour exécuter des commandes qui demandent une synchronisation entre plusieurs machines, il est préférable d'utiliser un outil plus adapté aux actions ponctuelles comme Rundeck ou Ansible, qui peuvent utiliser les informations présentes dans Rudder (liste de machines, groupes, etc.).
Oui, par exemple avec la Technique "File download (Rudder server)" qui permet de télécharger sur les nœuds un fichier (ou dossier) présent dans
/var/rudder/configuration-repository/shared-filessur le serveur Rudder.[^] # Re: Par rapport à Ansible
Posté par amousset (site web personnel) . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 2.
Effectivement, un playbook correspond plus ou moins à une Règle dans Rudder (qui est configurée via l'interface Web ou l'API). Une Règle regroupe des éléments de configurations issus de Techniques ("configuration de nginx", "configuration du serveur SSH", etc.) en un ensemble qui a un sens métier ("serveur de cache Web", "serveur de base de données", etc.), et les associe à un groupe de machines.
La création de Techniques peut se faire de deux manières :
Plus précisément, Ansible peut utiliser Rudder comme inventaire dynamique, pour récupérer la liste des noeuds et leurs propriétés (groupe, variables clé-valeur associées). Rudder et Ansible peuvent ainsi être utilisés de manière complémentaire, avec Rudder pour le maintien du socle (gestion des programmes installés, configuration système: utilisateurs, sécurité, etc.) et Ansible pour l'exécution d'actions ponctuelles et de tâches d'orchestration (déploiement, etc.).
[^] # Re: Merci pour la dépêche
Posté par amousset (site web personnel) . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 4. Dernière modification le 21 avril 2017 à 22:50.
La modification des configurations me paraît aussi peu probable sur mobile, mais potentiellement plus la consultation de l'état de l'infrastructure (conformité, changements effectués).
En plus, l'aspect responsive, sans aller jusqu'au mobile, est utile pour s'adapter à des matériels aux résolutions diverses (ou simplement pouvoir passer l'interface sur une moitié d'écran sans qu'elle ne devienne inutilisable ;)).