URL: https://linuxfr.org/news/entretien-avec-antoine-mercadal-d-archipel-project Title: Entretien avec Antoine Mercadal, d’Archipel Project Authors: Nÿco Date: 2011年11月07日T14:22:06+01:00 License: CC By-SA Tags: objective-c, firefox, xmpp, entretien, virtualisation, interview et coulisses Score: 24 Antoine Mercadal est le développeur principal du logiciel libre _Archipel Project_. _**LinuxFr.org :** T’es qui toi ?_ Antoine Mercadal (primalmotion). Je suis créateur, architecte, mainteneur, développeur principal du projet _Archipel_ et, maintenant, le [co‐fondateur de TrivialDev](http://trivialdev.com), la société derrière _Archipel_. _**LinuxFr.org :** Qu’est‐ce qu’Archipel ? Qu’est‐ce que ça fait et comment ?_ C’est un outil décentralisé de gestion de plates‐formes virtualisées. Il est basé sur la bibliothèque _libvirt_ pour ce qui est communication avec les engins de virtualisations, et sur [XMPP](http://fr.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol) pour tout le reste ! Le projet est séparé en deux composants : un agent en Python à installer sur les hyperviseurs, et l’interface utilisateur en [Cappuccino](http://fr.wikipedia.org/wiki/Cappuccino_%28framework%29) à installer où l’on veut. Il faut aussi disposer d’un serveur XMPP (soit en installer un, soit réutiliser un serveur déjà existant). *Suite de l’entretien en seconde partie de dépêche.* ---- [Archipel Project](http://archipelproject.org/) ---- _**LinuxFr.org :** C’est sous quelle(s) licence(s) ?_ Principalement AGPLv3, certaines bibliothèques développées pour Archipel sont sous LGPL v3. _**LinuxFR.org :** C’est développé autour de quelles « technos » ?_ L’agent est en Python. Il utilise la bibliothèque _python-libvirt_ pour communiquer avec l’hyperviseur et la bibliothèque _xmpppy_ pour discuter avec les autres hyperviseurs, les machines virtuelles ou les utilisateurs. Un agent instancie une « entité XMPP » disposant de son propre JID représentant l’hyperviseur, puis exécute un _thread_ par machine virtuelle (disposant aussi chacune de leur propre JID). Chacune de ces entités utilise _libvirt_ pour transmettre les commandes au sous‐système de virtualisation. On peut voir l’agent un peu comme un pontage entre XMPP et _libvirt_. L’interface graphique est en Cappuccino (et donc du pur JavaScript). Pas de _back‐end_, pas de PHP, pas de Java, pas de MySQL, ni rien. Du JavaScript qui se connecte en XMPP (par [[BOSH]]) et qui permet d’envoyer des commandes à toutes les entités (hyperviseurs, machines virtuelles ou utilisateurs). Cappuccino est écrit en Objective-J, qui est au JavaScript ce que Objective-C est au _C_. Cappuccino est un port de Cocoa en Objective-J. Le but est de faire de véritables applications Web. _**LinuxFr.org :** Avez‐vous conçu des extensions au protocole XMPP ? Comment faites‐vous communiquer les entités entre elles ?_ Non. Archipel utilise simplement une combinaison d’IQ (_Info/Query_) et de [[PubSub]]. Pour une action ponctuelle (du genre « quelle est la liste des VMs ? »), on envoie un IQ, on attend la réponse. Pour les trucs plus longs, comme cloner une machine virtuelle, on envoie un IQ, on a une réponse qui affirme que la commande a bien été reçue. Plus tard, quand le clonage est terminé, un événement est publié dans le PubSub personnel de la machine virtuelle, et les clients reçoivent tous le _« push »_. Par dessus cela, il y a l’interface de commande par _chat_ (message), plus simple. _**LinuxFr.org :** Des exemples de « chats » avec des machines virtuelles ?_ Le vocabulaire est plutôt simple pour le moment. Il est possible de leur dire _« Hello! »_, et les machines virtuelles (VM) répondront _« Hello bidule, how are you? »_, ou bien _« How are you? »_, et elles vous répondront en vous donnant les statistiques d’utilisation des ressources, etc.. Ensuite, on peut leur demander _« help »_, pour qu’elles affichent la liste des commandes comprises, leur utilisation et leur syntaxe. Cette liste est dynamique et peut bien évidemment être étendue par les modules. Pour le moment, les conversations ne sont pas contextuelles, dans le sens où il n’y a pas de jeux de questions‐réponses. Il n’est pas possible de faire : _— Can you create a new drive?_ _— Sure, what size, name and format?_ _— qcow2_ _— And name and size?_ etc.. Mais il est prévu d’ajouter tout ceci, ainsi qu’une gestion plus naturelle du langage parlé, grâce à des bibliothèques du genre _Natural Language ToolKit_ (NLTK). Le but a toujours été d’avoir un truc à la Siri d’Apple, mais pour le moment, je me concentre sur les fonctionnalités liées à la virtualisation depuis l’interface utilisateur. Les VM parlent aussi d’elles‐mêmes. Si un utilisateur ajoute un disque, elle diffusera à tous les utilisateurs dans son tableau de service (_roster_) : _« Hey, machin has just created a new drive named "mydrive.qcow2", with a size of 10 GiB. »_ _**LinuxFr.org :** Archipel, à quoi cela se compare‐t‐il de libre ou de proprio ?_ On peut comparer Archipel à _oVirt_, feu Enomalism, ProxMox ou certainement une des nombreuses déclinaisons de VMWare... _**LinuxFr.org :** Quelles sont les tueries de ce logiciel ?_ * **XMPP** : tout est _push_. Si vous ajoutez un disque virtuel à une VM, il apparaît directement dans les GUI de tous les autres utilisateurs connectés. On est enfin au courant de ce qui se passe sur l’infrastructure en direct. Pas besoin d’être au téléphone avec les autres administrateurs de la plate‐forme pour savoir qui fait quoi ; * **Cappuccino** : ce que l’on peut faire avec ce _framework_ est hallucinant. En plus, il est possible d’utiliser les outils de développement d’Apple (Xcode) pour faire les interfaces graphiques... graphiquement ! C’est excellent. Je suis d’ailleurs pour l’occasion devenu un des plus gros contributeurs de Cappuccino ; * **Modulaire** : Archipel a été pensé dès le début pour être totalement modulaire. Et ce n’est pas un système d’extensions ajouté à un cœur bien défini de fonctionnalités autour de la virtualisation. En fait, tout dans Archipel (à part la gestion bas niveau du XMPP : connexion, _roster_, envoi de commandes, etc.) est écrit dans des modules. Cela assure aux développeurs une API bien foutue, puisqu’utilisée partout dans l’application ; * **0 % Java** : même le client VNC intégré est en JavaScript / HTML 5 ; * **_Chat_** : on peut littéralement discuter avec les machines virtuelles et les hyperviseurs depuis l’interface d’Archipel ou n’importe quel client XMPP (et donc depuis son _smartphone_). C’est pas fun, ça ?! _**LinuxFr.org :** Y a‐t‐il un business model autour ?_ Oui. [TrivialDev](http://trivialdev.com), dont je suis le co‐fondateur, propose des services autour d’Archipel. Installation, conseil, déploiement, formation, développement spécifique pour Archipel, mais aussi autour de Cappuccino. Très important : il n’y a pas et il n’y aura pas de version dite « entreprise » plus étoffée que la version communautaire. 100 % d’Archipel est libre. Pas de version d’essai, genre : le gratuit c’est fun mais si vous voulez la fonctionnalité nécessaire et obligatoire, alors c’est payant et propriétaire. Ici pas de _freemium_, pas d’_open core_. _**LinuxFr.org :** Quels sont les déploiements publics ou privés (dont vous pouvez parler) les plus significatifs ?_ Archipel est utilisé dans plusieurs universités, françaises ou étrangères. Chez Alcatel‐Lucent, pour gérer une plate‐forme de développement et de tests, ainsi qu’au CERN, pour gérer les machines virtuelles dédiées au stockage des informations récoltées par le LHC. D’ailleurs, il y a beaucoup de contributions de la part des gens du CERN qui ne devraient pas tarder à montrer le bout de leurs _« pull requests »_ (demandes d’intégration du code). Beaucoup d’autres entreprises utilisent Archipel, sans forcément nous le dire. C’est le jeu du logiciel libre. Difficile, ici, de leur dire que nous savons qu’elles sont utilisatrices d’Archipel, et que si elles ont besoin d’aide, alors la société TrivialDev peut les aider. _**LinuxFr.org :** Combien êtes‐vous de contributeurs ?_ Il y a 22 « forks » sous GitHub. Il y a une petite quinzaine de contributeurs actifs. _**LinuxFr.org :** Comment est né le projet ? Comment a‐t‐il évolué ? Quels sont les faits marquants ?_ D’une mission chez un client sur l’orchestration pour une plate‐forme virtualisée. Tout ce que j’avais essayé était soit moche, soit pas adapté, soit en train mourir ou déjà mort. J’avais envie de me lancer dans un projet _open source_. Je voulais aussi jouer avec XMPP. J’ai donc fait un tout petit PoC (NdM : _Proof of Concept_, une maquette quoi) qui permettait de démarrer ou d’arrêter une VM gérée par _libvirt_ via _chat_. Ça m’a plu. Au début, je me suis dit que je n’allais pas développer d’interface utilisateur, laissant les clients XMPP gérer les commandes. Puis j’ai découvert Cappuccino. Un truc de plus à essayer. Puis, de fil en aiguille, un paquet de _« restart from scratch » plus tard, voici Archipel. D’ailleurs, je passe finalement beaucoup plus de temps sur l’interface que sur le reste. :) _**LinuxFr.org :** Quels problèmes avez‐vous rencontrés ?_ Cappuccino est un _framework_ jeune ! Il fallu corriger un paquet de trucs, et en ajouter un paquet d’autres ! Sinon, pas de problèmes majeurs. Simplement parfois, des choses qui pourraient paraître évidentes dans une solution classique, centralisée et synchrone sont en fait très compliquées à réaliser dans le cas d’Archipel, décentralisé et totalement asynchrone. Il faut parfois garder son sang froid quand un utilisateur m’assure que ce qu’il demande « c’est quand même pas grand chose à faire ! ». La partie interface graphique est 100 % JavaScript. Je ne vous fais pas un dessin sur les problèmes rencontrés par le _framework_, mais je préfère vous parler de performance. Il faut clairement un moteur JS digne d’utiliser Archipel. Et tous les navigateurs ne sont pas dignes d’utiliser Archipel. Si vous avez une version inférieure à Firefox 4, vous pouvez passer votre chemin ou mettre à jour votre navigateur. Les navigateurs basés sur les versions récentes de WebKit sont bien gérés. _**LinuxFr.org :** Quelle est la taille des parcs de machines virtuelles que vous pouvez gérer avec Archipel ?_ Il n’y a pas vraiment de limite. Comme chaque entité est indépendante, Archipel est très facilement extensible. Bon, par contre, si vous avez 10 000 marchines virtuelles dans le même _roster_, le chargement de l’interface graphique risque d’être un peu lent (NdA : ne pas essayer). :) _**LinuxFr.org :** Intégrez‐vous des solutions de supervision ? De gestion de parc à la [[GLPI]] ? De sauvegarde et restauration (dont les instantanés — snapshots —) ? D’administration système comme [[Puppet]] ? De la gestion de capacité (capacicity planning) ?_ Il y a un système de supervision basique. On affiche l’historique de la consommation mémoire, la charge moyenne, le consommation du temps processeur des hyperviseurs, ainsi que l’espace disque et les journaux. Pour une supervision plus fine, il y a des solutions qui font cela bien mieux. Pour le moment, Archipel gère les instantanés (_snapshotting_) sans aucun souci, et dispose d’un système de patrons (_templating_) basé sur VMCast (un flux RSS de _templates_ de machines virtuelles). Archipel gère aussi ce que l’on appelle les _Goldens Drives_ (_copy‐on‐write_ — copie sur écriture) et permet, par exemple, d’installer un système une bonne fois pour toute, pour différentes machines virtuelles. Pas de gestion de capacité (_capacity planning_) à l’horizon, mais, eh : _patch welcome_! ;) _**LinuxFr.org :** Y a‐t‐il des API, ou bien tout se fait via XMPP ? Comment puis‐je étendre Archipel ?_ La communication inter‐entités (d’un utilisateur vers une VM, par exemple) utilise une API exclusivement XMPP. Il est bien sûr possible de faire des interfaces en ligne de commande pour envoyer des commandes, mais il faudra passer par XMPP. Ensuite, bien évidemment, il y a des API internes. Il est sincèrement très facile de développer des modules. Il y a plusieurs niveaux d’abstraction, à vous de choisir le plus adapté. Pour les modules agents, Archipel utilise les points d’entrée (_entry points_) Python, et pour l’interface, les _CPBundles_. Bref, que des méthodes standard. _**LinuxFr.org :** Avez‐vous une sorte de console ou de tableau de bord pour une vision agrégée et synthétique du parc ?_ Non. C’est typiquement le genre de truc qui a l’air simple à faire, mais qui, dans un contexte XMPP, est difficile et coûteux en ressources. Pour le moment, le _roster_ (et donc la présence et les messages de statut des VM et hyperviseurs) permet d’avoir une vue d’ensemble sur la plate‐forme. Cependant, il est prévu d’ajouter un tableau de bord par un système d’agents de supervision indépendants. Il sera livré avec le module de facturation et permettra d’avoir des informations bien plus précises. Il jouera le rôle d’une sorte de relais, récupérera les informations de la plate‐forme (par XMPP, évidemment), et enverra une vue consolidée sur demande (par XMPP aussi). Il ne faut pas oublier que l’interface, est en JavaScript. Il est hors de question de demander à tout le monde ses infos en temps réel, cela ruinerait complètement l’expérience utilisateur. _**LinuxFr.org :** Quelle est votre feuille de route ?_ La liste est longue ! Mais les travaux en cours les plus importants sont : - gestion de l’API de stockage de la `libvirt` ; - module de facturation (_billing_) ; - prise en charge de Xen (le pilote _libvirt_ est bogué !) ; - _putils_ en ligne de commande évolués. _**LinuxFr.org :** Merci mec !_ Mais de rien, mec !

AltStyle によって変換されたページ (->オリジナル) /