Pas testé mais rudder.io peut être.
Nicolas Girardi.
Le 18 sept. 2025 à 18:44, Gilles Mocellin gilles.mocellin@nuagelibre.org a écrit :
Hello,
Il y a longtemps, j'avais bien adhéré aussi à Salt, puis, devant faire un choix dans une nouvelle boite, avec aucun système en place, aucune connaissance préalable des équipes, j'avais considéré que même avec ses défauts, Ansible restait le plus accessible.
Par contre, oui, il faut un système pour centraliser les playbooks, rôles, configurations... RedHat a son Ansible Tower, avec la version OpenSource AWX. Pas regardé car, nous avions choisi Foreman. Qui permettait aussi de gérer le provisionning, (PXE ou en pilotant des infra IaaS).
C'est loin d'être génial, c'était conçu à la base pour Puppet, mais comme c'est aussi la base d'un produit RedHat, le support d'Ansible s'est amélioré.
Un élément qui améliore aussi un peut le "bazar" Ansible, ce sont les collections.
De nos jours, si on a la volonté d'avoir une approche DevOps, on doit pouvoir utiliser un repo Git et une pipeline de CI/CD pour centraliser la configuration dans Git, et lancer les playbooks avec un environnement reproductible via des "runners".
Le jeudi 18 septembre 2025, 18:11:28 heure d’été d’Europe centrale 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
-- Jonathan Leroy _______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Liste de diffusion du French Sysadmin Group https://www.frsag.org/