Nous avons annoncé à la conférence PDC10 la disponibilité en Beta d’un nouveau type de “rôle” au sein de Windows Azure: le “VM Role”. Avant d’explorer de façon pratique la mise en oeuvre de ce nouveau rôle dans un prochain billet, je voulais introduire le sujet en faisant une synthèse du positionnement de ce composant, et en vous donnant un cas concret d’utilisation pour fixer les idées.

Tout d’abord, un bref rappel sur les rôles Windows Azure: au sein de la plateforme d’exécution, que l’on appelle le “Compute”, il existait jusqu’à présent deux types de Rôles: le Web Role et le Worker Role. Il s’agit en réalité de deux modèles de machines virtuelles préconfigurées que Windows Azure met à votre disposition, et que vous pouvez référencer dans votre modèle de service. Autrement dit, un service Azure est décrit dans un fichier (ServiceDefinition.csdef de son petit nom), et vous pouvez assembler dans ce fichier autant de rôles que vous le souhaitez, en piochant dans les modèles existants.

Un service très simplifié pourrait par exemple être constitué de trois rôles, un frontal Web ainsi que deux Worker. L’on pourrait multiplier les rôles dans cette définition, en ayant par exemple plusieurs rôles Web pour un frontal et une interface d’administration, ou encore d’autres types de Worker. La force de Windows Azure est de séparer cette définition du service de sa configuration, qui inclut par exemple le nombre d’instances à démarrer pour chaque rôle; il s’agit du fichier ServiceConfiguration.cscfg. L’on peut par exemple demander trois instances pour le frontal Web, et une seule pour chaque Worker.

image

Les deux types de rôles décrits correspondent à des usages assez spécifiques; schématiquement:

  • Le Web Role permet d’héberger une application Web sous IIS
  • Le Worker Role permet d’exécuter du code, typiquement:
    • tournant en tâche de fond comme un service Windows  (cas du Thumbnail Worker dans l’exemple)
    • exposant des services Web ou autres (cas du serveur WebDAV dans l’exemple)

Dans tous les cas, vous ne fournissez que le code applicatif; c’est Windows Azure qui fournit la machine virtuelle prête à l’emploi et installe votre application dessus. De même, vous n’avez pas à vous soucier de la maintenance du système d’exploitation: Windows Azure ayant la maîtrise de la machine virtuelle, il s’occupe automatiquement de l’installation des correctifs, et même des montées de version. C’est l’atout majeur du Platform As A Service (PAAS), le type de Cloud Computing auquel appartient Windows Azure.

Il y a bien entendu des situations où vous aurez besoin d’avoir quelque peu la main sur le système d’exploitation sous-jacent: c’est typiquement le cas quand votre application, ou l’un de ses composants, a besoin en pré-requis de modifier la configuration du système. Ces situations sont gérées dans les rôles Web/Worker avec les Startup Tasks, également présentées à la PDC10; en voici quelques exemples d’usages:

  • Votre application Web est écrite en Classic ASP, mais ce module n’est pas activé dans le IIS fourni par Windows Azure: vous pouvez l’activer par l’intermédiaire d’une Startup Task
  • Votre Worker s’appuie sur un composant tiers, qui vous est fourni sous la forme d’un MSI ou autre installeur, exécutable en ligne de commande: vous pouvez lancer l’installation en mode silencieux depuis une Startup Task

Mais comment faire si votre application s’appuie sur un composant dont la procédure d’installation est plus complexe? Par exemple, si l’installeur ne peut pas être lancé en mode silencieux, ou s’il requiert un redémarrage?

C’est ici que le nouveau VM Role vient compléter cette infrastructure PAAS, en offrant un nouveau modèle, avec une différence de taille: ce n’est plus Windows Azure qui fournit la machine virtuelle préconfigurée, mais vous qui fournissez un disque dur virtuel (fichier VHD) contenant l’ensemble des composants que vous souhaitez exécuter. Vous pouvez donc préparer votre machine localement, sous Hyper-V, lancer tous les installeurs que vous souhaitez, en mode interactif, redémarrer douze fois, etc., sans contraintes. Une fois l’image prête et vos composants opérationnels, vous pouvez télécharger cette image dans Windows Azure et la référencer dans une définition de service, comme vous le feriez pour un Worker Role par exemple.

image

On comprend tout de suite ce que l’on perd par rapport aux rôles existants: la plateforme Windows Azure n’ayant plus la maîtrise de la machine virtuelle, elle ne pourra pas en prendre en charge la maintenance, et il vous reviendra donc de mettre à jour votre image avec les correctifs, d’installer les mises à jour, etc.

Mais alors qu’est-ce qu’on gagne? On gagne en flexibilité de déploiement, avec la possibilité d’héberger dans Windows Azure des composants qui ne rentrent pas vraiment dans les modèles Web/Worker.

Voici donc un cas d’usage: je souhaite construire une “ferme d’encodage” permettant d’encoder des fichiers vidéo; je souhaite utiliser Microsoft Expression Encoder et son SDK pour construire les serveurs d’encodage, et exécuter les instances dans Windows Azure. C’est un cas d’usage tout-à-fait adapté à Windows Azure, car je vais pouvoir modéliser mes serveurs d’encodage sous la forme de Worker Roles, dont les instances iront chercher les jobs à effectuer dans une Queue. Je pourrai augmenter ou diminuer le nombre d’instances d’encodeurs en fonction du volume de fichiers à traiter.

Il me faut donc installer Expression Encoder au sein du Worker Role; néanmoins cette installation pose un problème: pour s’exécuter sur un Windows Server 2008, Expression Encoder requiert l’activation de la fonctionnalité “Desktop Experience”, or, l’activation de cette fonctionnalité entraîne un redémarrage de la machine. Ce redémarrage, pendant la phase d’initialisation du rôle, est un cas d’usage nominal du VM Role: je ne peux pas installer mon pré-requis dans un Worker Role, je me rabats donc sur un VM Role.

Mise à jour: mon collègue Wade Wegner a trouvé un moyen d'activer la "Desktop Experience" via une tâche de démarrage, il est donc désormais possible de faire tourner Expression Encoder dans un Worker Role! Voici son article: Using Expression Encoder 4 in a Worker Role.

Il faut donc bien voir le VM Role, non pas comme la simple possibilité d’exécuter des machines virtuelles dans Windows Azure, mais comme une évolution du modèle PAAS élargissant le champ des possibles.