Excerpts from Nicolas Charles's message of Thu Jun 28 12:02:31 +0200 2012: > > > >> 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
J'évite pour ma part d'utiliser puppet pour les exemples que tu cites. Il y a des outils plus adaptés qui existent pour cela. Je vois plutôt cela comme une sorte de cache: dans le cas de puppet, si la config réseau est cassée et que le client ne peut plus accéder au serveur pour récupérer sa config, il va appliquer la version locale de sa config, ce qui (avec un peu de chance) va corriger le problème réseau. Idem, si le master est en rade et que quelqu'un modifie une config importante à la main, puppet utilisera la version en cache pour remettre le système en ordre. À+, Marc _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
