[AlternC-dev] AlternD-puppet?

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

The Anarcat anarcat at anarcat.ath.cx
Lun 29 Jan 01:33:56 CET 2007


On Sat, Jan 27, 2007 at 03:44:27AM +0100, Benjamin Sonntag wrote:
> Je viens d'aller voir bcfg2, il semble nettement moins "réfléchi" que
> puppet, qui est parti d'une introspection du problème de la gestion de
> conf beaucoup plus profonde (il vient d'un type qui était déçu de
> fonctions et paradigmes manquants dans cfengine)

Cool! Content de voir d'autres gens tester l'idee...

> J'ai testé puppet, c'est en effet assez jeune, mais marche bien, cela
> dit, il m'a fallu un temps certain (pour ne pas dire un certain temps)
> pour réussir à lui faire faire ce que je voulais : créer un fic de conf
> bind, le modifier proprement, et reloader ce dernier. C'est très
> puissant cela dit ...

Moi ça m'a pris un certain temps à réussir à partir le serveur et avoir
un client qui lui parle, alors t'imagine modifier des fichiers de conf.
:P

Ça serait bon qu'on mette nos expériences avec puppet sur leur wiki ou
sur le notre, c'est du travail qui pourra être récupéré... 

https://reductivelabs.com/trac/puppet/tags/puppet%2Crecipe

> Je milite très clairement pour l'adoption d'un système "à la puppet"
> (genre puppet ou cfengine)

Youpi!

> Birdy, tu nous avais parlé d'un système de déploiement full-automatic ?
> C'était quoi déjà (même si cela risque d'être fort différent, ton
> système mérite surement d'être, lui aussi, exploré)

Bien que je crois que le mérite d'approcher alternc v2 sous l'angle du
problème général de la configuration de système revient à birdy, je
crois que cedont tu parles est le FAI (Fully Automated Installs):

http://www.informatik.uni-koeln.de/fai/

On Sat, Jan 27, 2007 at 07:47:00AM +0100, Benjamin Sonntag wrote:
> Re.
> 
> Je re-réfléchissais à tout cela, et me dit qu'il y a tout de même 2
> types de modifications de conf :
> 
> - l'initialisation de la conf d'un service donné, son tunning ultérieur,
> les modifs de l'admin-sys pour répondre à une attente ponctuelle d'un côté
>     > Typiquement déployables et maintenables avec puppet

Clairement.

> - les meta-données insérées en conf (virtual host, zone bind etc.) qui
> sont modifiables par les utilisateurs via le bureau web, et bougent souvent.
>     > Je ne sais pas (pas d'avis tranché pour l'instant) si c'est le
> rôle de puppet que de gérer ces fic de conf là  ?

Idéalement, oui, bien que Puppet n'est conçu pour ce niveau, je crois,
et c'est là le gros du défi selon moi.

Sans ça, puppet perd un peu de son intérêt car nous nous débrouillons
quand même bien à l'installation avec le package debian... Le problème
qu'il faut résoudre de façon plus élégante n'est pas à l'installation,
mais à la gestion long terme.

Utiliser puppet pour ceci permetterait par exemple d'ajouter
dynamiquement des serveurs beaucoup plus facilement et décentraliser
complètement la gestions des services. Un serveur dédié pour bind, par
exemple, devient facile à déployer, pour vu qu'on installe puppetd (le
client puppet) dessus.

> Cette question me parait importante, car puppet parait tout de même
> difficile à interopérer sur le second type de modifs, mais peut-être me
> trompe-je ...

Je crois que tu ne te trompes-je pas... C'est la toute la difficulté.
Peut-être, comme Lunar le mentionait, il serait possible d'avoir du
storage MySQL pour les "manifestes" (qui déclarent les fonctions et
configurations des serveurs). Si je me souviens bien, il y en a un en
LDAP... 

> Bref, une question se pose : jusqu'à quel niveau faut-il utiliser un
> outil de maintenance de conf ?

"All the way", selon moi, quoique certaines configurations (e.g. les
"comptes de courriels") peuvent être gérés directement (?) par le
"frontend web" sans passer par puppet, peut-être qu'il serait préférable
que tout passe par puppet, malgré cette possibilité, pour (1)
centraliser la configuration et (2) donner une API uniforme aux divers
"clients" (frontends) potentiels...

> Puppet présentant l'avantage d'être transactionnel, on a une robustesse
> plus grande, je serais alors pour une utilisation aussi profonde que
> possible d'un tel outil, mais dans le cadre de vhosts par exemple,
> est-ce vraiment pertinent ?

Je dirais que oui, en particulier si on veut commencer à s'écarter de
mod_vhost_alias (ce que je propose dans la v2). Il faut alors gérer un
fichier de conf par sous-domaine, un cauchemar dans notre scénario
actuel (en particulier avec des installations multi-serveurs comme
globenet ou l'autre), mais beaucoup plus faciles avec Puppet...

> des avis ?

voilà. :)

A.

PS: en passant, j'ai visité l'autre soit #puppet sur freenode pour
discuter un peu avec les gens de puppet, ils ont l'air sympa, et
à première vue, il semble y avoir un intérêt pour la collaboration.
Peut-être pourrions-nous aussi proposer notre projet sur leurs listes de
discussion pour amener d'autes commentaires...
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 189 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20070128/71ae0be5/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev