Intro

Lorsqu’on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C’est simple à faire sous Linux avec rsyslog, avec lequel je transmets les syslogs vers l’excellent Graylog2. Par contre dans le monde Windows il n’y a pas de serveur syslog natif. J’avais donc trouvé MonitorWare Agent un impressionnant logiciel propriétaire qui permet de définir des services qui vont lire n’importe quel type de logs, puis associer à ces services des ruleset qui vont déclencher une action comme faire suivre les logs vers un serveur syslog. L’interface graphique permet de créer un nombre de services et de rulesets impressionnants pour enchaîner des actions les plus tordus.
Le seul problème est le coût de la licence à environ 200€ par serveur, ce qui peut être bloquant.

NXLOG

Prêt à laisser tomber, mon collègue et voisin de bureau @ponteilla m’a judicieusement déniché le logiciel libre nxlog qui permet de faire exactement la même chose, sans interface graphique mais ça nous fait pas peur. Après de nombreux tâtonnement et quelques mails sur la liste j’ai pu transmettre les logs d’une application qui rotate elle meme ses logs en donnant un nouveau nom au log en cours (gruik)… Cependant nxlog permet d’utiliser des wildcard sur les noms des fichiers (*.log par ex) et même d’être récursif en allant lire tous les logs dans chaque sous répertoire. Un processor transformer permet de formater le log selon la RFC syslog voulue.
La doc montre le workflow très poussé de nxlog qui permet des enchaînements vraiment tordu, genre intégrer un schéduler dans un module input, surveiller un fichier de log et le convertir en CVS vers un autre fichier xm_csv_example. Il intègre également un langage qui permet par exemple de tester une expression régulière sur un flux en entrée :

if $Message =~ /^Test (\S+)/ log_info("captured: " + $1); 

Workflow

En entrée on choisi un input module (fichier, sgbd, syslog, tcp/udp, ..), puis un processor module qui va transformer ou filtrer les datas, puis un output module (sgbd, syslog, tcp/udp, file, ..) enfin via la directive route on enchaîne ces modules entre eux. Je n’ai que survolé les possibilités du soft, mais au vu de sa richesse et de sa licence GPL/LGPL je suis plutôt surpris de ne pas le trouver dans les dépôts debian/ubuntu.

Config basique fichiers de logs (*.log) -> serveur Graylog2 Linux (syslog)

Voici ma config qui fonctionne. Le serveur Windows communique avec Graylog2 sous Linux via OpenVPN. Pour aider au paramétrage j’ai lancé sur le Linux un tcpdump pour vérifier que les paquets arrivaient bien, avec la facility voulue :

tcpdump -i tap0 "udp port 514" 

Le fichier de conf nxlog.conf

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html
## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.
define ROOT C:\Program Files\nxlog
# define ROOT C:\Program Files (x86)\nxlog
define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO
<Extension syslog>
 Module xm_syslog
</Extension>
<Input in>
 Module im_file
 File "C:\monapp\log\\*.log" # lit tous les .log dans tous les sous répertoires !
 Exec $Message = $raw_event;
 SavePos TRUE
 Recursive TRUE
</Input>
<Processor transformer>
 Module pm_transformer
 Exec $SyslogFacilityValue = syslog_facility_value("local2");
 OutputFormat syslog_rfc3164
</Processor>
<Output out>
 Module om_udp
 Host 10.8.0.1 # IP du serveur Linux sur lequel écoute graylog2 server
   Port 514
</Output>
<Route 1>
Path in => transformer => out
</Route> 

Je viens de tomber sur APPLE, LA TYRANNIE DU COOL qui contient cette phrase :

Tim Wu, qui compare le succès de Steve Jobs à celui d’Hollywood, en soulignant que l’humanité préfère en général « la facilité et le confort » à la liberté

Je vais tenter de décortiquer cette phrase qui me parait très lumineuse, et possède plusieurs niveaux de profondeur pour nous Linuxiens.

En effet si nous sommes tous d’accord ici pour dénoncer la perte de nos libertés fondamentales lorsqu’on utilise un produit Apple, il en est pas de même pour reconnaître la faiblesse du logiciel libre qui ne le rend pas assez attrayant face aux produits Apple/Google. Pour certains le client Apple est idiot, pour d’autres il est bling bling, pour d’autres il est anti-microsoft primaire ou bien il peut être tout ça.

Cette histoire de confort me rappelle une histoire, vraie il me semble, sur un test de scientifiques effectué sur des chimpanzés. Ils fournissaient 2 moyens à ceux-ci pour obtenir des bananes. Un très complexe à base de cordes et de poulies et un autre très simple qui permet de prendre les bananes en tendant le bras à travers des barreaux légèrement électrifié. Il s’est avéré que le stress généré par la peur du courant électrique était moins important que celui généré via le système de poulies pourtant sans douleur.

Rapporté à l’être humain, cette histoire tend à démontrer qu’il préférerait le moyen le plus simple pour effectuer des tâches courantes, quelque soit les inconvénients. Donc même si ces tâches sont effectuées via des logiciels libres offrant plus de libertés, elles seront la plupart du temps plus stressante qu’un logiciel ou surtout qu’un écosystème propriétaire comme Apple ou Google plus agréable.

Si l’on admet cette réalité, d’autant plus pour des personnes dont l’informatique n’est qu’un outil qui ne les occupent qu’une infime partie de leur temps par rapport à nous, on ne devrait plus perdre du temps à pratiquer le dénigrement ou le mépris envers ces personnes, mais comment rendre les logiciels libres plus agréable.

Le cloud

C’est un système très justement dénoncé par le risque de perte de la vie privée contenue dans nos données. Il est pourtant le pilier des écosystèmes d’Apple, de Google, et prochainement de Microsoft. Cet outil permet et permettra encore plus de simplifier la synchronisation des données personnelles, des applications et des personnalisations.
Il est l’outil indispensable à l’amélioration du confort de l’utilisateur, et pourtant nous ne faisons que le dénigrer voir dénoncer la dangerosité d’un tel système en le baptisant par certains Minitel 2.0

Certains travaillent à concevoir des logiciels libres alternatifs aux outils propriétaires les plus connus basés sur le cloud, comme movim ou diaspora. D’autres comme la FSFFrance ou tuxfamily proposent d’héberger des logiciels libres. Même si ces 2 types d’initiative pourraient conjointement arriver à un début d’alternative, encore faudrait-il une équipe de techniciens pour maintenir et faire évoluer l’infrastructure. Or nous l’avons vu avec l’APINC et Tuxfamily, ce type de service basé sur le bénévolat est par définition non pérenne.

L’autre solution est l’auto-hébergement, ce qui revient à renvoyer à l’utilisateur la prise en charge des services et donc la complexité de celle-ci. Il va s’en dire que ce n’est pas une solution pour le grand public.

Solutions

Des solutions sont à mon avis nécessaire si l’on veut que le grand public ne doivent pas choisir entre son confort et sa liberté. Pourquoi l’utilisation du logiciel libre devrait nécessairement passer par une complexité ou une compréhension de l’informatique ?
Cette question est d’autant plus critique maintenant car jusqu’à il y a quelques années l’usage d’un logiciel libre comme un navigateur web ou une suite bureautique n’impliquait pas un grand effort face à la version propriétaire, hormis bien sûr celui de changer ses habitudes. Cependant avec l’intégration de plus en plus fortes de services au sein des logiciels, la différence entre logiciel propriétaire et logiciel libre est de plus en plus flagrante et ne sera pas en faveur de ces derniers.

Une solution serait qu’une Fondation du libre possédant une certaine reconnaissance de ses pairs proposent des services. En effet le dilemme du cloud est qu’il suffit qu’une entreprise exploite de données personnelles pour que cela suffise à jeter le doute sur la vie privée, que cela soit Google ou Canonical. A priori seul une Fondation ayant en son coeur une éthique, comme la FSF ou la Mozilla Fondation pourraient obtenir la légitimité de l’exploitation de données personnelles.

L’autre solution qui est une sorte de Graal, serait de concilier le P2P et les services. Il “suffirait” que des services, quel qu’ils soient, s’appuient sur une API système, laquelle fonctionnerait en P2P pour distribuer les données découpées, chiffrées et redondées. J’ai cependant bien peur qu’un tel système ne voit pas le jour avant très longtemps.

C’est pourtant à mon avis le prochain défi du logiciel libre, ne plus se contenter de proposer du logiciel, mais aussi des services si possible décentralisés et si possible non gratuit.

La gratuité

La liberté a un coût, la preuve en est que certains s’en prive en échange de confort et de simplicité. Il est à mon avis dommageable à long terme pour le libre que ce coût soit sur celui du confort d’utilisation. Le succès d’Apple montre qu’un grand nombre de personnes sont prêtes à payer très cher en monnaies, leur confort. Un autre grand nombre de personnes sont prêtes à obtenir ce confort en échange de leur vie privée, chez Facebook ou Google.
Dans les 3 cités, Apple, Facebook, Google, aucun n’a fait l’économie du confort.

Il est donc à mon avis nécessaire de diminuer fortement l’effort nécessaire à utiliser et exploiter les logiciels libres, l’usage de services liés sera pour cela de plus en plus indispensable. Une grande partie des utilisateurs seraient prêt à payer pour ces services ce qui permettrait d’une part de financer leur développement et exploitation, mais aussi que les communautés libres qui développent et supportent ces services puisse s’auto financer.

Quand je vois la part de plus en plus grande que prend l’informatique connecté à des services en ligne sur des formes aussi variées que des véhicules, des télévisions, console de jeux, téléphone, frigo, maison, etc, et que le libre ne propose aucune alternative à cela hormis dire que c’est pas bien, je suis très inquiet, certes pas à titre personnel mais pour l’avenir de tous.

Il sera je pense de plus en plus nécessaire de penser au confort, au financement et donc arriver à créer un écosystème décentralisé libre auto-financé et en terminer avec les tabous des services et de l’argent.

Comme chaque année j’ai fait un tour aux JDLL le vendredi et le samedi. Il y a eu des conférences très intéressantes, notamment celle d’ Alexandre de dommelin sur puppet. J’ai déjà eu envie d’utiliser cet outil de gestion automatique des déploiements et des configurations, mais son enthousiasme m’a convaincu d’utiliser cet outil indispensable à l’industrialisation d’un SI (traçabilité, déploiement automatique, etc).

J’ai ensuite suivi les conférences sur movim et salut à toi qui sont des réseaux sociaux décentralisés basés sur XMPP. On voit qu’il y a eu beaucoup de taff derrière ces projets, et qu’ils mériteraient d’être financé. Au sujet du financement j’ai rencontré les petits gars derrière elveos qui permet de financer les développements de logiciels libre. C’est typiquement ce genre d’outil qui manque à notre écosystème depuis longtemps. Mais à mon sens ils devraient ajouter une gestion des ressources humaines en plus des ressources financières. En effet l’énorme difficulté des développeurs de logiciel libre, outre le financement, est de trouver d’autres développeurs, administrateur, graphiste, etc.

J’ai ensuite assisté à la conférence de Benjamin Bayard. Il a vraiment des talents d’orateur et de vulgarisation. Sur les problématiques aussi fondamentales telles que la neutralité des réseaux, nous mériterions qu’il touche un plus grand public plutôt que celui des geeks déjà acquis à cette cause.

Pour finir j’ai été plutôt impressionné par une démonstration d’opensuse sur le stand éponyme. L’outil OBS semble à première vue extraordinaire pour générer des paquets vers différentes distributions Linux. Mon netbook va sans doute servir de cobaye.

Peut être que l’année prochaine j’aurais assez avancé sur nodecast pour faire une petite conférence, et ainsi éviter de saouler toutes les personnes qui font l’erreur de me demander quel est mon projet

Quoi qu’il en soit, il me parait évident que l’avenir des prochains services libres s’annoncent décentralisé et basé sur XMPP. C’est à mon sens la meilleur voie si l’ont veut éviter l’hémorragie des utilisateurs vers des services propriétaires centralisés et ce que cela implique en terme de protection de la vie privée. Car il ne sert à rien d’utiliser des logiciels libres sur son poste de travail si les données sont stockées chez Apple, Google, Facebook, Yahoo, …

Dans la lancée j’ai également intégré un serveur XMPP grâce à QXmpp  ce qui permet au client Geekast d’effectuer des push en XMPP. Il fonctionne également dans son propre thread. Outre la rapidité de ce protocole face à HTTP, cela va permettre aux clients Geekast d’avoir une socket persistante avec le serveur ncs et donc permettre à celui-ci de faire du push vers tous les clients connectés. Les usages restent à définir mais cette possibilité ouvre un grand nombre de portes. Par exemple proposer la possibilité d’agir sur tous ses clients geekast depuis l’interface web (kill de processus, etc). L’envoi par HTTP sera toujours présent dans le client, au cas où la connexion XMPP est impossible (firewall, etc).

L’autre avancée est sur le format de donnée entre le client et le serveur, qui migre du XML vers JSON via QxtJson. Ainsi le serveur ncs qui reçoit les payload en json peut directement les transformer en bson object, format binaire de MongoDB. Plus besoin de passer par un lourd parsing du xml et des conversions vers des tableaux pour en extraire les données. La ligne suivante montre la simplicité d’une telle conversion :

bson::bo m_bo_json = mongo::fromjson(json.toStdString());

Le serveur ncs est donc maintenant autonome, Ruby est uniquement utilisé pour l’exécution du frontal web en Ruby on Rails.

Pour finir, voici un schéma du fonctionnement interne du serveur ncs.

En effet dans mon dernier article je me sers d’un logiciel propriétaire pour présenter ce que je crois être l’avenir de services sur Internet via des technologies en Peer to Peer. Dans cette architecture P2P je pense que l’auto-hébergement est alors crédible car les données sont répliquées et leur accès répartie.

C’est pourquoi j’ai à nouveau réécris le backend, car dans un contexte où chaque utilisateur est encouragé à s’auto-héberger, il est nécessaire que le logiciel soit léger, simple à packager et donc avoir le moins de dépendance possible. Lorsque j’ai découvert Zeromq j’ai décidé d’implémenter avec, la gestion de la file d’attente et de répartition des jobs pour remplacer le serveur Qpid. Tous les serveurs de file comme Qpid, RabbitMQ ou Redis sont excellent dans un environnement centralisé mais sont à mon avis une contrainte s’ils sont imposés dans un environnement décentralisé ou réparti.

Zeromq me permet de migrer dans le dispatcher la gestion des files, grâce à des sockets ZMQ de type PUSH/PULL gérées dans des threads. L’usage de Zeromq est in fine plus complexe puisque plus bas niveau qu’une API fourni avec un serveur de file, mais les possibilités sont quasiment infinie, voir les différents exemples dans de nombreux langages et surtout les nombreuses spécifications de protocoles. A noter que Zeromq ne permet pas de persistance disque comme le font Qpid ou RabbitMQ, cependant une implémentation du protocole Titanic le permettrait, et il n’est sans doute pas sorcier de les ajouter en option.

A propos de la persistance des messages, tout dépend du type d’application gérée, pour un système bancaire il ne peut y avoir de perte de message bien entendu. Au contraire, il me semble avoir lu que les dev du  backend de last.fm avaient choisi une technologie sans persistance pour privilégier la performance.

Schémas

Voici le schéma de la nouvelle architecture et du dispatcher

Description

Ce schéma décrit le fonctionnement interne du processus dispatcher. Les numéros en rouge indiquent le workflow suivi par un job. Même s’il n’y a plus de serveur de file dans l’architecture nodecast, le dispatcher permet d’en conserver les propriétés grâce d’une part aux threads et aux envois non bloquant :  la directive ZMQ::NOBLOCK indique à la socket zmq de ne pas attendre de confirmation du destinataire.

1. L’API géré par Thin (externe au processus dispatcher) réceptionne les données XML envoyées par les clients nodecast. Le serveur Thin a bindé le port 5555 local, stocke le XML dans GridFS, construit un hash et le push dans la socket ZMQ_PUSH.
2. Le thread Zreceive est connecté sur le port 5555 via une socket ZMQ:PULL. Avec ce protocole il peut y avoir plusieurs instance du dispatcher connectés, mais un seul recevra un même job. A contrario en ZMQ PUB/SUB tous les subscribers recoivent une copie du job.
3. Zreceive a créé un ZMQ_DEVICE. Celui-ci relie la socket ZMQ_PULL vers une socket ZMQ_PUSH. Le device transmet tout ce que reçoit la socket de PULL vers la socket de PUSH. A noter que la socket ZMQ_PUSH est ici de type ZMQ_INPROC, ce n’est donc pas une socket TCP mais une zone mémoire partagée avec une autre thread.
4. Un thread Zdispatch est connecté en ZMQ_PULL sur la zone mémoire inproc. Il désérialize les jobs reçu dans un objet BSON puis émet un signal Qt avec la charge créée.
5. L’objet Payload reçoit la charge dans un slot. A noter que cet objet possède à une référence vers un objet Nosql ce qui lui permet d’interroger MongoDB. Dans ce cas il est impératif que le slot Payload ne soit pas appelé alors qu’il n’a pas fini ses tâches en cours. Pour cela le QObject::connect qui relie le signal de Zdispatch avec le slot de Payload doit impérativement posséder la directive  Qt::BlockingQueuedConnection. Payload découpe la charge reçue, effectue des traitements, sérialize des objects puis emet des signaux pour chaque worker.
6. Le thread worker_push possède un slot par signal emit par Payload. Lors de sa construction il a bindé chaque socket ZMQ_PUSH par worker. Il transmet alors la charge en mode non bloquant ZMQ_NOBLOCK.
7. Chaque worker ZMQ_PULL sur sa socket TCP dédié. Traite puis stocke dans MongoDB.

Les cadences.

Elles rythmes le workflow, s’il n’y avait qu’une seule cadence ce backend serait synchrone. Cependant on voit très bien plusieurs.

1. Tout d’abord le serveur Thin, qui transmet le job et retourne aussitôt une réponse au client.
2. Ensuite le thread Zreceive, retransmet à son rythme les jobs dans une zone mémoire
3. Le thread Zdispatch lit la zone mémoire puis faire suivre les jobs dans des signaux Qt.
4. L’objet Payload transmet les bouts de job dans des signaux vers des slots.
5. Le thread worker_push envoie à chaque worker sa charge

L’entrée et la sortie du dispatcher sont non bloquante. Si ce dernier plante, le serveur Thin et le worker se rendront compte de rien. De plus contrairement à un serveur classique, les sockets zeromq permettent de lancer des clients même si le serveur n’est pas lancé. Si le dispatcher tombe il pourra être relancé sans problème et les workers recevront à nouveau leur jobs.

Conclusions

L’architecture du dispatcher n’est pas encore optimisée, par exemple les positions 4, 5 et 6 pourraient fusionner. Cependant le Proof Of Concept est concluant, ce backend devrait pouvoir s’exécuter correctement sur une machine recyclée. Une dernière tâche serait de migrer le serveur Thin dans un thread en Qt afin de simplifier et optimiser encore l’architecture, ou bien d’utiliser Mongrel2 à la place de Nginx et Thin comme me le conseillait un certain Zed Shaw

La cible d’obtenir un backend asynchrone brokerless étant atteinte la prochaine étape est l’intégration d’un worker qui permette la synchronisation en P2P des données du backend. L’objectif est qu’une instance Nodecast se synchronise avec l’instance d’un contact de l’utilisateur. Gros travail en prespective, les solutions sont nombreuses comme telehash mais qui ne fourni pas pour l’instant d’implémentation en C/C++, ou bien la lib bitdht utilisée par entre autre par retroshare.

Constat et évolution

Tout d’abord Gearman qui était idéal sur le papier s’est avéré très instable à l’usage, comme l’ont constaté d’autres développeurs sur la liste de diffusion. Ils ont l’air malgré tout d’avoir confiance en leur produit car ils vont ouvrir un service d’hébergement de files d’attente basé sur German : GearmanHQ.

Après quelques recherches je me suis finalement dirigé vers un serveur de files qui implémente le protocole AMQP ce qui permet de ne pas dépendre d’un serveur en particulier. Plusieurs serveurs libres l’implémentent, comme RabbitMQ (racheté par VMware), ActiveMQ ou Qpid.

L’autre problème est venu des workers qui traitent les données envoyées par le client desktop ( nodecast-gui ). Le code Ruby était tellement lent qu’il fallait parfois plus de 1 minute pour effectuer un traitement de parsing et insertion dans MongoDB. Je pense que le problème venait de la pile Ruby / Mongoid / Mongodb ruby driver et non de Ruby seul, mais il n’est tout simplement pas concevable que le worker qui intègre dans la base les processus utilisateur met plus ou moins 2 minutes pour effectuer 1 traitement avec une charge CPU maximale.

J’ai donc décidé de récrire les workers ainsi que le dispatcher, en C++ avec l’aide de Qt. Mes tests en développement sont passés à moins de 1 seconde sur le worker process, le plus lourd…. Evidemment l’effort de développement est certes plus conséquent mais les résultats sont largement payant pour que cet investissement technique paye.

Qpid quant à lui s’est pour l’instant imposé de lui même, car il est le seul à proposer une API C/C++ fonctionnelle. Des plugins permettent de lui ajouter une persistance sur disque, des fonctionnalités de cluster, du support SSL et XML en natif. Il fait d’ailleurs partie du coeur de la solution de Red Hat Enterprise MRG. Cette architecture représentée par le schéma plus bas reste tout de même à valider par l’épreuve du feu de la production.

Ingénierie

Néanmoins il est à mes yeux évident qu’un service web ayant pour objectif à moyen/long terme la prétention de monter en charge, se doit d’avoir une architecture scalable et cela dès sa conception. C’est toute la différence entre créer un site web et créer une architecture web, ou bien entre le développement logiciel et l’ingénierie logicielle. Cette dernière implique une réflexion sur les méthodes de travail, les outils à utiliser, qu’ils soient ceux utilisés par les développeurs que ceux à utiliser dans l’architecture;  la veille techno, etc. En somme tout ce qui permet d’optimiser sa productivité, l’architecture mise en place n’en sera que le reflet, réussi ou pas, de ces choix…

Voici un exemple du résultat de l’ingénierie logiciel avec cette présentation de l’architecture logicielle de la nouvelle version de LinuxFR.org l’un des plus gros site technique francophone.

Implémentation

Pour revenir à Nodecast, les workers utilisent les drivers natifs de memcached, pour invalider le cache dont la page a été mise à jour, de MongoDB et de Qpid, ce qui permet, en ayant aucune couche d’abstraction intermédiaire d’obtenir les performances maximales. Le framework Qt permet d’obtenir une certaine simplification du développement, grâce entre autre aux signaux, même si en effet la bibliothèque Boost intègre cette fonctionnalité.

J’ai développé nodecast-worker de manière relativement générique afin qu’il instancie la bonne classe worker selon le paramètre –worker-type fourni en argument :

nodecast-worker --memcached-ip=127.0.0.1 --memcached-port=11211 
--mongodb-ip 127.0.0.1 --mongodb-base=nodecast_prod --qpid-ip=127.0.0.1 
--qpid-port=5672 --worker-type=process

L’usage du serveur de file Qpid, permet outre le fait de rendre les traitements asynchrones, de monter un cluster de worker d’un même type sans développement particulier. En effet chaque worker s’abonne à la même file d’attente Qpid de type pub/sub (amq.topic). Une routing key appliquée par le dispatcher sert à taguer chaque message envoyé dans la file d’attente. Ainsi les workers filtrent les messages qui leur sont destiné, par exemple le tag worker.cpu pour le worker qui va traiter les messages qui contiennent les données de CPU envoyées par le client desktop nodecast-gui.

Comme il est possible de lancer plusieurs instances worker du même type, chacun des worker dépile la même file taguée ce qui permet de répartir la charge sur plusieurs processus, voir aussi de la répartir sur des machines physiques différentes puisque les workers utilisent des connexions TCP … !

Pour comprendre les rouages et le potentiel d’une telle architecture, je conseille la lecture de ces 2 excellents articles sur l’utilisation d’un serveur AMQP : Introduction à RabbitMQ – AMQP Partie I et Introduction à RabbitMQ – AMQP Partie II

Pour finir sur cet épisode, ce développement me met de plus en plus la puce à l’oreille sur la nécessité de développer un framework / service qui permettrait le développement rapide de workers, de les enchaîner, les monitorer en temps réel et de les administrer. Ce framework / service proposerait en outre l’accès à une multitude de bibliothèques et d’API vers des services externes afin de pouvoir implémenter n’importe quelle idée, de manière rapide, stable et scalable. Cela éviterait de devoir redévelopper la roue et de devoir gérer toutes les exceptions inhérente à l’utilisation d’API bas niveau (timeout, déconnexion, reprise, exception, start/stop, …). En quelque sorte un tarpipe OpenSource mais qui permettrait d’utiliser n’importe quel langage script ou langage compilé. Comme on dit, je dis ça, je dis rien

Workflow

Le schéma suivant montre l’architecture en court de développement du backend de Nodecast. On y voit les 3 paliers asynchrones par lesquelles transite le traitement d’un message.

nodecast architecture

Palier 1

Le premier palier nécessite 7 étapes.

1. Le client nodecast extrait les données système de la machine, génère un XML et l’envoie par un POST (ajout) ou un PUT (update) HTTP.
2. le serveur web Nginx fait suivre la requête vers le cluster web Thin.
3. Thin exécute via rack le DSL Sinatra qui sert à créer simplement l’API REST de nodecast.
4. Ce dernier vérifie dans MongoDB les droits d’accès (couple email / token) grâce à un auth basic request HTTP transmis par le client,
5. Si l’autorisation a réussie, le code Sinatra stocke le XML dans le GridFS mongoDB, génère une collection de hash et transmet la charge dans queue dédiée au dispatcher.
6. Le code sinatra génère un XML de réponse au client.
7. NGinx le fait suivre au client, ce qui termine du point de vue utilisateur le traitement.

L’objectif de ce palier est d’être le plus minimaliste possible afin qu’une autre requête puisse être traité avec le moins d’attente possible. L’auth, la conception de la charge, sa transmission et la réponse au client sont malgré tout chacune nécessaire. Dans cette architecture asynchrone il n’est pas possible de signaler dans la même passe, la bonne fin du traitement à moins de revenir à une architecture synchrone non scalable… A vrai dire il n’est de toute manière pas nécessaire de le signaler puisque le service tourne en arrière plan sur le poste utilisateur.

Palier 2

La transmission de la charge utilise 2 canaux AMQP direct : dispatcher.update ou dispatcher.add. Le dispatcher est lancé selon cette ligne de commande :

 nodecast-dispatcher --mongodb-ip 127.0.0.1 --mongodb-base=nodecast_prod 
--qpid-ip=127.0.0.1 --qpid-port=5672

1. Il écoute les 2 files d’attente puis lors de la réception d’une charge, il vérifie l’existence de l’hôte à mettre à jour si c’est un update ou bien créé l’hôte si c’est un ajout.
2. Il injecte ensuite le XML extrait du GridFS dans un QHash Qt. Il sérialise ce QHash et envoie par AMQP la partie dédiée à chaque file de chaque worker concerné (hash["network"] pour le worker network par exemple). En clair, le XML est découpé et chaque morceau est envoyé dans la file d’attente de chacun des workers.

Palier 3

1. Tous les workers sont lancés et écoutent la file d’attente amqp.topic sur leur tag respectif (worker.cpu, worker.load. worker.uptime, worker.network, worker.memory, worker.process).
2. A réception d’un message, ils le sérialisent, mettent à jour la base de donnée puis invalident le cache de leur page web associée.
3. Ils transmettent via syslog leurs statuts et leurs exceptions.

Avenir

A ce jour les workers process et cpu ont été réécrit et fonctionnent. Il reste l’implémentation des logs vers syslog ou AMQP afin de tracer les traitements des workers via des streams Graylog2.

Je souhaite remplacer Memcached par Redis pour profiter de ses très intéressantes fonctionnalités. Migrer le frontal web de Rails 2 vers la version 3. Stabiliser le client desktop et lui ajouter toutes les fonctionnalités de la lib SIGAR. Développer un client Android. Terminer le rework et Dominer le Monde

- Vendetta Online on Ubuntu Linux -
For the last few months we've been working with Canonical, the company behind 
Ubuntu Linux, to be one of their featured products in the new Software Center 
being rolled out as part of the Ubuntu 10.10 "Maverick Meerkat" release. This Software 
Center will basically bring app-store type functionality to Linux, something that could 
greatly help the platform in gaining acceptance as a desktop OS, and allow easy access 
to a variety of software that exists outside the open-source world 
(such as commercial videogames).
Vendetta Online should appear in the new Software Center sometime next week. 
We were intended to be a debut partner with the OS launch (on10/10/10), but a few 
delays popped up here and there; those have now been addressed and we're confident 
you'll see our title appear there in the near future.

Je faisais parti d’une association, RubyFrance , dont le but est la promotion du langage Ruby dans la francophonie et localement. Or je réalise l’énorme erreur du combat qui était le mien. En effet je réalise qu’essayer de promouvoir une technologie moderne et innovante tel que Ruby et Rails est une perte de temps dans une région qui a 10 ans de retard sur Paris et où il n’y a aucune startup ou presque qui s’y développe !

Avant de vouloir décentraliser le Web il faudrait avant penser à décentraliser le travail. Pourtant le constat à faire est simple, les entreprises et startups dans la capitale ont beaucoup de mal à dénicher des développeurs, or il faudrait peut être réaliser que le coût du logement ne fait qu’augmenter que ce soit en location ou en achat, les transports qui ne font que se dégrader, le cadre de vie au final est de moins en moins attrayant pour tout le monde à Paris.

J’ai dans mon réseau de nombreux développeurs et administrateurs systèmes extrêmement compétant qui ne vivent pas dans la capital, et pourtant les startups française s’entête à ne recruter physiquement que sur Paris, façon 20ème siècle. Etrange façon de voir l’innovation …

Il existe pourtant au moins 2 manières de “dé-Minitiliser” le travail. Par le télétravail bien entendu, qui n’a cure des grèves des transports lui… Il faut cependant que l’entreprise intègre ce mode de travail, en possédant les outils et l’organisation adéquate et que cela convienne aux employés concernés. L’autre solution est de n’avoir que des bureaux commerciaux sur la capital, et de décentraliser les bureaux techniques en province. Cette 2ème solution n’offre que des avantages et peut de plus y associer le télétravail pour certains employés.

Cependant comment promouvoir des technologies productive, Méthodes Agiles / Redmine / Git / Ruby on Rails / NoSQL / Linux / …, lorsque l’environnement professionnel local reste figé sur des architectures synchrones d’un autre siècle en PHP / Java / DotNet / SqlServer,  avec comme méthode de développement le cycle en V … ?

Pour illustrer, j’avais rencontré à Lyon début 2010, un entrepreneur qui se prenait pour un techos, et qui souhaitait monter un site de recrutement avec webcam (rien de révolutionnaire sauf pour lui). Le tout en PHP / MySQL, ce qui déjà n’est pas d’une grande innovation et inutile de parler framework web type Symfony ou Ruby on Rails, inconnus … J’ai bien compris que c’était pour des questions de coût, et qu’il sous entendait migrer ensuite sur DotNet / SqlServer, parce que c’est plus sérieux quand même … De plus monter un tel site n’était pour lui qu’un assemblage de briques OpenSource existante, sans grande difficulté…

Quand on atteint un tel niveau de nullité, il y a quoi à espérer ? Inutile de dire que le site ne verra sans doute jamais le jour, et surtout pas le succès escompté.

Je réalise que j’ai pris le problème à l’envers, il est nécessaire de pousser la création d’un écosystème local d’entreprises innovantes avant de pousser les technologies associées. Un équivalent Lyonnais de http://paris.startupweekend.org serait le bienvenu !

Qu’est-ce que le desktop 2.0 ?

Historiquement le desktop est composé de logiciels installés sur une machine et qui au mieux dans certains cas communiquent entre eux. On télécharge le logiciel, on l’installe, on le paramètre si nécessaire et on l’utilise. Cette description n’a pas changé depuis environ 25 ans. Pour une mise en perspective, le web qui est venu bien après, qui est complexe à faire évoluer techniquement et administrativement, a régulièrement évolué et fait un bond en avant avec HTML5 : http://slides.html5rocks.com/#slide3

Le desktop 2.0 pourrait être un desktop qui utilise Internet afin de proposer des fonctionnalités supplémentaires. A priori ca existe déjà, par exemple iTunes qui permet de consulter le store d’Apple et d’y faire des achats depuis une interface native. Sauf que iTunes n’est qu’un logiciel qui intègre le moteur d’un navigateur web afin de présenter de manière un peu mieux intégré au desktop le store et surtout de gérer les DRM sur les fichiers achetés…

L’intérêt d’Internet est essentiellement de pouvoir partager et communiquer, consommer n’étant qu’une forme particulière de partage sous contrainte.

Mais pour moi il ne représente en aucun cas un but final. Dans les années 2000 on disait “il FAUT être sur Internet”. C’est une perception complètement erronée de l’outil ce qui a à mon avis complètement pervertie notre conscience. En effet, à l’époque le contexte était qu’il fallait y être en ayant un site web. Maintenant en 2010 il FAUT y être en ayant des suites bureautiques en web, des systèmes d’exploitation en web, et toute une suite de logiciels, en web …

Joost le fameux logiciel de vidéo en P2P par les créateurs de Kazaa est mort soit disant car il fallait installer un logiciel… Bullshit !!! La version full web est tout aussi morte. Joost est mort car il n’y avait pas de contenu. Et il y en avait pas car le seul contenu autorisé venait que des partenaires … Ca s’appelle la télévision ça, ce n’est pas Internet.

De fait la vision que nous avons d’Internet n’a pas changé depuis ses premiers pas ! Une vision très restrictive de l’outil.

Si le desktop 2.0 ne ressemble pas aux iTunes like, si ce n’est pas des applications web, qu’est-ce qu’il est ?

Le desktop 2.0 existe déjà

Plutôt que de décrire la chose avec des métaphores et des descriptions techniques autant prendre l’exemple parlant du seul gars qui a compris ce que c’était, qui l’a même pratiquement inventé et industrialisé à grande échelle : Steve Jobs.

Quoi encore lui ! bin oui … l’iPhone c’est quoi ? C’est un ordinateur (de poche) capable d’aller sur Internet (comme un ordinateur avec un abonnement Internet), et un kit de développement, le tout suffisamment bien conçu pour rendre n’importe quelle application web2 ridicule.

Attention tous les mots de cette phrase ont leur importance, notez d’ailleurs l’absence du mot téléphonie, car ne m’intéresse pas dans le contexte de ce billet. Et d’ailleurs le succès de l’iPad en rajoute une couche puisqu’il ne fait pas téléphone …

l’iPhone et maintenant l’iPad implémententent le desktop 2.0, car :

• Les applications sont natives. Ce qui rend “l’expérience utilisateur” (comme on dit), beaucoup plus fun, car cela apporte :
  • La réactivité
  • L’intégration au bureau
  • L’accès aux extensions matériel actuelles et à venir (3D, GPS, gyroscope, accéléromètre, …)

Et qui dit fun, dit j’utilise plus facilement qu’une application web qui ne peut pas avoir ces avantages. Qui dit j’utilise dit je suis potentiellement prêt à payer.

• Les applications utilisent Internet. Et je parle bien des applications pas uniquement du navigateur web !
• Les applications sont faciles à trouver, à installer et à mettre à jour grâce à l’AppStore.

NATIF, INTERNET, STORE

Ces 3 termes définissent bien la chose. On peut faire un paquet de reproches justifiés à Jobs, par contre on ne peut pas lui enlever la vision qu’il a eu. Car il ne suffit pas de dire je vais faire un téléphone qui peut aller sur Internet, ca existait déjà avant l’iPhone. Il faut imaginer ces 3 concepts, faire fabriquer le matériel qui tient la route, développer les logiciels et les services, et intégrer le tout de manière cohérente.

Google a d’ailleurs bien compris la leçon, et le confirme avec le succès d’Android.

Et le PC ?

NATIF ?

De manière historique les applications sont natives, mais pour diverses fausses bonnes raisons (déploiement et mise à jour) beaucoup d’applications “professionnelles” sont uniquement en web (IE6).

INTERNET ?

Depuis le début d’Internet les PC y accèdent. Sauf qu’ici dans la description du desktop 2.0 je parle des applications. Or il faut bien avouer qu’à part le navigateur web il n’y a pas beaucoup d’applications qui exploitent Internet, même en 2010 !!!

STORE ?

Gros point d’avance pour Linux qui possédait un “store” depuis la naissance de Debian au moins, dans les années 90 (et voui). Nous parlons de dépôts. De nos jours toutes les distributions en possèdent un et il permet de plus de mettre à jour tout le système et pas uniquement les applications utilisateurs !

Hormis Linux point de salut du côté de Windows et MacOS, même si des rumeurs d’appstore pour MacOS X ont circulé.

Arguments

NATIF !

Parmi les arguments en faveur d’une application native qui aboutissent à une “expérience utilisateur” agréable, il y en a une autre loin d’être négligeable pour le développeur, la facilité de développement. Il faut certes maitriser la technologie nécessaire à développer une application native, mais d’une part le choix est vaste sur un PC, et d’autres part une application web “équivalente” va nécessiter la maitrise d’un paquet de technologies côté client (Javascript, HTML, XML, CSS) pour un résultat bien inférieur et la maîtrise de plusieurs boites à outils nécessaires à débuger tout ça.

Pourquoi est-ce si pénible ? Tout simplement parce que le web n’a jamais été prévu pour développer des applications mais simplement pour afficher des pages … Bien sûr l’HTML5 vise à remédier à ces lacunes, mais cela restera malgré tout en deçà de n’importe qu’elle application native correctement développé et intégré. Et ne parlons même pas de l’exploitation de périphériques matériel ou même de la 3D, webgl commence à peine à être intégré à certains navigateurs web, en 2010 …

Enfin une botte secrète du web est la compatibilité de l’application quel que soit l’OS. Je balaie cela d’un revers de la main, car du coup on a renvoyé vers le développeur la complexité de la chose ainsi que vers le navigateur, on se rappelle tous des années de lutte à faire respecter les standards afin d’afficher et pouvoir utiliser correctement une application web… De plus une bibliothèque comme Qt est multi-plateforme, il n’y a qu’à voir Skype ou Opera. Et bien entendu Java (Eclipse, …)

Pour en revenir au faux exemple de Joost, devoir installer une application n’est pas une contrainte. Les succès de Skype, Dropbox, Spotify, iTunes, … le prouvent. Le frein est simplement la nullité d’une mauvaise application.

INTERNET !

Un des avantages d’une application web et ce qui a entre autre expliqué leur explosion est le fait de pouvoir tout stocker côté serveur. L’utilisateur a ainsi qu’à se rappeler de son login et mot de passe pour retrouver toutes ses données. Or rien empêche une application native de faire de même ! Elle peut même faire en sorte de stocker en local si une coupure au réseau survient.  C’est précisément ce que vient combler l’HTML5 pour les applications web …..

Les développeurs d’applications natives pour iPhone ont eux bien compris l’intérêt et ne s’en prive pas. Internet devient de fait ce pour quoi il est bon : stocker, présenter et partager des données. L’application native se contente elle de faire ce pour quoi elle est bonne : faire l’acquisition des données via l’utilisateur et/ou des extensions matériels (GPS, accéléromètre, gyroscope, …) et rendre cela agréable en exploitant au maximum les capacités du matériel.

Alors peut être qu’il y aura un jour une version d’HTML qui va permettre d’accéder au GPS … laule…

Un exemple concret de l’intérêt d’Internet ? Prenons un logiciel natif comme un client mail qui propose des fonctionnalités complémentaires comme la lecture de flux RSS. La personnalisation de ces flux comme l’ajout et leur catégorisation nécessite un certain temps. Or si vous avez un laptop comme ordinateur secondaire, ou bien celui du boulot, vous devrez refaire ce travail redondant de paramétrage, et je ne parle même pas qu’un article lu depuis son travail sera marqué non lu chez soi… Si ce logiciel pouvait sauvegarder sa configuration et ses données sur Internet, il suffirait d’une simple synchronisation pour se faciliter là vie.

A remarquer que la Mozilla Fondation a très bien compris cela puisque qu’elle propose l’extension Firefox sync, ainsi que Google chrome qui gère ça nativement. A leur avantage ces 2 entités ont de très forte compétences en développement client et serveur, ce que n’a pas forcément le développeur d’une application desktop lambda. Remarque importante pour la suite de cet article.

STORE !

L’autre avantage d’une application web était sur les déploiements et les mises à jour. Cependant grâce aux stores cet argument s’efface, et pour les OS préhistorique qui ne gère pas encore cette fonctionnalité, il parait trivial d’ajouter cela au sein même de l’application …

De plus un store permet de faciliter la vente de son application, ce qui est loin d’être négligeable. Côté Linux seul Canonical semble le comprendre et faire un pas dans ce sens. Il semble que le “petit” milliard de dollars reversé par Apple aux développeurs iPhone, ait fini par convaincre, il était temps !

QUEL AVENIR

du Desktop

D’un côté il va y avoir le fameux Chrome OS qui est là pour renforcer la présence des applications Google. Le truc drôle c’est qu’eux ont bien compris les limitations du web, aussi compétent soient-ils, et aussi bien HTML5 soit-il. Donc afin de rendre les applications web plus agréable et pour pouvoir développer tout type d’application, ce qui est important lorsqu’on a la prétention de faire un OS grand public, ils proposent le plugin Chrome nativeclient qui va permettre de développer des applications … natives … à l’intérieur de Chrome ! On marche sur la tête ?!

Ou quand le web réinvente le natif afin de combler ses propres lacune tout adaptant à son monde ce qui fait le succès d’Apple… Et bien entendu Google étant loin d’être bête va proposer son “store” market pour son OS.

De l’autre, il est heureux de constater certains réveil, encore une fois via Canonical avec son Ubuntu One. Ce service permet de stocker et synchroniser ses données sur Internet via les programmes qui supporte desktopcouch. Et ceci est la réponse aux programmeurs qui n’ont pas les compétences ou l’envie de développer eux mêmes ces fonctionnalités. Il était temps qu’un éditeur d’OS propose ce type d’API à ses développeurs !

Pour pousser le concept un peu plus loin, je rêverais d’un OS qui me permette, suite à son installation, de télécharger automatiquement tous les logiciels que j’utilise sur mon PC principal ainsi que toutes les préférences associées à ces logiciels.

Ces informations personnelles mais pas vraiment critique, pourrait même être partagée via un réseau social si l’utilisateur le souhaite.

du Réseau Social

Ce secteur à la mode a ceci de particulier qu’il est le révélateur flagrant de cette dualité web / desktop. Par exemple, au départ ces applications web de type Facebook étaient complètement fermées et uniquement accessible depuis un navigateur web. Avec la mode web2, ils se sont ouvert via des API ce qui a permis de faire émerger une multitudes d’applications natives pour mobile, puis pour PC.

Quand le web redécouvre l’intérêt du bon vieux client natif… Cependant on en est toujours sur du vertical, une application dédié à un service.

C’est ici que débarque le très intéressant social desktop et son OCS API, une API qui doit permettre l’accès des applications natives à des réseaux sociaux. En effet il est complètement aberrant qu’il faille utiliser une application en particulier pour faire du social ! Cette pratique est complètement transverse est de fait n’importe quelle application est capable de présenter un intérêt social ! Que cela soit d’intégrer le service Gitorious dans un IDE, comme QtCreator qui le fait, ou bien intégrer l’API d’un site de recettes de cuisine à des logiciels de gestion des courses….

Le social est transverse, il est ridicule de devoir utiliser un client dédié ou bien même un serveur en particulier… Côté serveur le très intéressant microblog décentralisé statusnet montre le voie, ainsi que la plateforme sociale décentralisée movim.

A moins que l’on souhaite que le futur du desktop ne tourne que dans l’onglet d’un navigateur web, ce qui est déjà le cas avec Chrome OS, Jolicloud, etc, il reste aux éditeurs d’OS et de bureaux de proposer des services web décentralisés et des API, afin que n’importe application desktop puisse enfin sortir des années 1990…

Pour finir je tiens à poser une question qui peut résumer ce débat.

Les acteurs et organisations du web travaillent à faire évoluer leurs technologies afin de proposer des fonctionnalités les plus proches d’une application native. Les éditeurs de logiciels natifs et développeurs d’environnement de bureau travaillent à proposer des fonctionnalités permettant le développement d’applications qui exploitent les capacités offertes par Internet (web services, cloud, …).

Entre ces 2 visions quelle est celle qui a le plus court chemin à faire et laquelle est la plus à même de répondre aux besoins envies des utilisateurs ?

C’est alors que la lumière fut lorsque je découvris l’offre de “cloud” de StatusNet http://status.net/signup En effet nul besoin de s’auto-héberger (mon temps est précieux), cette offre me permet d’avoir mon propre sous-domaine chez status.net et de l’administrer selon mon bon vouloir, notamment de faire sauter cette stupide limitation de caractères : http://fredix.status.net/

Elle permet aussi d’héberger sa propre communauté http://status.net/whos-using-statusnet, ouverte ou pas, Mozilla ne s’en est d’ailleurs pas privé : http://mozilla.status.net/ On dépasse largement avec tout ça le peu que propose Twitter. Cependant si je souhaite des services complémentaires comme les SMS ou XMPP, Status.net va proposer ce mois-ci une offre premium ajoutant un certain nombre d’options : http://status.net/cloud (SMS, XMPP, fichiers, …) J’espère que le prix sera abordable !

Je trouve cela très intelligent de leur part, et c’est une copie du modèle de http://wordpress.com/. Un logiciel que l’on peut s’installer et héberger soit même, ou bien simplement utiliser la version gratuite, ou la version avec des options payantes. Tout cela avec la garantie de pouvoir récupérer et exploiter ses données à tout instant grâce au code libre téléchargeable.

Cette 3ème voie me semble parfaite pour les logiciels libres qui souhaitent trouver un modèle économique. Il est dommage que pas mal de libristes feignent de l’ignorer, et préfèrent sacrifier le soutient financier du libre sur l’autel de l’auto-hébergement “pure et pas minitel 2.0″ …..

J’estime d’ailleurs que certaines organisations à but non lucratif devraient s’en inspirer afin de financer leurs actions et pourquoi pas même leurs développeurs … Et bien même soyons fou pour financer le développement de services concurrentiels à Google, l’éthique et la confiance accordées à des organisations type FSF , EFF ou GNOME Foundation sont d’une valeur inestimable face à n’importe quelle entreprise suspecte par définition. Mais ceci est un autre débat

Pour terminer, en plus de status.net et wordpress.com il existe aussi l’excellent http://shapado.com/ logiciel libre de question/réponse qui propose un hébergement avec des options payantes (plutôt chères  )  : http://shapado.com/plans Voici un exemple avec un shapado consacré à android : http://android.shapado.com/