creo ignem

WebDeploy et Azure

Cet article est (principalement) un résumé d’un billet de Ryan Dunn, datant d’il y a quelques mois.

Si vous développez sur Azure, et que vous y faites tourner des WebRoles, vous avez dû vous lamenter sur la longueur des déploiements. Si cela ne pose pas vraiment de problème lors de la phase de production, il arrive toujours un moment où “l’émulateur” fourni dans le SDK n’est plus suffisant et où l’on a besoin de pouvoir tester ses déve-loppements sur un véritable environnement Azure. Patienter entre 15 et 30 minutes après chaque modification pour en voir le résultat n’est pas particulièrement une bonne idée, surtout quand on est en train de finaliser une version.

Depuis la version 1.3, et l’ajout du support complet de IIS, il existe une autre solution : en utilisant le protocole WebDeploy que vous utilisez – peut-être  – déjà pour vos déploiements Web habituels. Avant de vous expliquer comment faire, précisons tout de même que cela n’est prévu que pour des environnements de test, et que ce n’est absolument pas prévu pour votre version de production et que vous devrez respecter certaines conditions pour que cela fonctionne :

• votre rôle devra être déployé sur une seule et unique instance
• vous devrez avoir activé l’accès à distance pour ce rôle (les identifiants du compte RemoteAccess seront utilisés par WebDeploy)

Une fois ces quelques limites connues, le principe est extrêmement simple, grâce à un petit add-in réalisé par Ryan Dunn :

• Téléchargez le fichier ZIP qu’il met à disposition sur Skydrive
• Décompressez le dans le dossier %ProgramFiles%\Windows Azure SDK\v1.3\bin\plugins\. Vous devriez déjà trouver dans ce dossier des plugins pour RemoteAccess et Diagnostics
• Editez ensuite le fichier ServiceDefinition.csdef de votre projet Azure pour ajouter une nouvelle ligne dans la section Imports, afin qu’elle ressemble à ceci :

  <Imports>
    <Import moduleName="RemoteAccess" />
    <Import moduleName="RemoteForwarder" />
    <Import moduleName="WebDeploy" />
  </Imports>

   

• Déployez votre rôle comme d’habitude.

Une fois ces quelques étapes faites, vous devriez avoir une instance active de votre rôle et le service d’administration à distance activé sur celui-ci. Il ne reste plus qu’à s’en servir :

• Cliquez sur “Publier” pour le projet web concerné. Attention, ne faites pas “Publier” sur le projet Azure, mais bien sur le projet Web, sinon vous êtes repartis pour un tour de déploiement complet.
• Dans l’écran de publication, choisissez la méthode WebDeploy, saisissez le nom DNS de votre service dans l’Url du service
• les informations de connexion sont celles de votre utilisateur RemoteAccess
• Cochez la case “Autoriser des certificats non approuvés”
• pour le champ “site/application”, c’est un tout petit peu plus compliqué : il vous faudra le nom de l’instance, que vous trouverez dans le portail d’administration Azure :

  ainsi que le nom de votre site dans cette instance, que vous trouverez dans le ServiceDefinition.csdef :

  <Sites>
    <Site name="Web">
      <Bindings>
        <Binding name="HttpIn" endpointName="HttpIn" />
      </Bindings>
    </Site>
  </Sites>

   

  Il ne vous reste plus qu’a combiner les deux avec un “_” pour obtenir le nom de votre application, dans l’exemple ci-dessus nous aurions donc le nom de site/application “ECommerceSite_IN_0_Web”

Voila ! Avec ces quelques manipulations, vous pourrez effectuer des déploiements BEAUCOUP plus rapidement. Pour terminer, sachez aussi qu’en cas de déplacement de votre instance (par exemple en cas de maintenance du serveur physique sur lequel vous êtes hébergé), votre rôle sera, bien entendu, redéployé à partir de l’archive d’origine et que tous vos déploiements par WebDeploy seront perdus.