Je réponds pour la partie Puppet, que j'ai pas mal utilisé en prod il y a un an.
Je ne réagirai pas sur l'argument "ansible n'est pas un outil de gestion de conf", ce qui pourrait aiguiller le thread vers du troll alors qu'on n'est pas vendredi, d'autant que sur le fond, je suis assez d'accord : ansible ne répond pas au même besoin.
Le 28 juin 2012 à 09:01, Nicolas Charles a écrit :
Par contre, gérer à distance, c'est impossible quand la machine n'est plus accessible (par exemple une attaque qui coupe le reseau entre le serveur Ansible et la machine cible), c'est pas très scalable, et si le serveur qui gère est mort, tout s'arrête (enfin, rien de peut être changé manuellement)
Le problème se pose à chaque fois il y a un repository central avec toute la conf... Si le repository n'est pas accessible il ne se passe plus grand chose.
Côté scalabilité, Puppet n'est pas non plus idéal : avec pas mal de machines et une grosse config, une install "out-of-the-box" dont le client tourne automatiquement et régulièrement part facilement à l'ouest et ça demande un peu de boulot pour lui faire tenir la charge (NB : ça a pu changer dans les dernières versions). Le client a aussi un bel impact sur la machine sur lequel is se trouve.
J'en connais plusieurs qui lancent le client puppet en SSH lors d'un changement de config, avec un fonctionnement qui se rapproche finalement d'ansible.
Les outils CFEngine/Chef/Puppet ont une version locale des promesses/recettes/manifests qui les rend résilient à une panne réseau; et c'est en fonction de ces règles qu'ils décideront d'aller parler à un serveur ou non (avec peut être plusieurs serveurs différents), et avec ca on peut commencer à être scalable.
Je ne vois pas l'intérêt : si le client a la config en local, c'est que logiquement elle est déjà appliquée. Si le client n'a pas accès au serveur, il ne peut plus appliquer les changements de config ou initier une nouvelle config dans le cas d'un déploiement...
JFB Frustré par puppet, et n'ayant pas envie de se lancer dans chef/cfengine