On 28/06/2012 09:36, JF Bustarret wrote:
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.
Si, il se passe toujours la même chose (et c'est déjà bien). Par exemple, verifier qu'il n'y a pas de nouveaux utilisateurs créés sur la machine et les supprimer le cas échéant. Corriger le contenu du fichier hosts ou des dns, pour reparer une erreur utilisateur possible qui aurait rendu la machine inutilisable sur le reseau. Il y a encore pleins d'autres exemples !
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.
Je suis d'accord avec ces points (et c'est principalement pour ca que j'utilise CFEngine)
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...
Il n'y a pas forcement de changement de config à faire, mais une correction ! Un exemple : - je veux avoir la dernière version d'apache2 installé (c'est un exemple un peu stupide). La règle est simple, et elle n'a pas besoin de changer, juste le repository avec les paquets apache2 - je veux être sur qu'apache2 tourne. La règle est simple : si il est arreté, l'agent le redemarre. Pareil, pas besoin de changer des règles ni d'action humaine
JFB Frustré par puppet, et n'ayant pas envie de se lancer dans chef/cfengine
C'est dommage, surtout qu'il existe des outils ou surcouches pour faciler les choses...
Nicolas