Le 2025-09-19T12:20:07.000+02:00, Jean-Yves LENHOF via FRsAG <[email protected]> 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
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
