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 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, 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 / git / tunnels / scheduling / accelerations du bouzing 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 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 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 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_compatible_with/

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/