Windows Phone 7 : LA mise à jour … enfin

Microsoft vient d’annoncer la diffusion de la mise à jour de Windows Phone 7 pour les heures/jours à venir. Cette update ( Version de l’OS : 7.0.7390.0) contiendra les améliorations suivantes :

• support du Copier/Coller
• chargement plus rapide des applications (et notamment des jeux )
• Markeplace : recherche améliorée, seuil de téléchargement, souplesse du règlement, …
• Visualisation de l’adresse MAC (pour simplifier la configuration des Box et routeur)
• Corrections diverses sur Outlook , intégration Facebook, stabilité des modes photos/vidéos
• plus quelques améliorations internes à l’OS

Pour plus de détails : http://www.microsoft.com/windowsphone/en-us/howto/wp7/basics/update-history.aspx 

Voilà patienter gentiment que votre Windows Phone 7 ou le logiciel Zune vous informe de la disponibilité pour vos téléphones.

QuidMind sera présent à la conférence Innorobo à Lyon du 23 au 25 Mars 2011 – “du Servo au cerveau”

En partenariat avec Microsoft, QuidMind sera présent lors de la conférence Innorobo à Lyon du 23 au 25 Mars 2011. Venez y découvrir nos travaux de R&D sur la thématique du cloud dans un environnement robotique « Clorofeel, the social robot » basé sur les technologies Microsoft .Net, Windows Azure, AppFabric Service Bus, Windows Phone 7

Liens web :

• http://www.quidmind.com
• http://www.innorobo.com
• http://www.facebook.com/pages/Clorofeel-the-social-robot/211452818868673
• http://www.facebook.com/pages/QuidMind/155297214489708
• http://www.facebook.com/pages/Nicolas-Clerc/143318772400035
• http://www.microsoft.com/france/mstechdays/showcase/player.aspx?uuid=af0837e8-0778-433e-8e0d-febf72d6f4a1&parcours=TD11_DEV_ROBOTIQUE

Déployer votre propre Machine virtuelle dans Windows Azure (2/2)

Le billet précédent (https://nicolasclerc.wordpress.com/2011/02/22/dployer-votre-propre-machine-virtuelle-dans-windows-azure-12/) vous a expliqué comment créer votre(vos) .VHD et les télécharger vers Azure.

Une fois ce téléchargement terminé, la console d’administration d’Azure doit ressembler à cela :

Quelques statistiques post upload :

– mon VHD de base préparé fait environ 8go , l’upload via une ligne ADSL situé a 3500m du central ,devrait durer plus de 1jour, 18h .

Au final, 1j et 8h auront “suffi”.

C’est dans ces cas là que l’on apprécie les connexions de type fibre optique. Ceci dit, il apparait clairement que la phase de test local de vos VM préalablement à l’upload est extrêmement importante. Il est en effet totalement inenvisageable de tester l’ensemble une fois la VM déployer et de retenter plusieurs upload en cas de soucis !

En cas de soucis pendant l’envoi des VHD, la commande csupload effectue une reprise par rapport au dernier morceau de VHD transmis. il suffit de relancer la commande pour que le transfert reprenne au point où il s’était arrêté.

Lors de mes 2 uploads, le transfert a généré une erreur a la fin du transfert. Les VHD sont restés en état ‘pending’. Il a suffit de relancer la commande csupload pour que leurs statuts soient corrigés et prennent la valeur ‘commited’.

 

Liaison VHD de Base / VHD Différentiel

Notre machine virtuelle sera instanciée à partir d’un disque différentiel (il ne contient que les différences par rapport au disque de base).

Le fait d’avoir téléchargé nos 2 VHD sur le repository Azure n’a pas recréé le lien logique entre le VHD différentiel et son VHD de base. Il faut le créer explicitement à l’aide de la commande suivante :

csupload Set-Parent -child SPECIFIQUEAzureDIFFW2008R2EN.vhd -parent ImageDeBase.vhd

 

L’affichage de la console d’administration se met à jours pour visualiser cette dépendance :

 

Il nous reste maintenant à créer un rôle Azure afin de lancer l’exécution de notre VM au sein des datacenters Azure. Pour ce faire, on aura besoin de Visual Studio 2010avec l’extension Windows Azure Tools for Visual Studio et bien entendu du SDK Azure v1.3 (mais qui est installé en même temps que les tools).

 

Création d’un projet Windows Azure

L’envoi des fichiers .VHDs dans Azure est une condition nécessaire mais pas suffisante pour démarrer votre VM dans Azure. Il faut créer un projet de type Windows Azure avec Visual Studio 2010 :

Pour le moment, on laisse le projet vide (ne pas ajoutez de service à partir du Wizard).

On obtient un projet Azure … sans service (ce qui est – vous conviendrez – d’une utilité toute relative ).

Nous allons devoir ajouter maintenant un rôle de type “VMRole”.

 

Point important : Le SDK 1.3 (et les tools associés) possède d’emblée les fonctionnalités pour créer des rôles de type “VMRole” dans un projet Windows Azure, mais cette fonctionnalité est désactivée lors de l’installation des tools. Lorsque vous aurez été accepté dans le programme de Beta VMRole vous recevrez par email un lien permettant de télécharger un fichier .reg qui mettra la base de registre à jour pour activer le support des VMRole dans Visual Studio.

 

Un clic droit sur le dossier “Roles” vous permet de créer un nouveau rôle … sélectionnez “New Virtual Machine role”.

Nommez correctement votre rôle : dans cet exemple : “VmDemoBlog”

Dans la fenêtre des propriétés du rôle qui s’ouvre automatiquement, onglet “Virtual Disk”, sélectionnez (ou ajoutez) le compte de stockage utilisé pour stocker votre VM dans Azure.

Sélectionner le VHD différentiel dans la liste déroulante :

 

Dans l’onglet “Configuration”, sélectionnez le type et le nombre d’instance de la VM que vous souhaiter lancé. (les instances de type small sont limité à 35Go : http://msdn.microsoft.com/en-us/library/gg465391.aspx). Si vous souhaitez lancez plusieurs instances il faudra vous assurer que vos applications sont compatibles avec des instances multiples … et bien entendu que vous possédez les licences en nombres suffisant.

Dans l’onglet “EndPoints”, nous allons configurer les points d’entrées/sorties que l’on souhaite rendre accessible sur notre VM. Dans notre exemple nous allons autoriser l’accès au port http/80 (qui sera géré par IIS).

 

Sauvegarder et fermer la fenêtre configuration du Rôle. Cette fenêtre à mis à jour les fichiers .cscfg et .csdef.

Ouvrez le fichier .cscfg (Cloud Service ConFiGuration) :

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="QuidMindVMRoleDemo" 
                      xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
                      osFamily="1" osVersion="*">
  <Role name="VmDemoBlog">
    <Instances count="1"  />
    <OsImage href="ImageDeBase.vhd" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
               value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>

    <OsImage href="SPECIFIQUEAzureDIFFW2008R2EN.vhd" />
  </Role>
</ServiceConfiguration>

Par défaut, Visual Studio configure le role comme étant basé sur un Windows Server 2008 SP2. Dans notre cas, notre VM est basé sur Windows Server 2008 R2. Pour assurer une intégration optimale de notre VM dans Azure il convient de préciser la version d’OS en affectant la valeur 2 à l’attribut osFamily (pour plus de détail sur le schéma XML : http://msdn.microsoft.com/en-us/library/ee758710.aspx ) :

<ServiceConfiguration serviceName="QuidMindVMRoleDemo" 
                      xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
                      osFamily="2" osVersion="*">

 

Par curiosité, on peut regarder le fichier .csdef (Cloud Service DEFinition) qui la définition de notre service.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="QuidMindVMRoleDemo" 
                   xmlns=http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition>
  <VirtualMachineRole name="VmDemoBlog" size="Medium" >
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="IIS" protocol="http" port="80" />
    </Endpoints>
  </VirtualMachineRole>
</ServiceDefinition>

 

Comme la plupart des machines virtuelles, la notre sera administrée à distance via une connexion Terminal Server. Même si l’administration à distance est activée dans notre VM, Windows Azure ne permettra pas une connexion directe à nos instances sans une configuration du service.

Cette configuration s’effectue dans les fichiers .CS*, mais il est plus simple d’utiliser le wizard de publication pour activer la connexion à distance.  Faites un clic droit sur le projet et sélectionnez “Publish”. Dans la fenêtre qui apparait cliquez sur le lien “Configure Remote Desktop connection …”.

 

Dans la fenêtre “Remote Desktop configuration” saisissez les informations suivantes :

• cochez “Enable connections for all roles”
• le certificat à utiliser pour sécuriser la communication. Pour mieux gérer la sécurité, il est pertinent d’utiliser un certificat distinct de celui utilisé pour la commande csupload. (L’utilisateur de la VM n’est pas forcement l’administrateur qui a gérer le déploiement).
• le nom d’utilisateur et le mot de passe à utiliser pour se connecter aux instances.
• Eventuellement, modifier la date de péremption des informations de connexion.

 

Cliquez sur OK pour valider les informations RDP puis fermer la fenêtre “Deploy Windows Azure project”. Par curiosité, ouvrez le fichier .CSCFG, vous y retrouverez la configuration lié à l’utilisation du bureau à distance.

Le fichier .CSDEF importe 2 nouveaux modules :

 

Le projet Azure est maintenant paré à être déployé sur Azure.

Faites un clic droit sur le projet et sélectionnez “Publish”. Cochez “Create Service Package only”. Visual Studio crée la package de déploiement et ouvre le dossier contenant les fichiers à déployer sur Azure (le .cspkg et le .cscfg).

Connectez vous à la console d’administration Azure ( http://windows.azure.com ).

Une fois identifié, il fait créer un nouvel “Hosted Service”. Cette étape n’est possible qu’une fois l’envoi des .VHDs terminé (statut “Commited” ).

Cliquez sur le bouton “New Hosted Service” puis saisissez les informations demandées :

• sélectionnez une souscriptions activée pour la Beta VMRole
• Le nom du service
• l’url de votre déploiement
• Le datacenter qui hébergera vos VM : sélectionnez le même que lors de l’upload de vos VM.
• La cible du déploiement. ( Production dans notre cas).
• Le nom du déploiement
• Les fichiers .CSPKG et .CSCFG généré par Visual Studio.

Cliquez sur le bouton “Add Certificate” et sélectionner le certificat que vous souhaitez utiliser pour la connexion bureau à distance, et saisissez le mot de passe attaché au certificat.

Cliquez sur OK pour valider l’ajout du certificat, puis sur OK pour créer le nouveau service.

La console d’administration vous avertie qu’un soucis potentiel a été détecté : Cet avertissement est lié au nombre d’instance demandé : 1. En effet il n’y aura pas de redondance et donc le contrat de qualité de service SLA d’Azure ne pourra pas être appliqué (ce qui n’est pas gênant dans notre cas, mais pensez à évaluer cette situation dans vos projets).

Cliquez sur “Yes”. Azure commence le déploiement du VMRole et démarre les instances demandées. (cette étape peut prendre quelques minutes).

L’onglet “VM Images” montre que le VHD est en cours d’utilisation :

L’instance VM passe par différents statuts, notamment : “Starting Host”, “Setting up Windows for first use”, … et enfin … “Ready”.

 

 

Utilisation de notre VM

 

Premier test : le service HTTP

Nous avons déclarer le port 80 comme point d’accès (Endpoint) à la VM  : lancer IE et tester l’url associé au VMRole ( http://demovmroleblog.cloudapp.net/ dans le cas de ce billet ) … oh magie … :

 

 

Deuxième test : la connexion RDP

Via la console d’administration d’Azure, sélectionner l’instance sur laquelle ont souhaite se connecter, puis cliquez sur le bouton “Connect” (ce bouton n’est actif que si les connexions RDP ont été activé dans la définition du rôle).

 

Acceptez l’ouverture du fichier .rdp qui lancera la client RDP de votre machine avec la bonne configuration pour arriver sur l’instance visée,

 

saisissez les informations de connexion paramétrées précédemment, puis acceptez le certificat associé à l’instance de la VM :

 

Et enfin … le bureau de notre VM qui tourne dans un datacenter Azure :

 

 

Cout et facturation

 

Petit rappel : l’utilisation de la plateforme Azure peut être générateur de cout financier (transfert de données, stockage, calcul). si vous n’êtes pas sur de vous n’entamez pas d’essai inutile et vérifiez au préalable les conditions de facturation de votre abonnement Azure.

 

L’utilisation de ressources Azure pour la rédaction des 2 billets concernant les VMRole à générer des couts (certes infimes, mais qui sont quand même apparu sur la facture : <1€). Ces couts concernent :

• Bande passante réseau : Envoi des fichiers VHD sur le datacenter (le forfait mensuel de mon abonnement MSDN à même été dépassé).
• Bande passante réseau : utilisation de la connexion bureau à distance sur la VM
• Temps CPU Azure sur un VM Rôle (non facturé pendant la période de CTP)
• Repository de VHD pour le stockage des VHD (non facturé pendant la période de CTP)

 

Et voila, maintenant à vous de ‘jouer’.