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
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
