Il y a Rexify, en Perl https://www.rexify.org/
et sinon, dans une optique bien différente : Drist https://dataswamp.org/~solene/2018-11-29-drist-intro.html
Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :
Hello,
(Désolé par avance pour le pâté...)
Depuis des années je gère la configuration de mes serveurs grâce à Salt (SaltStack). J’aime beaucoup ses concepts (States, Pillar, Grains, templates Jinja...) qui permettent de créer une « formule » pour telle ou telle chose et de la déployer avec des paramètres différents en fonction des environnements, des hébergeurs, des clients...
Mais il y a toujours eu quelques problèmes :
Pendant longtemps le moyen privilégié de déployer Salt était de déployer un « master » (serveur) auquel les « minions » (clients) se connectaient. Il y a eu un certain nombre de failles graves sur le master qui permettaient à n’importe qui d’exécuter n’importe quel code arbitrairement sur tous les minions. Alors ça peut arriver, le master est de toute façon censé être derrière un firewall, mais ça s’est reproduit quelques fois. Avec les parc à mettre à jour en catastrophe à chaque fois. Ce qui nous amène au point suivant.
Je ne sais pas où ça en est aujourd’hui, mais pendant longtemps la couverture du code par des tests était ridicule. D’où les mêmes bugs et failles qui reviennent sans arrêt. Plusieurs fois je me suis retrouvé à mettre à jour mon parc pour échapper à un bug qui n’aurait jamais dû pouvoir arriver jusqu’à une release dite stable, pour au final tomber sur un autre bug bloquant.
En 2020, VMware a racheté SaltStack, dans le but de baser dessus son produit VMware Tanzu. Comme beaucoup j’étais moyennement enthousiaste, mais après tout si ça voulait dire des développeurs payés pour bosser sur Salt, tant mieux.
En 2023, Broadcom, bien connue pour sa spécialisation dans le rachat / essorage / dépeçage / revente de boîtes de la tech rachète VMware. Les derniers anciens de la team SaltStack sont parties, les moyens semblent avoir été réduits au strict minimum et Salt est plus en maintenance qu’autre chose. Les bugs et PR n’avancent pas, certaines fonctionnalités sont cassés (notamment la gestion des configurations réseau qui est catastrophique).
Bref, ça sent le début de la fin. Je ne suis pas très enthousiaste à l’idée de réécrire toutes mes formules mais j’ai bien peur qu’il faille y passer. Le problème est que la concurrence ne fait pas franchement rêver :
Puppet a été rachetée par Perforce en 2022, qui a tuée la version open-source. La communauté a crée un fork (OpenVox) qui semble vivoter. La doc redirige sur celle de Puppet. J’ai jamais été trop fan de la syntaxe Puppet.
Chef a été rachetée par Progress en 2020. Vague de licenciements dans la foulée. Changement de licence et création d’un faux fork (CINC) par des employés de Progress eux-mêmes (?) qui distribuent des binaires uniquement. Menaces à peine voilées de poursuites aux distribs qui continuent de le packager (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981).
Ansible : semble être devenu la référence, open-source, développé par Red Hat. Pas mal d’issues et de PR ouvertes sur GitHub, mais ça ne me semble pas anormal vu le nombre d’utilisateurs. Et les tickets n’ont pas l’air d’êtres laissés à l’abandon pour le coup. Mais je n’ai jamais vraiment accroché. Contrairement à Salt qui est très organisé, Ansible me donne l’impression d’un tas de fichiers YAML jetés dans un répertoire. Il a la réputation d’être très lent. De plus, j’ai besoin de m’assurer de l’intégrité de mon système : lorsque j’execute Salt, j’ai la garantie que toutes mes formules configurées sur ce serveur seront exécutées. Je ne vois pas comment faire ça avec Ansible (j’ai survolé la doc j’avoue).
J’ai trouvé une myriade de trucs alternatifs : certains qui débutent, certains abandonnés, certains proprios...
Bref, je suis preneur de vos avis, conseils, expériences avant de me lancer dans un grand chantier de réécriture... :) Je précise que j’administre uniquement de serveurs Debian.
Merci