Configuration Management on Zwindler's Reflection

Rudder - astuces en vrac

Thu, 20 Apr 2023 18:00:00 +0200

Cet article fait partie d’une suite d’articles sur Rudder. La version qui est testée ici sera la version open source (car je n’ai pas les moyens de me payer une licence pour mon infra perso 😛) :

Note : une fois de plus, je tiens à préciser qu’il ne s’agit PAS d’un article sponsorisé. J’ai eu des contacts (techniques) avec la team Rudder, mais je n’ai été influencé d’aucune manière, en particulier dans la rédaction de cet article.

But de l’article

Dans les deux articles précédents, j’ai parlé des concepts de Rudder, de l’installation du serveur et des agents. Je suis allé un poil plus loin avec mon installation perso mais avec ce que j’ai déjà écrit, on est déjà en capacité de jouer avec Rudder et je pense pas qu’on ait besoin d’aller beaucoup plus loin.

Cependant, au cours de mes péripéties avec Rudder, je suis tombé sur quelques petits “os”. Rien de bien poussé, qui ne justifierait un article seul. Je vais donc tout regrouper ici, en vrac ;-P.

Tuning pour les petits CPUs et les petites RAMs

On l’a dit dans le premier article, Rudder est assez doux en termes de prérequis matériels. Quelques Mo de mémoire suffisent pour l’agent, et grosso modo pas besoin de machine de guerre pour le CPU.

Cependant, comme je suis extrêmement économe (aka radin) dans la gestion de mon infra perso, je suis quasiment un anti pattern dans le cas de Rudder. J’ai un cluster Proxmox monté sur des machines louées à 6€/mois à base d’un antédiluvien Atom C2350 (des duals core de 2013 !).

C’est d’ailleurs pour essayer de grappiller quelques % de CPU que j’avais publié les articles Optimisation de PFsense dans Proxmox VE et Proxmox - Tips and tricks.

Ces machines ne supportant même pas les instructions VT-x, je ne fais donc pas de machines virtuelles mais uniquement des machines à bases de containers LXC. Je me retrouve donc à installer une dizaine d’agents (oui, je suis vraiment bourrin) sur un même Atom.

Rudder a beau être économe, multiplier les agents sur une machine aussi faible avait un coût difficilement soutenable sur ma machine, comme en témoigne le graphique CPU ci-dessous (mon serveur ne fait quasiment rien, c’est donc quasiment exclusivement de la charge Rudder).

Il est très peu probable que vous ayez vous une charge perceptible sur vos infras. Dans le cas de machines aussi peu puissantes, il est probable que la team Rudder recommanderait de ne pas installer d’agent sur mes containers LXC. Mais dans le cas de machines très très peu puissantes et/ou très très densifiées en termes de nombre de VMs, sachez qu’il est quand même possible de tuner le scheduling des runs de Rudder et ainsi limiter la casse.

Dans le menu Administration / Settings, il existe une section Agent run schedule. Par défaut, l’ordonnancement est prévu de la façon suivante : Rudder lance les vérifications / corrections sur sa liste d’agent sur une plage de 5 minutes, le premier tiré au hasard commençant à 0 minutes (directement donc) et le dernier jusqu’à 4 minutes (1 minute avant la fin de la fenêtre de tir).

Note : au-delà de mon cas particulier, c’est quand même intéressant à savoir, car en fonction de ce qu’on lancera (scripts très longs par exemple, upgrades apt, …), il peut être intéressant de tuner ce dernier paramètre (Maximum delay) pour être certain que 2 jobs ne se chevauchent pas.

En modifiant le scheduling pour que les runs se lancent non pas sur 5 minutes mais sur 30, avec un dernier lancement à la 29 ème minute, j’ai pu retrouver une charge relativement acceptable sur mon infra.

Deuxième astuce, si vous êtes limité en RAM, que vous avez moins de 50 machines et que vous n’utilisez pas beaucoup les plugins, il est possible de diminuer la taille de la JVM de rudder (par défaut à 1 Go) et ainsi un peu mieux respirer sur une machine à 2 Go (prérequis Rudder, un peu justes).

sed -i 's/JAVA_XMX=1024/JAVA_XMX=512/' /etc/default/rudder-jetty
systemctl restart rudder-server.service

Merci Nicolas pour l’astuce :)

Changer le nom des machines du point de vue de Rudder

Autre problème, je n’ai pas toujours la main sur le FQDN des machines que je loue. En particulier, le retour de la commande hostname -f renvoit parfois le nom de la machine telle que l’appelle l’hébergeur.

Je me retrouve avec un inventaire rudder plein de machines avec des noms du type int.nua.ge et randomid.dedibox.fr…

Dans certains cas, je peux le modifier moi-même et/ou feinter Rudder (en modifiant le fichier /etc/hosts par exemple) mais plutôt que de faire ça, j’ai préféré utiliser une technique détaillée dans la documentation officielle de Rudder appelée override node fqdn

La méthode pour le faire à la main est la suivante. En tant que root, je crée un script qui renvoie un JSON contenant une variable avec le nom que je souhaite pour mon hôte :

# mkdir -p /var/rudder/hooks.d/
# vi /var/rudder/hooks.d/override-hostname.sh
echo '{"rudder_override_hostname": "myhost.example.org"}'
# chmod +x /var/rudder/hooks.d/override-hostname.sh
# rudder agent inventory
Rudder agent 7.2.4
Node uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

C’est relativement simple, mais j’étais pas satisfait car ça nécessite une action manuelle et je suis super fainéant. Comme les noms courts de mes machines sont eux toujours bons, quel que soit le provider et que je connais le domaine par avance (zwindler.fr), j’ai créé unedirective Rudder pour le faire à ma place !

A partir d’une technique de type Distribution files / File content, j’ai mis les valeurs suivantes :

Et voilà le résultat, 5 minutes pour tard :)

Agent qui ne démarre pas après une désinstallation / réinstallation

Au début, quand je commençais à jouer avec Rudder, je me suis un peu mélangé les pinceaux au point qu’il était plus simple de tout désinstaller et recommencer proprement.

En théorie, quand on veut debug et/ou réinstaller un agent qui marche mal, on peut utiliser les commandes suivantes :

rudder agent factory-reset
rudder agent inventory
rudder agent check

Sauf que dans mon cas, j’avais désinstallé puis réinstallé l’agent. Et à chaque fois, tout avait l’air OK, mais rudder ne faisait rien et voici le message d’erreur que j’avais :

rudder agent check
INFO: No disable file detected and no agent executor process either. Restarting agent service... Done
WARNING: The file /var/rudder/cfengine-community/last_successful_inputs_update is older than twice 10 minutes, the agent is probably stuck. Purging the CFEngine lock database... Done
FINISH: Rudder agent check ran properly, please look at messages above to see if there has been any error.

Pour essayer de comprendre pourquoi Rudder ne se lançait jamais alors que la communication avec le serveur semblait OK, je suis allé voir ce que faisait le service systemd rudder-agent.service.

cat /lib/systemd/system/rudder-agent.service
[Unit]
Description=Rudder agent umbrella service
Documentation=man:rudder(8)
Documentation=https://docs.rudder.io
After=syslog.target
# Dependencies register themselves with a WantedBy/RequiredBy
# currently they are rudder-cf-serverd and rudder-cf-execd
[Service]
Type=oneshot
RemainAfterExit=yes
# This is required for the service to be able to
# pass these commands to its dependencies
ExecStart=/bin/true
ExecReload=/bin/true
[Install]
WantedBy=multi-user.target

Et là, c’était tout de suite plus clair. Le service rudder-agent est en réalité un simple service “chapeau”, dont dépendent 2 sous services rudder-cf-serverd et rudder-cf-execd.

Or, par défaut, quand vous désinstallez rudder-agent (à minima sur Debian/Ubuntu), les services rudder-cf-serverd.service et rudder-cf-execd.service sont “disabled” mais pas re-“enabled” à la réinstallation.

root@node01:/# systemctl status rudder-cf-serverd
● rudder-cf-serverd.service - CFEngine file server
Loaded: loaded (/lib/systemd/system/rudder-cf-serverd.service; disabled; vendor preset: enabled)
Active: inactive (dead)

Rudder ne faisait rien, tout simplement parce qu’il n’était juste pas activé :D. On règle ça en 4 commandes :-P

root@node01:/# systemctl enable rudder-cf-serverd
Created symlink /etc/systemd/system/multi-user.target.wants/rudder-cf-serverd.service → /lib/systemd/system/rudder-cf-serverd.service.
Created symlink /etc/systemd/system/rudder-agent.service.wants/rudder-cf-serverd.service → /lib/systemd/system/rudder-cf-serverd.service.
root@node01:/# systemctl start rudder-cf-serverd
root@node01:/# systemctl enable rudder-cf-execd
Created symlink /etc/systemd/system/multi-user.target.wants/rudder-cf-execd.service → /lib/systemd/system/rudder-cf-execd.service.
Created symlink /etc/systemd/system/rudder-agent.service.requires/rudder-cf-execd.service → /lib/systemd/system/rudder-cf-execd.service.
root@node01:/# systemctl start rudder-cf-serverd

Note : je ne suis pas convaincu que ce soit un comportement voulu, j’ai remonté le point à la team Rudder, je vous tiendrais au courant.

Conclusion

Voilà les quelques petits trucs rigolos que j’ai eu avec Rudder pour l’instant.

Je ne sais pas quand je ferai le prochain article sur Rudder. La version 8 approche doucement, ça sera peut-être à cette occasion (il y a une fonctionnalité que j’attends dedans).

On a pas non plus parlé des plugins. Ca pourrait valoir le coup (il en existe certains uniquement utilisables avec la version entreprise que je n’ai pas, mais aussi des gratuits).

A voir. En attendant, have fun !

Premiers pas avec Rudder - concepts et configuration

Fri, 24 Mar 2023 06:30:00 +0200

On reprend où on en était

Dans l’article précédent, je m’étais arrêté après l’installation du serveur Rudder sur une machine Ubuntu, ainsi que d’un agent.

Dans cet article, je pars du principe qu’on est un peu plus loin dans le temps. On a installé des agents à droite à gauche.

Dans mon cas, j’ai une dizaine de machines Debian et Ubuntu, provenant de VMs (chez nua.ge) et d’hyperviseurs/containers LXC (Proxmox VE).

Pour le “fun”, j’aurais pu faire l’effort d’installer des machines Windows mais je n’ai pas eu le courage. Peut-être une autre fois.

Node Inventory

C’est cool d’avoir une flotte de machines dans notre Rudder, mais qu’est-ce qu’on peut faire avec ?

La première chose qu’on peut faire, c’est d’aller voir ce que l’agent remonte comme info au serveur. Un peu comme les “facts” d’Ansible. Ca nous sera utile par la suite.

On va donc choisir un de nos “nodes” dans la liste et regarder l’onglet Inventory pour voir ce qu’on peut faire avec.

Je n’ai pas creusé en détail pour savoir s’il y avait plus d’infos collectées que ce qui est affiché dans ce menu, mais on a déjà de quoi faire, en parcourant toutes les catégories.

Grosso modo on va utiliser ces infos-là pour définir des groupes, puis l’état souhaité de nos machines.

Groups

Dans la terminologie Rudder, les serveurs sont des “nodes”, on en a déjà parlé. On va ensuite regrouper nos nodes par “groups” (avec une relation n-to-n).

Il y a plusieurs catégories de groupes. On peut soit regrouper les nodes par groupes statiques (pas super efficace quand on passe à l’échelle), soit tirer parti des informations trouvées dans l’inventaire (cf section précédente) pour créer des groupes dynamiques.

Enfin, il existe une dernière catégorie de groupes, dits “system” qui des groupes spéciaux gérés par Rudder.

On retrouve ça dans l’interface de Rudder dans la partie Node management / Groups.

Créer un groupe pour tous les serveurs Ubuntu

Comme j’ai beaucoup de serveurs Ubuntu, la première idée qui m’est venue à l’esprit a été de créer un groupe pour les regrouper.

Dans ce menu, il existe 2 choses qu’on peut créer. Des Categories et des Groups.

Je fais un mini aparté sur les Categories, concept qu’on pourra retrouver ailleurs dans l’interface. Il s’agit de subdivisions logiques (des “dossiers”, en gros) qui permettent de faciliter le rangement de nos bidules.

Comme j’aime bien que les choses soient bien rangées, j’ai commencé donc par créer une catégorie “By OS” pour regrouper tous mes groupes.

Une fois que c’est fait, on peut rentrer dans le dur et créer un groupe dynamique pour nos serveurs Ubuntu.

Quand on clique sur create, on peut ensuite ajouter les conditions pour déterminer si un hôte est dans le groupe ou pas.

Jusque-là, rien de bien foufou, on demande à Rudder de se baser sur les infos de l’inventaire et de matcher ou pas avec une regex.

Je note la petite feature de preview, qui permet de voir d’un coup d’œil si ça matche bien les bons hosts. C’est très sympa :)

Autre remarque, le menu déroulant est assez pratique à utiliser et assez fourni (c’est les infos de l’inventaire, donc assez riche).

Un exemple de ce qu’on peut faire juste avec la partie “node summary” :

Pour l’instant, rien de bien compliqué/original.

Un peu de théorie

C’est là où ça se corse (un peu, pas beaucoup). Avant d’aller plus loin, il va falloir comprendre quelques concepts propres à Rudder.

Je pompe honteusement le schéma de la doc officielle pour faire un support visuel, puis j’explique ensuite :

On a déjà parlé de notre relation n-to-n avec nos nodes et nos groups. Si on se concentre sur la partie gauche, on découvre 3 nouveaux concepts :

les techniques
les directives
les rules

Les techniques, c’est les fonctionnalités que rudder va appliquer ou vérifier sur nos nodes. Les techniques sont configurables et c’est pour ça qu’on va créer des directives à partir de ces techniques (relation 1-to-n).

Et pour finir, les rules sont ce qui va relier un certain nombre de groupes à un certain nombre de directives.

Premier exemple de directive

Quand j’ai commencé à tester Rudder, une CVE (de plus) venait de sortir sur sudo. Je voulais voir si Rudder était capable de vérifier si mes binaires sur mes ubuntu étaient patchés ou pas.

Je suis donc allé dans le menu Directives, cliqué dans la liste sur la technique Packages et j’ai créé ma directive à partie de cette technique.

Cette directive est relativement triviale, on fera des exemples plus complexes dans l’article suivant. Mais ça vous donne une idée du concept.

Première rule

Une fois la directive sauvegardée, on va créer une rule qui va regrouper nos groups et notre directive.

Comme vous pouvez le voir, c’est relativement trivial. Une fois que c’est validé, rudder passe sur tous nos nodes pour appliquer la nouvelle configuration.

On peut retrouver sur le Dashboard principal pour voir ce qu’il se passe de manière globale

Ou aller sur un node en détail et aller lire l’historique

Et si je ne veux pas appliquer ?

Par défaut, le “Policy mode” est positionné sur “Enforce”, ce qui veut dire que Rudder va auditer nos systèmes, puis les corriger s’ils ne sont pas conformes.

Si on veut faire ça, il suffit de positionner la directive sur “Audit”, et utiliser l’option “This specific version” plutôt que “Latest available version”.

Voici le résultat sur un node qui n’était pas à jour :

Conclusion

Voilà pour une très brève introduction sur le système de configuration des nodes et des politiques de conformité avec Rudder.

J’ai pris un exemple très très basique, mais il permet de se faire une idée rapide de la facilité d’utilisation de Rudder.

Premiers pas avec Rudder - Installation

Sun, 19 Mar 2023 14:30:00 +0200

Mais d’abord, c’est quoi Rudder ?

Rudder est un logiciel open-source de gestion de configuration et d’automatisation des systèmes, qui permet aux administrateurs système de contrôler et de gérer leurs infrastructures de manière industrialisée. Il est en grande majorité édité par la société Normation, qui vend du support et des fonctionnalités complémentaires (plugins).

Pendant longtemps, j’ai un peu mis de côté Rudder, pensant que ce n’était pas pour moi, surtout que j’avais investi beaucoup de temps dans Ansible (vous trouverez mes nombreux articles sur le sujet ici).

Cependant, ce qui fait à la fois la force et la faiblesse d’Ansible, c’est le fait qu’il soit agentless. On peut lancer nos playbooks depuis n’importe quelle machine, mais ça veut aussi dire qu’il n’y a pas a priori de machine privilégiée pour garder notre infra conforme dans la durée.

Alors oui, je sais qu’on va me rétorquer qu’il existe Tower/AWX, mais je n’ai pas du tout apprécié l’expérience le peu que je l’ai testé, au point de ne pas vouloir l’utiliser ni au travail, ni en perso. En particulier en perso, je trouve l’outil lourd et pas adapté pour mon objectif : garantir la conformité de mes quelques machines.

Parallèlement à ça, Rudder fonctionne avec un agent, et il y a un serveur centralisé qui contrôle les serveurs enregistrés. On peut consulter le tout dans une interface web et on voit en un clin d’oeil si les serveurs sont conformes ou pas.

Sans juger de l’expérience avec des centaines voire des milliers de serveurs, ça me parait adapté pour mon besoin perso (gérer une flotte de quelques machines voire dizaines de machines).

Installation du serveur

Je vais essayer de ne pas passer trop de temps sur cette partie. Elle a déjà été détaillée récemment par Stéphane Robert sur son blog et par Nidouille en stream la semaine dernière.

Grosso modo, j’ai popé une VM chez nua.ge en Ubuntu 22.04 avec 2 CPU et 2 Go de RAM, suivi la documentation officielle d’installation et basta.

sudo apt update
sudo apt upgrade
sudo wget --quiet -O /etc/apt/trusted.gpg.d/rudder_apt_key.gpg "https://repository.rudder.io/apt/rudder_apt_key.gpg"
echo "deb http://repository.rudder.io/apt/7.2/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rudder.list
(output) deb http://repository.rudder.io/apt/7.2/ jammy main
sudo apt update

Note : j’étais assez content de voir dans la doc officielle que pour quelques nodes, 2 CPU / 2 Go de RAM suffisent (surtout qu’il y a une JVM, donc la conso RAM aurait pu être bien plus importante).

On nous conseille évidemment de vérifier que la clé correspond à celle indiquée dans la documentation officielle, puis on l’ajoute (affichée au moment de l’apt update) et on installe le package contenant le serveur.

apt install rudder-server

Une fois installé, la première chose à faire est de créer un utilisateur admin, puis on peut se connecter sur l’IP du serveur en HTTPS/443 (certificat autosigné par contre, faudra que je regarde comment ajouter du let’s encrypt).

ubuntu@rudder:~$ sudo rudder server create-user -u toto
New password:
Re-type new password:
User 'toto' added, restarting the Rudder server

Côté sécurité réseau, il va falloir ouvrir les ports 443 (obviously) mais aussi le 5309 pour que ça marche bien ( pour la partie “Fetch policy”, je vous laisse aller lire la doc).

Installation des agents

Même topo pour les agents, j’ai suivi la doc.

On peut donc installer simplement un agent sur nos serveurs en ajoutant la clé + le repo de rudder, puis en lançant la commande

sudo wget --quiet -O /etc/apt/trusted.gpg.d/rudder_apt_key.gpg "https://repository.rudder.io/apt/rudder_apt_key.gpg"
echo "deb http://repository.rudder.io/apt/7.2/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rudder.list
sudo apt update && sudo apt install rudder-agent

A partir de là, l’agent ne sait pas où il doit s’enregistrer. On ajoute l’agent au serveur Rudder :

sudo rudder agent policy-server <IP.Du.Rudder.Server>

Petite subtilité, je n’ai pas eu besoin de faire cette étape dans un premier temps, car il se trouve que par défaut, les agents cherchent sur le LAN une machine s’appelant “rudder”. J’étais donc un poil surpris de ne pas voir cette info dans la doc (il faut que je fasse une PR pour corriger ça).

On vérifie ensuite que tout fonctionne :

sudo rudder agent inventory
Rudder agent 7.2.4
Node uuid: 72577f55-46b0-47e2-acd0-2eeb45353122
M| State Technique Component Key Message
E| compliant Common Compute inventory splay Scheduling rudder_run_inventory was correct
E| compliant Inventory Inventory The inventory has been successfully sent
info Rudder agent was run on a subset of policies - not all policies were checked
## Summary #####################################################################
2 components verified in 3 directives
=> 2 components in Enforce mode
-> 2 compliant
Execution time: 10.67s
################################################################################

Note : On prendra évidemment garde à ne pas ouvrir les ports des serveur/agents Rudder sur Internet et à utiliser des IPs locales et/ou des firewalls pour filtrer proprement tout ça. On pourra aussi utiliser un VPN, mais il ne faudra pas oublier d’autoriser les IPs des machines distantes dans Rudder (on en reparlera).

Accepter les machines dans notre inventaire

Un point qui n’était pas super clair pour moi dans la doc de Quickstart d’installation des agents, est qu’une fois que les agents étaient installés, il faut les autoriser côté serveur. C’est logique (on ne veut pas autoriser n’importe qui) mais la doc méritera une petite suggestion de ma part je pense.

Ce point est détaillé dans une autre partie de la documentation Node management / Accept new nodes, mais même cette partie de la documentation ne semble pas à jour, car je n’ai pas vu de menu “Navigate to Node Management → Accept new Nodes.”

On a en revanche un menu “Pending nodes” où on retrouve une liste de tous les agents fraichement installés en attente.

La suite ?

A partir de là, on a installé tout ce qu’on avait besoin d’installer pour commencer à jouer avec Rudder.

Cependant, on est déjà à 8000 signes et entamer la partie configuration dans cet article me parait lourd.

Je vais arrêter ici pour aujourd’hui et publier dans un prochain article (semaine prochaine surement) comment créer des groupes, ce que sont les rules et les directives en un seul et même bloc (ça sera plus cohérent).

En attendant, have fun !