Depuis mon dernier article sur nodecast en novembre 2011 j’ai depuis extraordinairement avancé. Historiquement Nodecast.net représentait pour moi un outil de monitoring système, via un client natif desktop et un backend asynchrone. J’ai rapidement décidé de rendre ce backend agnostique pour qu’il puisse être utilisé par tous types de projets. Le site du projet est donc Nodecast.org qui renvoie pour l’instant sur le compte github en attendant une page web de présentation.

Nodecast devient donc officiellement un ordonnanceur, même si ce terme est encore très pompeux face aux ténors propriétaires du marché. Je ne sais pas encore ce qu’il adviendra du projet de monitoring, ni si j’aurais le temps et l’envie de le migrer vers la nouvelle version de Nodecast. Côté desktop j’ai à vrai dire une idée de projet plus excitante

Je tiens à remercier la société Ubicmedia qui m’emploie depuis décembre 2011 et qui m’autorise à travailler sur mon projet à plein temps, dans le but de l’utiliser pour des besoins internes. De fait Ubicmedia fait partie des (trop rares) entreprises françaises qui participent au développement d’un projet opensource, c’est tout à son honneur et à son président Alain Rosset qui a bien compris les avantages qu’il pouvait en tirer.

A ce jour Nodecast permet de gérer des workers qui reçoivent en paramètre un exécutable à lancer. Une fois enregistré, on poste en HTTP un JSON qui contient un workflow d’enchainement des workers, exemple :

curl -H "X-workflow: test" -d '{ "ls": 1, "rm": 2}' --user "user@email.com:16dsqqs" 

http://127.0.0.1:4567/workflow/create

Le premier worker qui s’exécutera s’appelle "ls" et le deuxième "rm", ils lancent bien entendu les commandes éponymes.  L’API renvoi un uuid à utiliser par la suite.

On poste ensuite le fichier binaire ou texte que l’on souhaite traiter, ici qxmpp-0.4.0.tar.gz :

curl -H "X-workflow-uuid: 66e994e8-1824-4604-bcf0-f1a321986888" 
-H "X-node-uuid: d4bd950b-7a04-4ff3-bf73-f840947d1171" 
-H "X-node-password: 69df62ab-4084-4e22-b788-6803c80c9931" 
-H "X-payloadfilename: qxmpp-0.4.0.tar.gz" 
-X POST --data-binary @qxmpp-0.4.0.tar.gz 

http://127.0.0.1:4567/payload/create

Les informations à fournir sur le node (le serveur qui POST) sont obtenues auparavant par la commande suivante :

curl -H "X-nodename: your-node-name" --user "email:token" http://127.0.0.1:4567/node/create

Le fichier est ensuite stocké par Nodecast dans GridFS, puis extrait dans le filesystème et son path transmis au premier worker. le retour de la commande (ls dans cet exemple) et transmis au deuxième worker, via Nodecast, qui la donne en paramètre à son exécutable (rm ici). Rien de transcendant comme exemple, mais grâce à l’architecture de Nodecast basée sur Zeromq, il est possible de lancer de multiples workers "ls" et "rm", les messages seront alors transmis à une instance aléatoire de chaque type de worker. La connexion entre les workers et Nodecast étant en TCP il est bien sur possible de répartir les workers sur une grappe de serveurs. Attention le fichier transmis à Nodecast étant stocké sur le file system, il faudra un partage NFS pour que les workers y aient accès en réseaux. Je souhaite cependant utiliser les fonctionnalités de stream de données de Zeromq pour la transmission vers les workers.

Mon prochain gros travail sera de terminer les workers de type service et leur éventuel communication avec les workers. Ensuite développer une API qui permettra de développer des IHM afin de connaitre l’état des workers, les piloter, etc …

Pour finir voici les derniers schémas côté utilisateur et développeur