Virtualisation Entretien avec Antoine Mercadal, d’Archipel Project

Posté par (page perso) . Modéré par baud123. Licence CC by-sa
24
7
nov.
2011
Virtualisation

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, 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 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 à 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.

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, 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 !

  • # C'est bon mangez-en !

    Posté par (page perso) . Évalué à  5 .

    Archipel était LA solution d'orchestration que j'attendais depuis des années ! C'est à dire une interface web qui permette de gérer simplement ses VM.
    J'attendais de voir ce qu'allait donner oVirt... j'attends toujours.

    Depuis quelques semaines, j'ai même mon nouveau serveur perso, sobrement nommé "archipel", qui est une simple debian+kvm+libvirt+archipel, et qui fait exactement ce que je lui demande.

    Et sans être un amateur particuliers des zolies interfaces, il faut reconnaître que c'est tout de même agréable à utiliser.

    Bref, un grand merci à Antoine pour ce projet, et pour sa disponibilité !

    • [^] # Re: C'est bon mangez-en !

      Posté par (page perso) . Évalué à  3 .

      J'attendais de voir ce qu'allait donner oVirt... j'attends toujours.

      Moi aussi, mais maintenant que les sources sont out, j'espère ne plus attendre très longtemps. Archipel a une architecture intéressante, une interface classieuse (même si, franchement, Cappuccino/Objective-J c'est pas trop ma tasse de café), mais quand on bosse avec des gens qui n'ont pas forcément l'esprit le plus ouvert qui soit, un truc comme oVirt permet de sortir l'argumentaire « regardez, c'est Red Hat (+ Intel, etc.) derrière, et en plus c'est écrit en Java, c'est *enterprisey* ! » et, avec un peu de chance, m'épargner l'énième déploiement client sous VMware (j'en ai ras la casquette de VMware, de leurs licences à la noix et de leur vCenter Windows-only tout pourri).

      Envoyé depuis mon PDP 11/70

  • # ESXi

    Posté par . Évalué à  5 .

    Est-ce qu'il est envisageable d'utiliser Archipel avec des hyperviseurs ESXi ? Libvirt parle de support ESX mais selon quelques docs ou mails la prise en charge d'ESXi 4 est un peu ambiguë. Ou sinon, peut-être est-il possible de faire quelque en passant par les différents SDK VMWare (Perl ou Java hein, je vais pas parler de PowerShell...). J'arrive pas à me faire une idée claire sur le sujet.

    • [^] # Re: ESXi

      Posté par (page perso) . Évalué à  5 .

      Si je pouvais me passer de l’infâme vSphere ça serait un pur bonheur.

      Born to Kill EndUser !

      • [^] # Re: ESXi

        Posté par (page perso) . Évalué à  3 .

        Théoriquement oui. Mais effectivement le driver ESX est loin de supporter tout ce qu'il faut pour Archipel. Donc en plus court, pour le moment non.

  • # XMPP : petites questions

    Posté par . Évalué à  5 .

    Bonjour,

    Déjà félicitations pour l'application très propre et bien sympa (même si je n'ai testé qu'avec 2 machines virtuelles kvm).

    Il y a un point qui m'interpelle, le choix d'XMPP. Peut-on savoir ce qui a guidé ce choix ? Car même si la page wikipédia donne beaucoup d'éléments indiquant qu'XMPP va bien au delà de la messagerie et qu'il a trouvé sa place pour les communications inter-applications par exemple, j'avoue que ce n'est pas un choix qui me viendrait par défaut.
    Est-ce que d'autres technologies ont été étudiées avant qu'XMPP ne soit retenu ? Quelles ont été vos sources/références d'informations (s'il y en a eu :-) ) qui vous ont servi dans cette mise en place d'XMPP qui diffère de son usage initial "de messagerie" ?

    Cdt,

    DuF

    • [^] # Re: XMPP : petites questions

      Posté par (page perso) . Évalué à  4 .

      Moi, ce qui me gène le plus, c'est de devoir gérer un serveur XMPP juste pour la virtualisation:
      - Il se passe quoi si le serveur XMPP tombe ?
      - Ca veut dire une machine physique en plus ? On va pas mettre le serveur XMPP sur un des socles j'imagine...

      Pour l'instant je suis sous Proxmox, mais si le passage vers la version 2 devait se faire dans la douleur, je regarderais bien ce qui se fait ailleurs.

      • [^] # Re: XMPP : petites questions

        Posté par . Évalué à  1 .

        On va pas mettre le serveur XMPP sur un des socles j'imagine...

        Pourquoi pas? Au contraire, je suppose que ça fait sens : tu pourrais "pointer" tes machines virtuelles via machinevirtuelle@machinephysique, c'est assez sympa. Enfin je présume que c'est comme ça que ça se fait.

        Après, évidemment, ces serveurs XMPP "socles" ne seraient probablement pas utilisés pour autre chose que la virt, dans ce cas.

        Ceci étant, pas encore testé, je ne fais qu'imaginer.

        • [^] # Re: XMPP : petites questions

          Posté par (page perso) . Évalué à  2 .

          Pourquoi pas? Au contraire, je suppose que ça fait sens : tu pourrais "pointer" tes machines virtuelles via machinevirtuelle@machinephysique, c'est assez sympa. Enfin je présume que c'est comme ça que ça se fait.

          Euh... sauf si tu migres tes invitées d'hôtes, à ce moment là, l'adressabilité devient un cauchemar...

      • [^] # Re: XMPP : petites questions

        Posté par (page perso) . Évalué à  3 .

        Pour répondre à la question :
        - Il se passe quoi si le serveur XMPP tombe ?

        Le serveur XMPP est le serveur de communication. Si il s'arrête, les communications s'arrêtent. Les vms continuent leurs vies sans s'en apercevoir... Il n'y a plus de communications entre l'agent archipel qui s'interface avec la libvirtd et le client archipel qui discute avec l'agent via le serveur XMPP. Rien de plus, rien de moins.
        Et quand le serveur XMPP revient à la vie, il n'y a toujours pas d'impacts pour les vms.

      • [^] # Re: XMPP : petites questions

        Posté par (page perso) . Évalué à  2 .

        XMPP est décentralisé et il est possible de les mettre en clusters. Tu peux en installer autant que tu veux, ou tu veux, comme tu veux. Si tous les serveurs XMPP tombent, plus de communication, mais d'autre problème.

      • [^] # Re: XMPP : petites questions

        Posté par (page perso) . Évalué à  3 .

        • Ca veut dire une machine physique en plus ? On va pas mettre le serveur XMPP sur un des socles j'imagine...

        Bof. Si tu es sous Proxmox, tu as bien un serveur Apache + mod_perl + mod_ssl sur chacun de tes hyperviseurs. Moi, le coup du serveur XMPP ne me choque pas plus que ça…

        Envoyé depuis mon PDP 11/70

    • [^] # Re: XMPP : petites questions

      Posté par (page perso) . Évalué à  5 .

      Comme expliqué, au début le but d'Archipel était pouvoir chatter avec des VMs depuis son client XMPP classique. Le choix était évident. Puis il s'avère qu'il y a de très bonne libraires clientes XMPP en python et en javascript (en en à peu près tout en fait). Archipel est basé sur le push, XMPP est donc le choix de prédilection.

      Ma référence c'est les RFC (http://xmpp.org/xmpp-protocols/rfcs/) et les XEP (http://xmpp.org/xmpp-protocols/xmpp-extensions/) qui montrent bien que le chat avec XMPP c'est une utilisation possible, pas l'Utilisation avec un U majuscule. XMPP est un protocole de push.

      • [^] # Re: XMPP : petites questions

        Posté par (page perso) . Évalué à  4 .

        Red Hat a fait le même choix de XMPP avec son satellite server (le RHN déporté chez un client) pour la mise à jour des différents serveurs / postes gérés en version.
        Chaque serveur remonte les information via XMPP (ou demande les mises à jour qui lui ont été réservées, selon la politique de montée de version) et le satellite server peut aussi effectuer des interrogations (récupérer la conf' matériel ce qui est pratique lorsqu'elle change, ou pousser des installations)...

        Je ne sais pas trop où en est la version libre http://linuxfr.org/news/spacewalk-red-hat-network-satellite-devenu-libre (il y avait le remplacement de Oracle par Postgresql), ni le niveau de la documentation.

  • # Enfin :-)

    Posté par . Évalué à  3 .

    Comme beaucoup j'attendais aussi une bonne solution décentralisée de gestion de mes plateformes virtuelles, dommage que pour Xen ça bug pour l'instant mais je penses migrer progressivement vers kvm donc à tester.

    Bravo pour ce travail

  • # Outils de supervisions de VMs

    Posté par . Évalué à  2 .

    Salut,

    Pour une supervision plus fine, il y a des solutions qui font cela bien mieux

    Lesquelles par exemple ?

    Comme d'autres, je ne peux que féliciter le travail fait sur Archipel !

  • # version stable ?

    Posté par . Évalué à  1 .

    Archipel est toujours en version BETA. Est-ce assez stable pour le mettre en production ?
    Il y a t-il d'autre beta prévues ? Ou une date de sortie de la version stable ?

    Comment seront géré les mises à jour pour les nouvelles versions ?

    • [^] # Re: version stable ?

      Posté par (page perso) . Évalué à  2 .

      Oui, c'est toujours une version beta. Mais c'est une version beta au même titre que gmail a été en beta pendant des années. La version 1.0 finale sortira lorsqu'elle sera prête.

      Pour les mises à jour, la partie agent est publiée sous forme d'eggs, donc easy_install est ton ami. La partie cliente permet de savoir si une nouvelle version a été publiée avec un lien vers la nouvelle version. Charge à toi de faire la mise à jour.

  • # Integration Infrastructure

    Posté par . Évalué à  1 .

    Saalut!

    Est ce que le support d'outils comme nsupdate (mise à jour du DNS) ou omshell (mise à jour du DHCP) dans Archipel Agent est prévu? un peu dans le style Foreman-Proxy?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.