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
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
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/
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/
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".
pour ma part je fais cela avec Ansible sur du Gitlab avec un script qui définit deux choses:
1. si un nouveau nœud est ajouté dans l'inventaire/fichier hosts
new_servers=`git diff --cached --diff-filter=M $CI_MERGE_REQUEST_DIFF_BASE_SHA -- hosts | \ grep -vE '^+++|^+$' | grep '^+' | sed 's/^+//' | grep -vE '^[[:space:]]*($|#|[)' | \ grep -v ansible_docker_extra_args | grep -v = | awk '{print $1}' | sort -uV` || true
2. si un rôle en particulier est modifié
roles=`git diff --cached --raw --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA | xargs dirname | sed -r 's@^([^/]+).*@\1@' | sort -uV | sed '/^./d'`
dans le premier cas je lance l'install et la config des rôles sysprep + monitoring + sshguard. dans le second cas je lance uniquement le rôle en question pour tous les serveurs.
ce n'est pas tout à fait standard (et je vous en voudrai pas trop si vous trouvez que c'est crado), car mes rôles se trouvent simplement à la racine du repository.
je suis curieux de savoir comment vous faites votre CI/CD avec une architecture de répertoire standard. d'ailleurs je devrais sans doute ouvrir un thread séparé à cet effet.
-elge
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/
Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :
Hello,[...]
@work on a toujours considéré que les deux approches suivantes étaient différentes et complémentaires : - l'audit continu avec correction et convergence vers un état souhaité - pousser one-shot une série de directives vers un ensemble de serveurs/services/configs.
Pour l'audit continu, j'ai passé pas mal d'années avec le grand-père de tous les Puppet/Salt/Chef, à savoir Cf-Engine (issu de recherches universitaires), mais il faut reconnaître qu'en plus d'apprendre à maîtriser le langage bien spécifique et au comportement curieux, il a fallu s'acculturer à des attitudes pas forcément ergonomiques.
Après plusieurs années et à l'occasion d'un nouveau job, je suis passé sur sa version user-friendly : Rudder. Dans les premières années, Rudder était totalement basé sur cf-engine, mais en tant qu'utilisateur, tout se gère via une interface web. Comme tous ces produits, le plus confortable consiste à rester dans les limites "builtin" du produit, et éviter si possible de ré-écrire ses propres directives. Mais c'est évidemment possible de le faire, d'y ajouter ses templates, etc... Le GUI Web nous synthétise en permanence le pourcentage de convergence de notre parc par rapport à nos directives. La boîte qui tient ce produit se nomme Normation, et est me semble-t-il Lyonnaise et québécoise. Elle existe depuis un bon nombre d'années, elle me semble stable, et les rapports qu'on a avec les devs via leur Redmine + forum sont des plus agréables, depuis au moins 10 ans.
Pour l'aspect one-shot, on a absolument tout basé sur Ansible, et comme l'ont dit les collègues, l'usage des collections fut une révélation, en plus de tout ce qui marche déjà vraiment très bien pour nos usages. La lenteur générale d'Ansible n'est pas un frein chez nous, car comme indiqué, ces actions one-shot ne se déroulent jamais dans un contexte d'urgence.
Bien entendu si on parle convergence oui il faut puppet/chef ou salt. Mais la convergence c'est une épine dans le cul relative ... faire converger ses settings firewall avec puppet c souvent le bordel quand un déploiement nécessite d'autre ports et les ouvre ou à la révocation du service ou si on les a poussé par puppet il faut alors pensé à les révoquer. D'un autre côté puppet devrait (je n'ai pas assez joué avec) ne s'occuper que d'une chaîne nftable afin de structuré son firewall sur un modèle règles globales d'entreprise et règles spécifiques applicative.... ou pire croiser les effluves et pousse un manifeste de règles à appliquer a puppet avec le rôle ansible qui déploie l'outil (delegate to : puppet master) ... bref des choses qui doivent se faire mais je n'ai pas assez fait de puppet pour confirmer le modèle que je propose ici.
Le 19 sept. 2025 à 11:37, Nec via FRsAG frsag@frsag.org a écrit :
Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :
Hello,[...]
@work on a toujours considéré que les deux approches suivantes étaient différentes et complémentaires :
- l'audit continu avec correction et convergence vers un état souhaité
- pousser one-shot une série de directives vers un ensemble de serveurs/services/configs.
Pour l'audit continu, j'ai passé pas mal d'années avec le grand-père de tous les Puppet/Salt/Chef, à savoir Cf-Engine (issu de recherches universitaires), mais il faut reconnaître qu'en plus d'apprendre à maîtriser le langage bien spécifique et au comportement curieux, il a fallu s'acculturer à des attitudes pas forcément ergonomiques.
Après plusieurs années et à l'occasion d'un nouveau job, je suis passé sur sa version user-friendly : Rudder. Dans les premières années, Rudder était totalement basé sur cf-engine, mais en tant qu'utilisateur, tout se gère via une interface web. Comme tous ces produits, le plus confortable consiste à rester dans les limites "builtin" du produit, et éviter si possible de ré-écrire ses propres directives. Mais c'est évidemment possible de le faire, d'y ajouter ses templates, etc... Le GUI Web nous synthétise en permanence le pourcentage de convergence de notre parc par rapport à nos directives. La boîte qui tient ce produit se nomme Normation, et est me semble-t-il Lyonnaise et québécoise. Elle existe depuis un bon nombre d'années, elle me semble stable, et les rapports qu'on a avec les devs via leur Redmine + forum sont des plus agréables, depuis au moins 10 ans.
Pour l'aspect one-shot, on a absolument tout basé sur Ansible, et comme l'ont dit les collègues, l'usage des collections fut une révélation, en plus de tout ce qui marche déjà vraiment très bien pour nos usages. La lenteur générale d'Ansible n'est pas un frein chez nous, car comme indiqué, ces actions one-shot ne se déroulent jamais dans un contexte d'urgence.
-- Nicolas _______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Le 19/09/2025 à 11:35, Nec via FRsAG a écrit :
Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :
Hello,[...]
@work on a toujours considéré que les deux approches suivantes étaient différentes et complémentaires :
- l'audit continu avec correction et convergence vers un état souhaité
- pousser one-shot une série de directives vers un ensemble de
serveurs/services/configs.
Pour l'audit continu, j'ai passé pas mal d'années avec le grand-père de tous les Puppet/Salt/Chef, à savoir Cf-Engine (issu de recherches universitaires), mais il faut reconnaître qu'en plus d'apprendre à maîtriser le langage bien spécifique et au comportement curieux, il a fallu s'acculturer à des attitudes pas forcément ergonomiques.
Après plusieurs années et à l'occasion d'un nouveau job, je suis passé sur sa version user-friendly : Rudder. Dans les premières années, Rudder était totalement basé sur cf-engine, mais en tant qu'utilisateur, tout se gère via une interface web. Comme tous ces produits, le plus confortable consiste à rester dans les limites "builtin" du produit, et éviter si possible de ré-écrire ses propres directives. Mais c'est évidemment possible de le faire, d'y ajouter ses templates, etc... Le GUI Web nous synthétise en permanence le pourcentage de convergence de notre parc par rapport à nos directives. La boîte qui tient ce produit se nomme Normation, et est me semble-t-il Lyonnaise et québécoise. Elle existe depuis un bon nombre d'années, elle me semble stable, et les rapports qu'on a avec les devs via leur Redmine + forum sont des plus agréables, depuis au moins 10 ans.
Pour l'aspect one-shot, on a absolument tout basé sur Ansible, et comme l'ont dit les collègues, l'usage des collections fut une révélation, en plus de tout ce qui marche déjà vraiment très bien pour nos usages. La lenteur générale d'Ansible n'est pas un frein chez nous, car comme indiqué, ces actions one-shot ne se déroulent jamais dans un contexte d'urgence.
Qq commentaires
Avec ansible on relance tout et c'est à la charge des modules de gérer l'idempotence, ce qui est plutôt bien fait... Dans les quelques rares cas où on utilise le module shell/command parce qu'on ne peut faire autrement, il faut bien blinder avec des conditions pour essayer de rendre idempotent
Sinon pour les aspects vitesses, il est possible de tuner un peu ansible, voici par exemple un guide sur le sujet : https://spacelift.io/blog/how-to-improve-ansible-performance
Sinon il n'y a pas d'outil magique dans la liste de ceux exposés, tous ont des avantages et des inconvénients :
En perte de vitesse - cfgengine - chef (si tu installes configure du gitlab, tu en fais certainement sans le savoir ;-) )
- salt
Les plus mainstream
- Puppet :
--> n'est plus très opensource... un fork est né https://github.com/openvoxproject --> nécessite un agent, c'est bien pour la rapidité et pour un fonctionnement en mode je reste sur une cible.... mais ça reste un agent à installer avec un port à ouvrir
--> pratique pour éviter les modifications de conf sur un serveur puisque la conf est remise à la cible presqu'immédiatement
--> le bump de version majeure est souvent compliqué --> en perte de vitesse depuis que RedHat pousse ansible
- Ansible
--> Grosse communauté
--> Qq grosses sociétés ont contribuées des améliorations (Cisco notamment ds mon souvenir d'une présentation)
--> Une certaine lenteur si tu as de gros gros gros playbook
- Terraform plus adapté pour la partie cloud... mais pas adapté pour de la conf réseau ou d'un serveur
Après à certains endroits, j'ai déja vu la combinaison de plusieurs outils... Du terraform, un kickstart ou preseed bien tuné, un puppet puis de l'ansible
De mon côté terraform/opentufu + ansible + kickstart/preseed en général on arrive à ses fins
Cdlt,
JYL
Le Fri, Sep 19, 2025 at 12:18:16PM +0200, Jean-Yves LENHOF via FRsAG a écrit:
- Puppet :
--> n'est plus très opensource... un fork est né https://github.com/openvoxproject
Il ne semble malheureusement pas très vivant. Je voulais migrer dessus, j'attendais que ça commence à ressembler à quelque chose... Pour l'instant, ils ont l'air encore à moitié dans la politique et le "qu'est-ce qu'on fait". Ce ne serait plus mon choix en repartant de zéro aujourd'hui...
--> nécessite un agent, c'est bien pour la rapidité et pour un fonctionnement en mode je reste sur une cible.... mais ça reste un agent à installer avec un port à ouvrir
Heuu... ? Sur le serveur oui, mais justement sur l'agent, il n'y a rien à ouvrir, c'est ça qui est pratique.
--> pratique pour éviter les modifications de conf sur un serveur puisque la conf est remise à la cible presqu'immédiatement
La version de base, c'est l'agent se lance régulièrement, soit en version démon, soit par un cron; donc c'est "immédiat" si ça se lance vite, sinon il faut attendre le cron...
(je déconseille le démon, il bouffe une ram folle) (rends la ram)
--> le bump de version majeure est souvent compliqué
"compliqué", en lisant les releases notes, ça passe assez facilement. C'est plutôt les modules qui sont compliqués, la plupart (de ceux gérées par puppet/perforce) ont mis quasiment deux ans à supporter la debian 12, avec des commentaires WTF du genre "ah le serveur bookworm est pas sorti donc on supporte pas la deb12 dans le module").
J'attends la même pour trixie, Par exemple, le support "officiel" de deb12 dans le module mysql est arrivé en décembre 2024... Soit 8 mois avant la sortie de la trixie. Classe.
--> en perte de vitesse depuis que RedHat pousse ansible
Surtout en perte de vitesse depuis que perforce a pourri le produit et (tenté de ? réussi à ?) faire une broadcom...
Bref, puppet, ça pue actuellement. OpenVox, j'attends toujours.
Arnaud.
Le 2025-09-19T12:20:07.000+02:00, Jean-Yves LENHOF via FRsAG frsag@frsag.org a écrit :
Le 19/09/2025 à 11:35, Nec via FRsAG a écrit :
Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :
Hello,[...]
@work on a toujours considéré que les deux approches suivantes étaient différentes et complémentaires : - l'audit continu avec correction et convergence vers un état souhaité - pousser one-shot une série de directives vers un ensemble de serveurs/services/configs. Pour l'audit continu, j'ai passé pas mal d'années avec le grand-père de tous les Puppet/Salt/Chef, à savoir Cf-Engine (issu de recherches universitaires), mais il faut reconnaître qu'en plus d'apprendre à maîtriser le langage bien spécifique et au comportement curieux, il a fallu s'acculturer à des attitudes pas forcément ergonomiques. Après plusieurs années et à l'occasion d'un nouveau job, je suis passé sur sa version user-friendly : Rudder. Dans les premières années, Rudder était totalement basé sur cf-engine, mais en tant qu'utilisateur, tout se gère via une interface web. Comme tous ces produits, le plus confortable consiste à rester dans les limites "builtin" du produit, et éviter si possible de ré-écrire ses propres directives. Mais c'est évidemment possible de le faire, d'y ajouter ses templates, etc... Le GUI Web nous synthétise en permanence le pourcentage de convergence de notre parc par rapport à nos directives. La boîte qui tient ce produit se nomme Normation, et est me semble-t-il Lyonnaise et québécoise. Elle existe depuis un bon nombre d'années, elle me semble stable, et les rapports qu'on a avec les devs via leur Redmine + forum sont des plus agréables, depuis au moins 10 ans. Pour l'aspect one-shot, on a absolument tout basé sur Ansible, et comme l'ont dit les collègues, l'usage des collections fut une révélation, en plus de tout ce qui marche déjà vraiment très bien pour nos usages. La lenteur générale d'Ansible n'est pas un frein chez nous, car comme indiqué, ces actions one-shot ne se déroulent jamais dans un contexte d'urgence.
Qq commentaires Avec ansible on relance tout et c'est à la charge des modules de gérer l'idempotence, ce qui est plutôt bien fait... Dans les quelques rares cas où on utilise le module shell/command parce qu'on ne peut faire autrement, il faut bien blinder avec des conditions pour essayer de rendre idempotent Sinon pour les aspects vitesses, il est possible de tuner un peu ansible, voici par exemple un guide sur le sujet : https://spacelift.io/blog/how-to-improve-ansible-performance
Hello,
ansible peut être lent, mais avec mitogen, ca va vraiment beaucoup plus vite. mes playbooks se déroulent souvent x5 plus vite. Et il est très fortement recommandé comme indiqué sur le lien ci dessus d'utiliser redis pour les facts. Avec les jsonfile, il faut s'attendre à beaucoup d’accès disques et même des "Too many open files" quand la cible est volumineuse.
sinon, alternative ansible (push) que je n'ai pas encore essayé: ansible-pull. Chaque noeud execute le(s) playbook(s) en local. Il y a des avantages et inconvénients comme toute solution.
Ronan
Bonjour,
Je prends le thread et vais ajouter ma couche…
Comme certain d’entre vous j’ai aussi bossé sur le grand père de Chef/Puppet : cfengine avec ses avantages et des fois, oui, des comportements étrange.
Puis passé sur Puppet. Que j’ai pas mal aimé… Le passage de puppet server avec du Java m’as copieusement gonflé… dans la série pourquoi faire simple quand on peux faire de la merde… (et je ne parle pas quand je dois débugger un truc)…
J’ai essayé Salt parce que j’ai hérité d’un truc comme ça. Vu que VMWare/Broadcom l’ont « acheté » c’est certain que je vais pas continuer… Sans compter la dépendant avec python et ses emmerdes liées (incompatibilités, etc… même si ça s’est *UN* peu amélioré)…
Quand à ansible… bon… alors… je n’ai vraiment aucune idée pourquoi les gens veulent faire leur MCO avec un outil qui est plutôt focussé sur le déploiement… Sachant que ce machin doit avoir un « mini setup » pour qu’il puisse être exécuté. Pour moi c’est utile dans les taches répétitives pas pour du MCO. Dernier redflag: dépend de python (ou mython) … donc voila end of story
Reste a tester rudder… je le mets dans ma TODO…
/Xavier
— Xavier BEAUDOUIN SiamNok Ltd - Smart Solutions for Koh Samui https://siamnok.co.th/ X: @SiamNokCoTh
Mython : Mytho Python… (C)iMil :D
Mython, c'est le pendant système de Metoo ?
Mython : Mytho Python… (C)iMil :D
— Xavier BEAUDOUIN SiamNok Ltd - Smart Solutions for Koh Samui https://siamnok.co.th/ X: @SiamNokCoTh
ronan.s@lmon.io, 19/09/2025 – 13:33:11 (+0200):
ansible peut être lent, mais avec mitogen, ca va vraiment beaucoup plus vite. mes playbooks se déroulent souvent x5 plus vite.
+1
Mes tests montrent même du x7, c'est devenu incontournable et je ne peux plus m'en passer. Attention quand même, le projet a souvent un peu de mal à suivre la cadence des releases Ansible. Donc c'est souvent pas possible d'utiliser les toutes dernières versions de Ansible (ce qui n'est pas forcément une mauvaise chose).
Pour la partie MCO (maintient de l'état des machines), j'ai jamais utilisé AWX ou Tower, trop usine à gaz j'ai l'impression (mais pas d'expérience, donc...). Par contre j'ai un runner qui chaque nuit fait un déploiement en mode check et m'alerte si des changements ont été détectés. Évidement, c'est moins, performant ou précis que ce qu'on peut faire avec Puppet ou Chef (notamment car j'ai un peu de `when not ansible_check_mode`). Mais ça permet quand même - je trouve - de garder un parc homogène et de voir si des machines dérivent.
Dernière chose que je n'ai pas encore lue ici et donc je le signale. Pour le développement Ansible, je vois trop peu de gens s'aider de molecule, c'est dommage car quand on a passé la barrière (un peu ardue il faut dire), du setup de l'environnement, c'est redoutable.
Mes 2 centavos.
-
Arnaud Launay -
Faustin Lammler -
Gilles Mocellin -
gregoire-frnog＠greboca.com -
Jean-Yves LENHOF -
Jonathan Leroy -
Nicolas GIRARDI -
nicolas.frsag＠ecarnot.net -
Pascal Valois -
Pierre-Philipp Braun -
rkt231＠proton.me -
ronan.s＠lmon.io -
Xavier Beaudouin