Articles précédents : Petites brèves
- [3] Vidéos du FOSDEM, Blender 2.5 alpha 1 et diaporama HTML5
- [4] Éditorial sonore février 2010
- [7] Paquet de petites brèves d'hiver
- [17] Codec OpenSource BroadVoice
- [29] Firefox, Google, Samsung, X
- [1] fOSSa conférence sur le libre/open-source d'envergure
- [44] OOMouse, GRUB 1.97 & Moblin
- [4] Annonce en vidéo du forum PHP et conférences audio de Symfony 2009
- [5] CVC3, IntelliJ IDEA et Uruguay
- [8] Éditorial sonore octobre 2009
Liens connexes
- HAProxy (626 clics)
- Précédente dépêche DLFP sur HAProxy (167 clics)
- Use HAProxy 1.4 if you need MySQL health checks (203 clics)
- Annonce de la sortie de Chef 0.8.2 (202 clics)
- Le wiki officiel de Chef (233 clics)
- GNU Social (713 clics)
Dépêche modérée par
Dépêche éditée par
Petites brèves : HAProxy 1.4, Chef 0.8.2 et GNU Social
Posté par Bruno Michel (page perso, ). Modéré le 06 mars 2010.
HAProxy est une solution libre, fiable et très performante de répartition de charge, qui peut agir soit au niveau de la couche TCP, soit au niveau d'HTTP. La branche 1.4 apporte son lot de nouveautés, dont le très attendu support du keep-alive HTTP côté clients. On peut également citer la gestion du protocole RDP, l'interface en ligne de commande ou les health checks pour MySQL.
Chef 0.8.2
Chef est un outil en Ruby qui permet d'automatiser son infrastructure, sous licence Apache. Avec Chef, on peut :
- Gérer ses serveurs en écrivant du code, les recettes, et non pas en lançant des commandes
- S'intégrer à ses applications, bases de données, annuaires LDAP, etc.
- Configurer facilement ses applications qui ont besoin d'une connaissance de l'infrastructure (« Quel est le serveur de base de données maître ? »)
La version 0.8.2 est la première version stable de la nouvelle branche 0.8. L'API Rest de Chef est maintenant complète. Knife était un outil en ligne de commande proposé sous la forme d'une extension non-officielle. Il a été intégré à Chef, et il couvre maintenant l'ensemble des fonctionnalités proposés par l'interface REST. Un nouveau mécanisme d'authentification a été mis en place avec des signatures par requête. Et bien d'autres fonctionnalités ont fait leur apparition.
GNU Social
GNU Social est une initiative qui vise à créer un réseau social décentralisé. Un des objectifs est de permettre aux utilisateurs d'avoir un meilleur contrôle sur les données et leur vie privée que ce que les réseaux sociaux actuels permettent. L'intégralité du code sera placé sous licence AGPLv3, mais pour le moment l'heure est plus à la discussion pour essayer de regrouper les idées sous un concept fort.
![[en]](../../../images/en.png)
HAProxy (626 clics)![[fr]](../../../images/fr.png)
Précédente dépêche DLFP sur HAProxy (167 clics)-
Use HAProxy 1.4 if you need MySQL health checks (203 clics)
-
Annonce de la sortie de Chef 0.8.2 (202 clics)
-
Le wiki officiel de Chef (233 clics)
-
GNU Social (713 clics)
> Lire les commentaires (15 commentaires, moyenne: 2,3).
Chef
J'ai rien compris chef !
Je suis allé sur le site de Chef et je dois dire que j'ai rien compris à ta nouvelle ni au site. Je ne dois pas être en forme !
C'est quoi l'objectif : de faire de la configuration automatique de poste comme CFengine et Puppet ?
Je ne vois pas ce que veux dire automatiser son infrastructure ici, ni ce que c'est qu'un recette. Sur leur site, il y a du Cookbook ici et la mais pas un exemple clair pour moi.
Bref, je trouve le chef nébuleux...
-
[^]Re: Chef
Posté par Bruno Michel (page perso, ) le 07/03/2010 à 18:09. (lien). Évalué à 2.> C'est quoi l'objectif : de faire de la configuration automatique de poste comme CFengine et Puppet ?
Oui. Après, je ne suis pas un utilisateur de Chef, donc je ne saurais pas te dire en quoi Chef est mieux.
> Sur leur site, il y a du Cookbook ici et la mais pas un exemple clair pour moi.
Peut-être que la recette pour HAProxy te parlera : http://github.com/opscode/cookbooks/blob/master/haproxy/reci(...)-
[^]Re: Chef
Posté par Sytoka Modon (page perso, ) le 07/03/2010 à 21:36. (lien). Évalué à 2.Et en pratique, par rapport à cfengine ou puppet (qui est aussi en ruby), c'est quoi le plus ?
Je viens de regarder l'API REST et Knife et je me demande à quoi cela sers vraiment en pratique ? Avec cfengine, toute ma configuration est versionnée et propagée de machine en machine via cfserv. J'ai absolument pas besoin d'interagir avec la couche client serveur, c'est complètement transparent. D'ailleurs, mes règles cfengine sont toujours en deux temps : -1- Copie locale des fichiers cfengine, -2- application locale des règles. Ainsi, même en cas de réseau planté ou même si mes machines se baladent à l'autre bout du monde, cfengine applique toujours la dernière politique sur laquelle il s'est synchronisé.
Bref, je vois pas bien a quoi sers cette API REST dans la vie de tous les jours ici.-
[^]Re: Chef
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 08/03/2010 à 17:30. (lien). Évalué à 1.REST, Representational State Transfer, est une architecture souvent comparée aux protocoles SOAP et XML-RPC car elle peut utiliser également XML pour le format de ses échanges, tout comme HTML ou JSON.
S'appuyant sur les requêtes du protocole HTTP pour déterminer les types d'opérations, REST est assez léger et permet de développer des applications néanmoins complètes.
L'une des plus célèbres est Request Tracker, le gestionnaire de suivi d'incidents par tickets écrit en Perl et s'appuyant totalement sur une architecture REST pour fonctionner.-
[^]Re: Chef
Posté par Sytoka Modon (page perso, ) le 08/03/2010 à 17:52. (lien). Évalué à 2.Je sais ce que c'est que REST (j'utilise RT par ailleurs), ce que je ne comprends pas au premier abord, c'est le plus de REST dans chef et surtout ce que cela apporte par rapport à cfengine ou par rapport à puppet.
Mettre du REST pour du REST, cela me reste en travers de la gorge ;-)-
[^]Re: Chef
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 09/03/2010 à 18:06. (lien). Évalué à 2.Par rapport à Cfengine2, le fait que le protocole de transport soit HTTP peut aider à traverser certains proxys et pare-feux récalcitrants.
Par rapport à Puppet, il me semble que celui-ci peut également passer par HTTP.
Sinon, cela offre sans doute une API facilement utilisable par des outils tiers.
-
-
-
[^]Re: Chef
Posté par Octplane (page perso, ) le 08/03/2010 à 18:34. (lien). Évalué à 1.Un des avantages de Chef par rapport à Puppet, c'est que les recettes sont écrites en Ruby et pas en Puppet.
Puppet a quand même l'ignoble défaut d'avoir son propre langage à lui qui marche un peu quand il veut avec sa syntaxe parfois juste horrible à saisir. Ca marche bien quand ça marche mais pas tout le temps (passer 3 heures à débugguer une recette pour s'apercevoir que le , qu'on avait mis en trop est resté en cache quelque part, c'est rageant)...
De plus, Chef permet à chaque machine de connaître le reste des machines configurées de manière automatique: Ca peut par exemple permettre à un load balancer (comme HAProxy, tiens) d'intégrer automatiquement toutes les instances vers lesquelles il balance et ce de manière automatique...-
[^]Re: Chef
Posté par Sytoka Modon (page perso, ) le 08/03/2010 à 18:55. (lien). Évalué à 2.J'avoue ne pas utiliser Puppet mais cfengine. Je ne savais pas qu'il y a avait des problèmes de syntaxe avec Puppet. Merci.
Sinon, c'est pas un peu dangereux qu'une machine puisse tout savoir sur les autres dans l'absolue ?
J'avais un peu l'espoir de faire le genre de chose que tu dis avec cfengine au début. Mais, je me suis retrouvé rapidement avec un serpent qui se mord la queue. En gros, soit tu installes un paquet qui indique que le serveur doit être dans un << cluster >> soit tu indiques que la machine est dans le << cluster >> et alors cela installe dessus un certain nombre de paquet.
Bref, avec cfengine, tu peux facilement remonter un fichier sur le serveur et celui-ci peut alors redescendre des fichiers ou autre... C'est vrai que ce n'est pas des "events" temps réels mais je me méfie un peu de l'aspect trop temps réel pour des outils à ce niveau la.
A trop vouloir en faire, cela peut devenir dangereux et surtout j'ai pas trop envie que le fonctionnement temps réel de mes serveurs dépendent trop d'un outil tiers en plein développement. Cela me semble peu intégrable sur le temps.
Du coup, par exemple, cfengine me dépose des fichiers pour cron mais ne fait pas le boulot de cron. Idem pour monit...
Bref, à voir et à suivre dans la durée.
Je suis plus au final dans la mouvance d'avoir un outil simple comme Slaughter de Steve Kemp.
http://www.steve.org.uk/Software/slaughter/-
[^]Re: Chef
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 09/03/2010 à 18:11. (lien). Évalué à 2.Quelle version de Cfengine utilises-tu ?
-
[^]Re: Chef
Posté par Sytoka Modon (page perso, ) le 09/03/2010 à 23:11. (lien). Évalué à 2.2.2.8 qui est par défaut dans debian
-
-
-
[^]Re: Chef
Posté par Sylvain AVRIL (page perso, ) le 12/03/2010 à 14:37. (lien). Évalué à 2.Pour moi l'avantage de Puppet, c'est qu'il n'utilise pas Ruby. :-)
Je n'ai pas envie d'apprendre un langage ainsi que l'ensemble des bibliothèques associées avant de pouvoir déployer un truc.
Et c'est bien là que réside la différence de philosophie entre les 2 outils.
Avec Chef, tu développe des scripts.
Avec Puppet tu décris l'archi que tu veut déployer (il utilise un langage déclaratif).
Pour configurer un cluster, tu peut utiliser les exported ressources. Dans mon cas, je l'utilise pour que chaque base de données déployée modifie automatiquement la config de mon serveur bacula pour y inclure le backup de ces BD.
Puppet apporte son propre langage et son propre mode d'exécution et c'est comme avec l'apprentissage de chaque nouveau langage, au début on galère, après tout vient bien plus vite, j'en conviens.
Mais pour moi, utiliser Chef n'aurait pas été plus facile (peut être plus, ruby est plus riche que puppet). Après il m'a quand même fallu apprendre ruby lorsque j'ai voulu étendre les possibilitées de puppet (même si on peut faire déjà pas mal de chose, écrire des types personnalisés est plus propre dans certains cas).
En tout cas, je reste convaincu de l'intérêt d'avoir un langage déclaratif pour décrire un déploiement. Quand tu lis du puppet, tu sais ce qui est installé. Quand tu lis du Chef, tu est obligé d'imaginer chaque étape pour comprendre le résultat final.
Autre élément intéressant quand le déploiement plante au milieu, puppet est capable de reprendre là où il s'était arrêté. Avec un script...
-
-
-
-
[^]Re: Chef
Posté par Kerro () le 07/03/2010 à 20:07. (lien). Évalué à 2.Les développeurs de Chef doivent se prendre pour des as car ils ont intégré leur propre serveur web (tout comme l'ignoble Puppet d'ailleurs).
C'est quoi cette mode ? Les performances sont pourrites, il faut lancer plusieurs instances (et utiliser un logiciel d'équilibrage) sinon les clients doivent faire la queue. Bravo :-(-
[^]Re: Chef
Posté par Sytoka Modon (page perso, ) le 07/03/2010 à 20:13. (lien). Évalué à 6.C'est pour simplifier.
Simplifier, simplifier, simplifier !
D'ici peu, on aura des setup.exe avec toutes les lib dedans ;-)
-
[^]Re: Chef
-
[^]Re: Chef
Posté par Sylvain AVRIL (page perso, ) le 12/03/2010 à 14:24. (lien). Évalué à 3.Puppet n'a pas son propre serveur web. Il utilise le standard ruby Webrick (qui est plutôt nul j'en conviens). Tu peut utiliser passenger ou mongrel pour monter en charge.
-
Cette page a été générée par Templeet en 0.1063s (dont 0.0105 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.