On se tutoie ?

Aller au contenu | Aller au menu | Aller à la recherche

samedi, avril 4 2009

Migration de twitter vers identi.ca

Comme je l'ai twitter (je pense que le verbe associé restera) je suis entrain de basculer vers identi.ca.
identi.ca c'est tout plein de bonnes choses:

  • Basé sur l'application open source laconi.ca.
  • Décentralisé (possibilité de monter son petit serveur).
  • Ca gère openid.
  • On peut poster via xmpp depuis son compte jabber.
  • Permet d'exporter un fichier FOAF.

Bref, tout plein de formats ouverts.

Inconvénients:

  • <troll>C'est du PHP, mais personne n'est parfait.</troll>
  • Je ne sais pas comment va évoluer le service, j'imagine que la société controlyourself va sûrement se concentrer d'avantage sur son service de microblogging payant pour les entreprises status.net. Mais il y a toujours la possibilité de s'auto-héberger en installant laconi.ca.

Et puis le fait que google soit sur le point d'acheter twitter me motive aussi à changer, je n'ai aucune envie d'avoir toute ma vie chez eux.

jeudi, juillet 17 2008

Vertebra, un système intelligent de gestion de cloud, basé sur des standards

Les plateformes de type cloud computing (comme l'EC2 d'amazon) sont à la mode en ce moment, et d'après ezra, ça ne fait que commencer.

Je m'intéresse de plus en plus à ce type de solutions depuis que je travaille sur deescover, puisque le système a besoin de monter en charge.

Vertebra est donc un système de gestion de cloud computing (nuage de machines).
Il est vrai que le déploiement d'une application à forte charge, donc répartie entre plusieurs machines, peut vite s'avérer un casse tête, même avec des outils exceptionnels comme capistrano.

Vertebra se base sur XMPP afin de permettre aux différentes machines de communiquer entre elles.
XMPP, utilisé entre autre par jabber, est un standard qui peut être utilisé dans bien des situations.
L'idée de vertebra est de permettre à des machines (et plus seulement des personnes) de communiquer avec ce protocole.

Comme dans un système de messagerie, les machines disposent d'un statut, permettant de préciser leur état (disponible / indisponible / occupé).
Pour spécifier cet état un agent ruby tourne sur chacune des ressources du 'cloud'.
Il est important de spécifier que les agents tournent à deux niveaux :

  1. Au niveau node (noeud : groupe de machines) afin de connaître l'état des ressources du noeud.
  2. Au niveau slice (la resource ou machine) afin de lister les opérations disponibles.

Pour continuer dans les bonnes idées, le clud est Restful. Les opérations disponibles sont enregistrées au niveau de la ressource du cloud et sont accessibles au travers d'URL.
Sans ré-expliquer REST, le type d'opération dépend uniquement de l'URL et de la façon dont on y accède (GET : consultation, POST: création, PUT : modification, DELETE: suppression).

Chaque noeud dispose donc d'une API prête à l'emploi en fonction des opérations qu'il enregistre.
Ces opérations sont donc consultables à la demande par un simple message XMPP.

L'exploration des différents noeuds se fait de façon dynamique, par un système de broadcast des messages (basé sur XMPP donc).
En fonction des réponses il est possible de déterminer l'état des noeuds, mais aussi de choisir à qui adresser une opération (potentiellement le noeud qui répond le plus vite).
Ce système permet donc aussi de répartir la charge.

La présentation d'ezra montre bien que les jeux de questions - réponses ne sont pas limités.
Il est par exemple possible de déterminer l'état et la configuration des différentes machine du noeud depuis l'agent grâce à l'API.

Du côté des technologies utilisées on retrouve donc ruby, pour la partie agent, et erlang pour la partie serveur XMPP (ejabberd), mécanisme de découverte de services ...
Bref, que du bon.

Bien sûr on pourrait se poser la question de savoir comment sont gérées les autorisations entre les agents.
On n'imagine mal n'importe quel système envoyer un message XMPP à l'agent pour lui ordonner d'éxécuter une tâche.
Comme pour les systèmes de messagerie classiques, les agents sont en relation les uns avec les autres (un peu comme une liste de contact).
Pour 'se parler' chacun doit donc être dans la liste de l'autre.

La souplesse du système et de l'architecture choisie ouvre des tas de possibilités dont parle ezra : ne plus se limiter à de l'automatisation de tâches systèmes mais utiliser ce sytème en temps réel pour des applications web.

Ce principe est déjà possible grâce à fuzzed.
Écrit en Erlang, il permet de facilement créer un cluster et dispatcher les requêtes.
Ce système permet de monter en charge rapidement en ajoutant simplement des nodes au cluster.

Voilà, ça bouillonne pas mal en ce moment, et les grincheux qui crient sur tous les toits que rails ne monte pas en charge [1] et est complexe à déployer n'ont qu'à bien se tenir.

Notes

[1] Ce qui est idiot puisque ce n'est pas la technologie qui monte en charge mais l'architecture.

jeudi, mars 13 2008

Plugin highlight et pv pour weechat

Le besoin

Comme shingara, j'utilise weechat pour IRC et il nous manquait un plugin pour être notifié sur notre jabber à la réception d'un PV ou lors d'un highlight sur un channel.
Le but est de recevoir un message sur sa messagerie instantanée avec le nom de l'expéditeur et le contenu du message lorsque quelqu'un nous interpelle sur IRC.
Je me suis donc motivé pour écrire ce plugin in en me basant sur ses travaux en amont.

Qu'est ce qui change ?

Je suis donc parti de la révision 204 de son script (euh en fait y a d'autres choses dans le dépôt hein, vas faire un tour !) , basée sur celui de davux (c'est beau le libre hein ?), qui apparemment avait tendance à faire freezer weechat.

Au lieu d'utiliser xmpp4r j'utilise xmpp4r-simple qui est une lib plus légère et largement suffisante pour nos petits besoins.
Je pense avoir cerné ce qui potentiellement faisait planter weechat.
En effet lorsqu'on tente d'envoyer un message via XMPP, et que l'on ferme la connexion instantanément après, le message est non seulement perdu, et n'arrive donc jamais, mais a (semble t-il, je n'ai pas de certitudes) tendance à geler weechat.

Le script attend donc maintenant 3 secondes avant de fermer la connexion. D'une manière générale j'ai essayé d'améliorer la lisibilité et les perfs du script.
Au lieu d'instancier systématiquement un objet pour délivrer un message je passe par un singleton qui délivrera tous les messages pendant la durée de vie de weechat.

En terme de configuration il ne faut plus que le strict minimum : un couple jid / password qui désigne le compter jabber à utiliser pour envoyer les messages et un destinataire.
Il est possible de spécifier le port de connexion s'il est particulier, autrement le script utilise le port 5222.

Attention : Je n'ai pas testé mais il me semble logique qu'il ne faut pas utiliser le jid comme recipient, autrement le script risque de s'envoyer des messages à lui même.
En effet lorsque l'on utilise jabber c'est le dernier endroit depuis lequel on se connecte qui prend la main.

Au cas où ton compte destinataire ne serait pas connecté, les messages seront mis en file et tu les recevras à ta prochaine connexion.

Comment ça marche ?

L'usage est vraiment simple : il suffit de copier ce plugin dans ton .weechat/ruby/autoload et le plugin sera chargé au lancement de weechat. Ensuite tu édites ton fichier .weechat/plugins.rc et tu colles les informations te correspondant :

ruby.highlight_jabber_notify.jid = "jid@provider.tld"
ruby.highlight_jabber_notify.password = "toto42" # c'est pas ça ?
ruby.highlight_jabber_notify.port = "5222" # optionnel
ruby.highlight_jabber_notify.recipient = "recipient@provider.tld"

C'est tout. Le script est volontairement minimaliste mais on peut imaginer plus de configuration et de code pour n'être notifié que sur certains channels etc ...
J'ai aussi proposé ce script dans la section officielle du projet weechat (il est en attente d'approbation a été approuvé \o/).