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

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 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

Le Sat, Sep 20, 2025 at 01:58:18PM +0700, Xavier Beaudouin via FRsAG a écrit:

Dernier redflag: dépend de python (ou mython) … donc voila end of story

Mython, c'est le pendant système de Metoo ?

Arnaud.

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.

Salute,

Moi j'ai une position assez spécifique sur ce sujet alors je dirais que l'outil ansible peu vraiment faire des miracles à condition d'avoir un niveau adapté autant dans la techno que l'on veut automatiser que dans l'outil et surtout spécifiquement dans cet outil : ses conseils (good practices) dans leur doc officielle qui sont ma foi très utiles au final pour des informaticiens motivés.

Après si vous voulez suivre la trend du moment et bien il faudra encore plus bosser en rajoutant des compétences de développement et se mettre à *pulumi https://www.pulumi.com/* ou bien terraform ou autre fork de ce dernier (https://opentofu.org/) pour compléter ce qu'ansible n'est pas censé gérer : les ressources !

A petit détail l'UI d'ansible : AWX je la déconseille pour la majorité des cas. Ca n'a pas de sens, autant qu'une UI pour un cloud au final... Mais là d'autant plus. Si vous avez du scheduling à faire il y a des projets bien plus stables qui ont fait leur preuve. Et à l'heure des workflows AI un peu de créativité serait la bienvenue.

Le soucis dans ces tech c'est que ça n'est pas magique il faut déjà avoir des compétences en réseau, en systèmes, en de nombreux services avec un recul sérieux, en cloud computing (et oui c'est différent), en toute autre tech que vous souhaitez aborder avec. Et en plus en IaC spécifique à par ex. ansible qui n'est en aucun cas un framework donc pas de cadre s'apparente à une foire sans rigueur et formation.

Par contre une fois que tout ça prend forme l'automatisation commence à prendre sens et là ça devient très pratique. Mais de prime abord ça n'est pas une techno facilement accessible contrairement à ce que l'on pense.

En tout cas pas si l'on souhaite écrire des rôles indempotents et de créer des tests avec *molecule* https://ansible.readthedocs.io/projects/molecule/philosophy/, gérer des virtualisations et des containers pour cela, et avoir une architecture versionnée qui sépare bien ses roles pour une maintenance facilitée.

Donc passez un bon bout de temps sur les inventaires et l'organisation des ressources c'est pas évident mais ça aide bien plus tard. Pour les mass features : *vault* https://infisical.com/docs/integrations/platforms/ansible / *git* https://docs.ansible.com/ansible/latest/cli/ansible-pull.html / *tunnels* https://www.jeffgeerling.com/blog/2022/using-ansible-playbook-ssh-bastion-jump-host / *scheduling* https://semaphoreui.com/ / *accelerations du bouzing* https://mitogen.networkgenomics.com/ansible_detailed.html et bien il faut souvent mettre la main à la pâte.

De toute façon ça n'est pas comme s'il y avait vraiment le choix. Et *galaxy* https://galaxy.ansible.com/ui/ en passant c'est bien mais c'est comme docker hub le but n'étant pas de piocher gratuitement dans le travail d'inconnus. Sinon ça se terminera en *bitnami* https://www.reddit.com/r/developpeurs/comments/1mvbb4x/pour_rappel_bitnami_broadcom_va_tout_casser_%C3%A0/ storie.

Bon chance, Guillaume Tristani

P.S. Nicolas, dans la modularité de l'outil et ce qui en fait sa force rien ne t'empêche de déposer du code python et de l'appeler inline dans tes tasks : https://docs.ansible.com/ansible/latest/plugins/filter.html ! C'est quasi transparent. Idem pour les inventaires dynamiques.

Le 09/10/2025 à 13:31, Nicolas Cuissard via FRsAG a écrit :

Le 18/09/2025 à 18:11, Jonathan Leroy via FRsAG a écrit :

...

• 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.

Salut,

Mes deux sous (avec un peu de retard) à propos de Ansible de la part de quelqu'un qui commence à s'y mettre en 2025 (sans avoir utilisé une autre solution avant).

Je suis impressionné par les limitations et les bugs. Il y a vraiment des choses élémentaires qui manquent et je ne comprends pas comment ça peut être utilisé à large échelle. Ce matin j'ai voulu faire un playbook pour réduire un volume logique LVM et je découvre que pour trouver sa taille, ansible_lvm.lvs est tout pété : https://github.com/ansible/ansible/issues/85632

Autre problème également : c'est « sans agent » mais complètement dépendant de la version de Python sur les hôtes donc les versions d'Ansible récentes ne peuvent pas gérer des versions d'OS un peu vieilles mais encore sous maintenance (exemple : RHEL 8) : https://www.reddit.com/r/ansible/comments/1d9pfhf/dnf_redhat8_rocky_8_not_co...

Et enfin pour moi le plus gros problème c'est les filtres Jinja pour traiter les données qui nous rappellent les heures les plus sombres du PowerShell et ses one-liners de 3 km de long. Tu veux trouver le prochain unitNumber dispo pour ajouter un disque à une VM VMware ? Pas de problème : unitNumber: "{{ diskOutput.guest_disk_facts.values() |selectattr('controller_key','equalto',(controllerKey | int))|map(attribute='unit_number')| list | sort | last |int +1 }}"

Moralité je l'utilise car ça fait une partie du boulot mais je vais continuer à lancer des scripts avec le module « command » pour utiliser des scripts Python ou Bash qui feront ça en quelques lignes plutôt que de faire des pages et des pages de playbooks en YAML pour faire des tests élémentaires. Je songe même à encoder certaines sorties et les envoyer à des scripts pour traitement plutôt que de le faire en Jinja.

Bon courage en tout cas !

-- Nicolas

---

Liste de diffusion du French Sysadmin Group https://www.frsag.org/