Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Créer l'image serveur d'un rôle machine virtuelle dans Windows Azure

Mis à jour: mars 2011

[La fonction Rôle de machine virtuelle de Windows Azure sera mise hors service le 15 mai 2013. Après cette date, les déploiements du rôle de machine virtuelle seront supprimés. Pour poursuivre avec vos applications existantes, vous pouvez utiliser des machines virtuelles Windows Azure. Pour plus d'informations sur l'utilisation de machines virtuelles pour votre application, voir Moving from VM Role to Windows Azure Virtual Machines (Passer d'un rôle de machine virtuelle à des machines virtuelles Windows Azure).

Le rôle machine virtuelle pour Windows Azure est semblable aux autres rôles, car toutes les instances de rôle qui s'exécutent dans Windows Azure sont des ordinateurs virtuels qui exécutent une version du système d'exploitation Windows Server. Le rôle machine virtuelle se distingue dans la mesure où vous créez et gérez l'image du serveur. Pour ce faire, créez un disque dur virtuel de base, installez les composants d'intégration de Windows Azure, installez les applications et effectuez les personnalisations nécessaires, généralisez l'image, puis téléchargez-la sur Windows Azure.

Vous pouvez utiliser les technologies standard de création d'images système Windows pour créer votre image personnalisée de Windows Server 2008 R2. Par exemple, vous pouvez utiliser le Gestionnaire Hyper-V pour créer le disque dur virtuel de base qui est téléchargé vers Windows Azure.

Le disque dur virtuel de base contient le système d'exploitation, ainsi que les personnalisations du système d'exploitation et de vos applications. Vous pouvez utiliser le Gestionnaire Hyper-V pour créer le disque dur virtuel de base. Après avoir créé et préparé l'image serveur, le disque dur virtuel est téléchargé vers le portail de gestion de Windows Azure.

Les informations suivantes peuvent vous aider à en savoir plus sur les disques durs virtuels et les images serveur :

Dans la mesure du possible, il est recommandé de mettre tous les éléments nécessaires sur le disque dur virtuel de base. Vous pouvez utiliser un disque dur virtuel de différenciation pour appliquer des mises à jour et des correctifs limités. C'est à vous de choisir ce que vous voulez mettre sur le disque dur virtuel de base et le disque dur virtuel de différenciation. Dans la mesure où le disque dur virtuel de base et le disque dur virtuel de différenciation doivent être considérés comme un ensemble qui définit l'image serveur, conservez une copie locale du disque dur virtuel de base dans un emplacement sûr.

Les composants d'intégration de Windows Azure doivent être installés sur l'image serveur pour permettre le téléchargement du disque dur virtuel de base vers Windows Azure. Les composants d'intégration de Windows Azure s'exécutent sur chaque instance de rôle machine virtuelle créée à partir de l'image serveur. Ils gèrent l'intégration entre l'instance de rôle machine virtuelle et l'environnement Windows Azure.

Les composants d'intégration effectuent les tâches nécessaires pour intégrer le système d'exploitation de l'instance de rôle machine virtuelle à Windows Azure. Ils fonctionnent conjointement avec le programme d'équilibrage de charge pour communiquer des informations sur l'état des instances. Les composants initialisent également la machine virtuelle en installant des certificats et en créant des répertoires de ressources locales en fonction des paramètres de la définition du service.

Avec Windows Azure Connect, vous disposez d'une interface utilisateur simple pour configurer des connexions protégées par le protocole IPsec entre des ordinateurs ou ordinateurs virtuels de votre réseau local, et des instances de rôle s'exécutant dans Windows Azure. IPsec protège les communications sur les réseaux IP (Internet Protocol) via l'utilisation de services de sécurité de chiffrement. Pour plus d'informations sur l'utilisation de Windows Azure Connect, consultez Connexion d'ordinateurs locaux à des rôles Windows Azure.

Vous pouvez écrire un adaptateur qui s'exécute dans le cadre de l'installation ou du démarrage du système d'exploitation. Le diagramme suivant illustre le modèle de développement de l'adaptateur :

VMRoleDevelopmentModel

Vous avez deux options pour l'écriture d'un adaptateur :

  • Vous pouvez écrire un adaptateur qui s'exécute lors de l'étape de spécialisation. Cette étape de spécialisation a lieu lors de l'installation du système d'exploitation, une fois que l'image serveur a été téléchargée sur Windows Azure pour la première fois, ou après la réinitialisation d'une instance. Ce type d'adaptateur peut être écrit sans recourir à du code. Il est basé sur l'une des deux approches suivantes : exécution d'un script à partir du fichier de réponses ou écriture d'un fournisseur pour l'outil de préparation du système (sysprep). Pour plus d'informations, consultez Écriture d'un adaptateur qui s'exécute lors de l'installation du système d'exploitation.

  • Vous pouvez écrire un adaptateur correspondant à un service Windows qui démarre automatiquement à chaque démarrage du système d'exploitation. Ce type d'adaptateur peut être écrit en code managé ou natif. Il utilise l'API de runtime du service Windows Azure pour recueillir des données dynamiques de l'environnement Windows Azure. Pour plus d'informations, consultez Écriture d'un adaptateur qui s'exécute au démarrage du système d'exploitation.

Il existe une différence essentielle entre le déploiement d'applications Windows sur site et leur déploiement vers Windows Azure : en effet, lorsque vous téléchargez l'image serveur vers Windows Azure, les instances de rôle machine virtuelle créées à partir de cette image s'exécutent dans un environnement dynamique. Vous ignorez certaines informations majeures au cours de la phase de développement, par exemple l'adresse IP des instances de rôle machine virtuelle ou le nombre d'instances exécutées et leur mode de gestion. Le processus de développement d'un rôle machine virtuelle consiste à configurer les instances de rôle machine virtuelle et les logiciels installés sur ces dernières afin qu'ils s'exécutent et communiquent dans un environnement dynamique.

L'image serveur que vous téléchargez sur Windows Azure (avec le modèle de service) est appliquée pour permettre la création des instances de rôle machine virtuelle. Lorsqu'une instance de rôle machine virtuelle est mise en ligne, elle doit passer toutes les étapes nécessaires à la préparation de son exécution dans Windows Azure. Dans la plupart des cas, cela signifie qu'il faut configurer toutes les applications logicielles installées à l'aide des informations dynamiques de l'environnement, et les démarrer. Par exemple, il peut s'avérer nécessaire d'écrire des données recueillies à partir de l'environnement dynamique dans des fichiers de configuration de l'application logicielle.

Si une application écrit des données dans un répertoire de stockage local, l'instance de rôle machine virtuelle doit également configurer le répertoire afin de le rendre accessible à l'application. Lorsque l'image serveur est chargée pour la première fois afin de permettre la création de l'instance de rôle machine virtuelle, les ressources de stockage locales définies dans le modèle de service sont créées en tant que répertoires locaux. Le répertoire local associé à une ressource de stockage nommée est sécurisé par défaut. En d'autres termes, il est configuré pour être accessible uniquement au compte administrateur. Si votre application a besoin d'écrire dans le répertoire, l'instance de rôle machine virtuelle doit modifier les autorisations du répertoire afin de le rendre accessible aux comptes ayant un niveau de privilège inférieur.

Lorsque l'image serveur est déployée vers Windows Azure, elle est généralisée, état qui résulte de l'exécution de l'outil de préparation du système (sysprep) dans le but de préparer l'image sur site. Pour permettre au système d'exploitation de s'exécuter sur l'instance de rôle machine virtuelle de Windows Azure, une étape de spécialisation doit avoir lieu dans le cadre du processus d'installation. Les informations utilisées pour automatiser cette étape de spécialisation sont stockées dans le fichier de réponses installé à la racine de l'image serveur (c:\unattend.xml) par les composants d'intégration de Windows Azure.

En personnalisant le fichier de réponses lors de la création de l'image, vous pouvez exécuter un script qui est appelé lors de l'étape de spécialisation, une fois que l'image a été téléchargée vers Windows Azure. Pour plus d'informations sur la personnalisation du fichier de réponses, consultez les détails relatifs au Kit d'installation automatisée (Windows AIK).

Vous pouvez également écrire un fournisseur sysprep inclus dans l'image serveur. Un fournisseur sysprep étend l'outil sysprep afin d'inclure les fonctionnalités supplémentaires que vous définissez. Les composants d'intégration de Windows Azure prennent en charge l'outil sysprep, lequel permet d'effectuer l'étape de spécialisation qui termine l'installation de Windows lorsque l'instance de rôle machine virtuelle démarre pour la première fois. Pour plus d'informations sur l'écriture d'un fournisseur sysprep, consultez Guide de développement de fournisseur Sysprep pour Windows 7.

Un adaptateur de ce type ne s'exécute que pendant la première séquence de démarrage de l'instance. Il ne s'exécute pas lorsque l'instance redémarre. Ce type d'adaptateur présente une limitation, il ne peut pas répondre aux modifications apportées automatiquement aux paramètres de configuration du service. Si des modifications des paramètres de configuration doivent être appliquées à l'instance par l'adaptateur, l'opérateur doit réinitialiser manuellement l'instance pour exécuter l'adaptateur et appliquer les nouveaux paramètres. Si votre application repose sur des paramètres de configuration qui peuvent être amenés à changer pendant la durée d'existence de l'image serveur, écrivez plutôt votre adaptateur en tant que service Windows.

Vous pouvez écrire un adaptateur en tant que service Windows qui démarre automatiquement lorsque Windows démarre, et qui utilise l'API de runtime du service Windows Azure pour recueillir des données dynamiques de Windows Azure. Vous pouvez être amené à écrire un service Windows si vous avez besoin des informations d'adresses réseau de l'instance de rôle machine virtuelle actuelle ou d'autres instances de rôle en cours d'exécution dans votre service, si vous avez besoin d'écrire dans une ressource de stockage local, ou si vous avez besoin de lire les paramètres de configuration de service au moment de l'exécution ou d'y répondre quand ils changent.

Votre service Windows doit être un processus Windows 64 bits pour pouvoir utiliser l'API de runtime du service. Il peut être écrit en code managé ou en code natif. Pour plus d'informations sur l'API, consultez Windows Azure Managed Library Reference et Windows Azure Native Library Reference.

Vous pouvez appeler l'API de runtime du service uniquement à partir d'un processus qui s'exécute sous un compte Administrateur ou LocalSystem. Cette restriction vous permet d'avoir la garantie que votre service est sécurisé par défaut, car elle élimine le risque qu'un processus ayant un niveau de privilège inférieur utilise l'API de runtime du service pour lire les paramètres de configuration du service.

Votre service Windows doit être configuré pour démarrer automatiquement en même temps que Windows. Il doit implémenter les méthodes de cycle de vie de la classe ServiceBase, notamment OnStart et, si une séquence d'arrêt est nécessaire, OnStop ou OnShutdown. L'exécution de votre code de démarrage doit être terminée avant le retour de la méthode OnStart. Toutes les séquences d'arrêt requises par votre service Windows doivent être terminées avant le retour de OnStop ou OnShutdown. Pour plus d'informations sur l'écriture de services Windows, consultez Applications de service Windows.

Après le démarrage automatique de tous les services configurés à cet effet, y compris votre adaptateur, Windows Azure détermine que l'instance est prête à recevoir le trafic en provenance du programme d'équilibrage de charge. C'est la raison pour laquelle il est important de vous assurer que votre adaptateur a effectué toutes les tâches nécessaires à la préparation de l'instance de rôle machine virtuelle et des logiciels qu'elle exécute, avant le retour de la méthode OnStart. L'instance de rôle machine virtuelle doit être prête entre le moment où la séquence de démarrage prend fin et le moment où la séquence d'arrêt commence, sauf si vous excluez explicitement l'instance en affectant à son état la valeur Busy. Pour ce faire, ajoutez un gestionnaire d'événements à l'événement StatusCheck. Lorsque l'événement se déclenche, la méthode SetBusy peut être appelée sur l'objet d'argument d'événement. Vous pouvez également utiliser l'applet de commande PowerShell Set-RoleInstanceStatus pour modifier l'état de l'instance de rôle machine virtuelle.

Après avoir installé les composants d'intégration de Windows Azure, installez vos applications et apportez les modifications nécessaires à la configuration du système d'exploitation. Le cas échéant, installez l'agent Windows Azure Connect, créez et installez un adaptateur, puis préparez l'image à télécharger.

Pour permettre au disque dur virtuel d'être téléchargé correctement vers Windows Azure, vous devez généraliser l'image serveur à l'aide de la commande sysprep. Pour plus d'informations sur l'utilisation de Sysprep, consultez la page d'introduction à l'utilisation de Sysprep. Pour plus d'informations sur le téléchargement du disque dur virtuel, consultez Télécharger un disque dur virtuel pour un rôle machine virtuelle dans Windows Azure.

Voir aussi

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

Afficher:
© 2014 Microsoft. Tous droits réservés.