Étendre les capacités du portail VMware vCloud Director

Dans le cadre de nos activités d’ingénierie dans le monde des infrastructures virtualisées, nous avons pu récemment proposer à nos clients un nouveau type de prestation : l’extension d’un portail de gestion d’infrastructure virtualisée : VMware vCloud Director.

Cet article de notre blog revient sur ce concept qui permet d’ajouter des fonctionnalités personnalisées au portail initial et de faire profiter les utilisateurs finaux d’un portail unique pour leurs différents besoins.

Présentation de VMware vCloud Director

VMware vCloud Director (for Service Provider) est un produit assez courant dans le monde des infrastructures virtualisées. On le trouve notamment chez des « Service Providers » de cloud « mutualisé » ou chez des grands comptes.

Via une interface simplifiée, les utilisateurs de machines virtuelles peuvent consommer de la ressources IaaS (Infrastructure-as-a-Service) dans un contexte restreint à leur besoin ou à leur appartenance (client/entité…).

Nativement le portail de vCloud Director (vCD) est notamment une surcouche aux produits VMware tels que vCenter/vSphere, et NSX-V pour la consommation de réseaux. Le périmètre natif de vCD se limite à-peu-près à la consommation de machine virtuelles (VM), de ressources de stockage et de réseaux (L2/L3).

Le concept d’extension

Depuis la version 9.1 (sortie en mars 2018), vCloud Director bénéficie d’une fonctionnalité d’extension. Cela permet aux administrateurs de ce portail d’étendre le périmètre de fonctionnalités offertes via le portail.

Via un développement adapté, on peut ainsi créer le contexte technique d’exécution de son extension, selon ses besoins et ajouter de nouvelles sections adaptées au portail vCD.

Exemple : Proposer aux utilisateurs d’un portail vCloud Director la possibilité de créer des tickets de support directement depuis ce portail.

Le périmètre d’une extension personnalisée est adaptable en fonction des besoin de la plateforme. On peut donc choisir de publier l’extension pour :

  • Les administrateurs de la plateforme
  • Les organisations « clientes », avec au choix, une publication pour :
    • Toutes les organisations
    • Des organisations sélectionnées
Exemple de publication d'une extension
Exemple de publication d’une extension

Étendre l’UI

Un des premiers intérêts de cette nouvelle fonctionnalité d’extension de vCloud Director est la possibilité d’intégrer, dans l’interface utilisateur (UI), une nouvelle section permettant l’accès aux fonctionnalités ajoutées.

Cela inclus donc l’ajout d’un item dans le menu de navigation principal :

Exemple d'extension du menu principal
Exemple d’extension du menu principal

Et la possibilité d’ajouter des pages personnalisées pour afficher le contenu de l’extension. Comme la page est chargée à l’intérieur du portail vCD, il est souhaitable de réutiliser le style et les composants de l’interface native afin de proposer une expérience utilisateur (UX) unifiée.

vCD utilisant le framework open-source Clarity, développé par VMware, pour son interface HTML5, il est possible d’en utiliser les composants (Angular), les bonnes pratiques et les styles associés.

Étendre l’API

Une deuxième possibilité offerte par le kit d’extensibilité de vCD est de permettre l’extension du périmètre des URI disponibles via l’API vCloud. Il devient donc possible, via le chemin standard de l’API vCloud (https://<vcloudserver>/api/) de réaliser des requêtes pour obtenir les informations de notre extension.

Prenons l’exemple suivant :

Notre extension coffee a pour but de lancer une commande sur une machine à café à partir de vCD.

Les requêtes seront envoyées à l’API via ce chemin : https://<vcloudserver>/api/coffee/order et par exemple une requête POST (et ses paramètres) lancera la commande d’un café, une requête GET permettra elle de lister les commandes et leur état etc.

Pour gérer les requêtes personnalisées correspondant à l’extension, un serveur de backend est nécessaire. Celui-ci est hébergé sur une serveur dédié (ou sur le serveur vCD (cell) mais ce n’est pas recommandé) et peut être écrit dans le langage de votre choix (Python, java etc.). Les messages reçus par vCD sur ce chemin de l’API seront transmis à un serveur RabbitMQ intermédiaire et le backend d’une extension viendra consommer ces messages, traiter leur contenu et proposer une réponse, via le système de réponse à un message AMQP.

Dans notre exemple, cela donne :

Chemins utilisés par une requête à destination de l’API de l’extension
Chemins utilisés par une requête à destination de l’API de l’extension
  1. Un utilisateur réalise une requête (via l’UI ou directement via l’API qui lui est exposée).
  2. vCD compile cette requête en un message AMQP et l’envoie avec une routing key spécifique au serveur RabbitMQ.
  3. Le serveur de backend de l’extension peut consommer le message, réaliser éventuellement des traitements (vérification des droits, pré-requis, ouvertures de connexions etc.)
  4. Une ou des requêtes API sont envoyées à notre machine à café (ou un autre produit tiers) pour réaliser la commande.
  5. La machine à café répond avec des données. Ex : « Commande lancée » ou la « Liste des commandes passées ».
  6. Le serveur de backend traite le résultat des requêtes renvoyé par la machine à café (remise en forme, sélection d’éléments etc.) peut alors envoyer une réponse à vCD dans une queue dédiée du serveur RabbitMQ (connue via le champ reply-to de la requête d’origine).
  7. vCD peut alors consommer cette réponse et l’utiliser comme une réponse à l’appel API initial de l’utilisateur.

le SDK vCD d’extension

Pour permettre le développement de ces extensions, VMware met à disposition un SDK (kit de développement), contenant notamment :

  • Le code de base d’une extension (vcd-plugin-seed).
  • Des exemples d’extensions assez basiques. Notamment :
    • About page : sans API
    • Ticketing : extension permettant de générer des tickets de supports avec un exemple d’API en Python (non persistant!)

Un exemple d’implémentation par SII : LUMExt

L’exemple de la machine à café est fictif (même si il serait très pratique en réalité), mais les besoins d’extension pour un tel portail ne manquent pas. À SII nous avons choisi, par exemple, de développer une interface de gestion d’utilisateurs se basant sur un serveur LDAP.

Présentation

Nativement, vCloud Director supporte l’authentification d’utilisateurs enregistrés dans un serveur LDAP. Toutefois, il ne permet pas de les créer ou des les éditer. Il faut que les utilisateurs soient déjà créés pour ensuite les importer dans le contexte vCD de notre choix : une organisation par exemple.

Or, si on héberge des clients qui ne souhaitent pas déployer leur propre serveur LDAP pour gérer leurs utilisateurs vCD mais qui souhaiteraient tout de même utiliser une source d’authentification commune à d’autres besoins (par exemple une authentification unifiée sur des VMs), un serveur LDAP mutualisé est un choix intéressant.

L’extension LUMExt (LDAP User Management Extension for vCloud Director) permet ainsi de déporter, dans l’interface vCD, la gestion des utilisateurs enregistrés dans un serveur LDAP.

Une fois l’utilisateur créé dans le serveur LDAP, il est possible de l’associer à une organisation et à un rôle. L’utilisateur pourra ainsi se connecter à vCD dans l’organisation qui lui est attribuée.

API

L’API de cette extension est un script Python lumext exécutant un nouveau thread à chaque requête présente dans la file AMQP. Parmi les nombreux intérêts d’utiliser les threads Python :

  • Plusieurs requêtes peuvent être traitées en même temps.
  • Le traitement d’une requête n’affectera pas les autres requêtes (en cours ou à venir) y compris en cas d’erreur de traitement.

Pour consommer et publier (consumer/publisher) les messages via le protocole AMQP, nous utilisons le package Python Kombu qui s’avère être très fiable et propose le support natif d’un worker utilisant des threads.

Note : Les exemples de VMware utilisent majoritairement la librairie Pika que nous avons aussi testée mais qui ne permettait pas d’utiliser des threads.

Nous avons développé un MessageWorker appelé VcdExtMessageWorker générique qui lance des threads métiers. Ces threads représentent la complexité inhérente à la gestion de cette fonctionnalité (workflow applicatif, analyse des données, requêtes à des éléments tiers…). Le MessageWorker étant générique, il peut quant à lui, servir à d’autres type de besoins.

Dans le cas de LUMExt, VcdExtMessageWorker exécute un nouveau thread du worker lumext à chaque requête. Ce dernier sera chargé d’analyser le type de demande (lister des informations, créer un utilisateur, l’éditer etc.). Une fois le résultat de la requête mis en forme, il est publié dans la queue AMQP de réponse et consommé par vCD.

L’extension de l’API REST permet donc de mettre à disposition des utilisateurs les chemins suivants :

  • /api : base des APIs vCD (natif)
    • /api/{org_id} : racine d’une organisation (natif)
      • /api/{org_id}/lumext : racine de l’extension (lumext)
        • /api/{org_id}/lumext/user : (lumext)
          • GET : lister les utilisateurs
          • POST : créer un utilisateur
          • /api/{org_id}/lumext/user/{login} : (lumext)
            • DELETE : supprimer un utilisateur
            • PUT : éditer un utilisateur

Cette même API est à disposition des administrateurs qui voudraient mettre en place un outil d’automatisation quelconque pour créer des utilisateurs sur le portail. Elle est aussi utilisée par l’interface (UI) pour accéder aux données.

Enfin, en utilisant le protocole AMQP, des threads stateless et notre MessageWorker basé sur Kombu, nous avons ici une application scalable(extensible) pouvant donc être déployée sur de multiples nœuds et assurer de la haute disponibilité ou un équilibrage de charge.

UI

L’interface utilisateur de LUMExt est intégrée au portail vCD. Elle reprend les mêmes composants Angular et la même charte graphique basée sur le framework open-source Clarity, développé par VMware.

Le menu de navigation principal de vCloud Director est enrichi d’un nouveau lien permettant l’accès à l’interface de LUMExt :

Menu de navigation vCD
Menu de navigation vCD

Par défaut, la liste de utilisateurs de l’organisation est affichée :

LUMExt, liste de utilisateurs
LUMExt, liste de utilisateurs

Dans cette interface, il est intéressant de noter que seule la partie centrale est développée pour l’extension. La barre de navigation et celle de suivi des tâches en cours sont natives à vCD (et non modifiables) :

LUMExt, liste de utilisateurs - Zoning
LUMExt, liste de utilisateurs – Zoning

Pour créer un utilisateur, plusieurs champs sont à remplir:

  • Login
  • Nom
  • Mot de passe (personnalisé, ou généré (coté client) répondant aux critères de sécurité attendus)
  • Confirmation du mot de passe
  • Description (facultative)

Ces données seront ensuite stockées sur le serveur LDAP dans les champs correspondants de l’annuaire.

LUMExt, création d'un utilisateur
LUMExt, création d’un utilisateur

L’interface utilisateur permet aussi l’édition et la suppression d’un utilisateur, ainsi que la mise à jour d’un mot de passe.

Note : Le support de groupes d’utilisateurs est envisagé mais il n’est pas encore développé.


Conclusion

LUMExt est un projet interne à SII que nous publions en opens-source (Licence MIT) sur Github afin de démontrer les possibilités d’extensions de vCloud Director et illustrer cet article au moyen d’un cas d’usage réel et implémenté. Depuis quelques mois, nos équipes sont en mesure de développer de tels plugins pour nos clients et de leur permettre d’étendre les capacités des outils qu’ils utilisent ou qu’ils mettent à disposition de leurs clients (cas d’un « Service Provider »).

C’est aussi un bon exemple d’un travail de concert entre développeurs et ingénieurs en infrastructures à un moment de l’histoire de l’informatique où ces métiers tendent à se rejoindre de plus en plus.


Crédits illustrations

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

deux × 5 =