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/

Bonjour,

J'ai aussi fait partie des "early adopters" SaltStack; j'en ai fait pendant des années, j'ai géré toute mon infrastructure avec ça sous git avec des runners, avec notamment la gestion événementielle/réacteurs, les orchestrateurs; j'ai même écrit des modules Salt (au début les tests étaient insignifiants sur le dépôt github, puis c'est devenu une usine à gaz...). Bref, que du bonheur, jusqu'à... Des bugs réguliers dans les systèmes gitfs devenus de plus en plus réguliers, puis les rachats successifs où c'est devenu bien la m...

Je me suis progressivement à Ansible : plus simple, basique, mais oui, aussi plus lent... Du moins, c'était vrai jusqu'à l'arrivée de mitogen, que je n'ai pas suffisamment testé pour affirmer que ça a totalement résolu le problème (contrairement à Salt, il n'y a pas une gestion de queue avec ZeroMQ).

Néanmoins, il faut se l'avouer, SaltStack est peu adopté face à Ansible, même s'ils me semblent que de gros noms utilisent toujours Salt. J'ai changé deux fois d'équipe et personne ne sait faire, voir parfois ne connait vraiment SaltStack... J'ai bien essayé de former une des équipes, mais ils n'avaient pas le temps...

Avec Ansible, tu as l'avantage de connaitre déjà jinja et le templating, python derrière; il y a quand même un gros socle commun même si la logique est très différente (voir inversé même). Par défaut, Ansible est idempotant, mais peut ne pas l'être (ex: module raw); pour SaltStack, c'est l'inverse (pas idempotent par défaut, mais peut l'être selon comment tu l'utilises).

Une fois que tu auras compris la mécanique assez simple Ansible (et même si c'est moins puissant que SaltStack), tu pourras faire tes premières recettes (une lecture pour s'y mettre : https://www.ansiblefordevops.com/).

My 2 cts,

Envoyé avec un e-mail sécurisé Proton Mail.

Le jeudi 18 septembre 2025 à 18:14, Jonathan Leroy via FRsAG frsag@frsag.org 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/