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