Pas testé mais rudder.io peut être. Nicolas Girardi.
> Le 18 sept. 2025 à 18:44, Gilles Mocellin <[email protected]> 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/ _______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
