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.
Aller plus loin
- HAProxy (28 clics)
- Précédente dépêche DLFP sur HAProxy (13 clics)
- Use HAProxy 1.4 if you need MySQL health checks (9 clics)
- Annonce de la sortie de Chef 0.8.2 (10 clics)
- Le wiki officiel de Chef (13 clics)
- GNU Social (27 clics)
# Chef
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 2.
Mettre du REST pour du REST, cela me reste en travers de la gorge ;-)
[^] # Re: Chef
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: Chef
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Chef
Posté par Sylvain AVRIL (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 6.
Simplifier, simplifier, simplifier !
D'ici peu, on aura des setup.exe avec toutes les lib dedans ;-)
[^] # Re: Chef
Posté par taiwan . Évalué à 2.
[^] # Re: Chef
Posté par Sylvain AVRIL (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.