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