[AlternC-dev] Alternc 2.0 & Puppets : Howto ?

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

Benjamin Sonntag benjamin at alternc.org
Lun 7 Mai 09:18:49 CEST 2007


Salut,

The Anarcat a écrit :
> J'ai aussi commité une config plus simple, avec tout sur le même
> serveur. Du coup, j'ai complexifié au maximum la config "cluster", pour
> vous donner une idée.
>
> https://alternc.org/svn/alternd/trunk/doc/dev/simple_configuration.png
> https://alternc.org/svn/alternd/trunk/doc/dev/simple_configuration.dia
>
>   
Excellent, je ne m'attendais pas à ce que cela ressemble autant à mon
braindump d'hier ;)
> Ce qui est chouette avec l'utilisation de puppet, c'est qu'entre les
> deux configurations, il n'y a pas une grosse différence d'efforts pour
> le déploiement, c'est parfaitement "scalable", pour vu qu'on tient les
> choses bien en ordre...
>   
oui
> Si les choses ne sont pas bien comprises dans mes dessins affreux et ne
> respectant aucune forme de standard, faites-moi signe, car je crois que
> c'est une voie extrêmement intéressante à prendre.
>   
compris, et très intéressant.
> Notez bien que dans les deux configurations, le gros du travail va comme
> suit, pour ce qui est du codage d'AlternD:
>
>  1. codage d'un paquet de recettes pour puppet, afin qu'il sache comment
>  configurer postfix, bind, courier, vhosts apache, etc
>  2. codage d'une interface web pour la création de vhosts, qui va écrire
>  et gérer des recettes puppet (qui peuvent être stockées en LDAP, en
>  passant)
>   
je suis heureux de voir que tu n'as pas mis LDAP dans ton schéma ;) (à
mon avis trop compliqué à gérer pour le peu que cela apporte ...)
Notamment parce que puppet ne gère ldap que pour y stocker quelques
rares informations sur ses nodes, que l'on pourra tout aussi bien coller
dans quelques recettes de quelques lignes, et qui ne changent pas tout
les jours, y compris sur un cluster AlternC de 10 machines comme celui
de Lautre Net ...
http://reductivelabs.com/trac/puppet/wiki/LdapNodes


>  3. codage d'une interface web pour gérer les comptes usagers (comptes
>  pop, redirections, FTP, permissions, etc)
>
> Selon moi, chaque utilisateur créé devrait avoir un ACL lui donnant
> droit (ou non) à gérer certains domaines, à avoir un certain nombre de
> mails (quotas bonjour), FTP, etc, etc, mais tout centralisé dans le même
> usager au lieu d'avoir tout ça déconnecté.
>
> Ces comptes usagers ne sont pas stockés dans Puppet, mais dans une base
> de données externe, dont Puppet n'a pas grand chose à faire anyways.
>
> Pour les domaines, par contre, je ne suis pas certains. Selon moi,
> initialement, ils pourraient se tenir dans les recettes puppet. Ça
> serait plus facile à gérer, et ça serait plus transparent que d'avoir
> une copie dans une BD mysql. Anyways, à terme ces recettes peuvent se
> retrouver dans LDAP si on a besoin d'une config plus complexe (e.g.
> 1000+ domaines).
>   
Le problème de mettre cela dans des recettes puppet, c'est que ce sont
des fichiers texte. puppet étant destiné à être utilisé directement par
des admins-sys, on retrouve des fichiers texte visibles par un
admin-sys, et peu facilement décodables par un programme. Ce que l'on
peut faire tenir dans puppet, à mon avis, se sont les templates qui
génèreront les recettes à partir de la base de données. Sinon il faut
écrire un writer/parser de recettes ...
Par ailleurs, cela rend le code entre le bureau web et la base de
données des domaines beaucoup plus léger.

L'avantage de puppet est vraiment de disposer d'un outil qui va modifier
les config, s'assurer de la stabilité de ce point, et reloader les
services pour nous.

Après, pour la gestion des 1000+ domaines hébergés sur LautreNet, je ne
sais pas trop si les auteurs de puppet ont quelque chose en tête sur la
manière de procéder. Je pense que l'on devrait prendre le temps de les
contacter (irc leur semble habituel, je viens d'arriver sur leur chan
pour lurker un peu). En fait, je pensais à bind et à ses fichiers zones,
et me rend compte qu'avec myDNS, on a pas ce problème (il tape direct en
base les zones). J'en viens à me dire que ce type de problème sera du
ressort de chaque module d'altrnc pilotant un logiciel donné.

Par ailleurs, tous les cas que l'on évoque pour l'instant parlent soit
d'un AlternC monoserveur, soit de config multiserveurs typiquement en
HA/HP. Or, de mon côté, j'ai un cas plus retors : j'ai en fait une
vingtaine de serveurs sous AlternC, chacun avec sa base système, bref,
20 serveurs indépendants. Comment pourrais-je centraliser un peu la
config ? voir "gagner du temps d'admin sys grace a puppet" ?


Ensuite un détail : je ne vois pas puppetmaster piloter le DNS
secondaire, tout simplement parce que, par exemple,
secondary.heberge.info est secondaire pour une vingtaine de serveurs
AlternC, et qu'il me parait difficile de donner à 20 puppetmasters :)
l'accès à cette machine (... en fait ca n'est pas possible et pas fait
pour) d'autant qu'elle n'est pas gérée par les mêmes admins, ce qui me
parait assez habituel comme façon de procéder dans le monde du DNS. Je
vois plutot garder le système actuel (autoriser un serveur distant à
accéder à la liste des domaines hébergés, qu'il synchronise
régulièrement, et autoriser sur le serveur dns les axfr depuis des ips
habilités)
(c'est un détail, mais autant en tenir compte)

Enfin :

- que veux tu dire par : "(mails, FTP, etc, etc,) mais tout centralisé
dans le même usager au lieu d'avoir tout ça déconnecté."
parles-tu d'usager unix ? que veux-tu dire par "déconnecté" ?

- Si j'ai bien compris ton schéma, on n'a plus de démon AlternD, c'est
le httpd qui pilote les fichiers de puppetmaster, le même httpd qui sert
les pages web aux internautes ?
Je pensais que l'on voulait avoir un endroit déconnecté du httpd
habituel, qui serait par exemple un demon en python qui fournirait du
rest/xml-rpc, et serait chargé de tout cela ?
En gros, il serait le lien entre un bureau web tout léger sans droit
particulier, et les recettes puppet et las base de données système que
l'on ne voulait pas trop exposer.
Cela dit, dans ton schéma multiserveurs, le httpd de config (utilisé par
l'admin) n'est pas non plus le webnode. Je pense donc qu'il serait bon
d'expliciter cela.


> Voilà... Je crois que c'est très important de réfléchir comme il faut
> avant de d'asseoir et écrire du code (je considère des APIs comme du
> code). On est encore beaucoup à l'étape du design et de la réflexion, et
> si on saute cette étape, on est aussi bien de joindre une autre équipe
> de développement, car repartir à neuf, sans plan, ça nous amène nulle
> part.
>   
oui, réfléchissons.


@+

Benjamin Sonntag

Menu v2 : https://alternc.org/wiki/Version2.0
Logiciels : https://alternc.org/wiki/AlternCSpecsV2
Api : https://alternc.org/wiki/ApiV2
WebGui : https://alternc.org/wiki/InterfaceUtilisateur




Plus d'informations sur la liste de diffusion Dev