Accueil

Articles techniques

A propos de AzureGuru.org

Publier sur AzureGuru.org
 
   Accueil

13
"Full IIS" dans Azure, qu'en est-il exactement ?

Le SDK 1.3 supporte la fonctionnalité "Full IIS" dans les WebRoles qui permet, en théorie, de paramétrer dans Azure IIS comme sur un serveur dédié. Il existe en réalité quelques différences subtiles dans le comportement...



Full IIS

Dans les premières versions d'Azure, les WebRoles utilisaient un composant HWC "Hosted Web Core" en lieu et place de IIS (Internet Information Services). Dans la plupart des cas, HWC est suffisant pour répondre à des scénarios simples, mais les applications déployées étant de plus en plus complexes, la nécessité d'utiliser des fonctionnalités propres à IIS est devenue de plus en plus indispensable : multiples sites, application virtuelle, WCF hors http (via WAS), ...

La fonctionnalité "Full IIS" est maintenant accessible avec le "Windows Azure SDK 1.3".
Pour préciser que vous souhaitez utiliser IIS au lieu de HWC, la seul chose que vous devez faire, c'est ajouter une section <Sites> valide dans le fichier ServiceDefinition.csdef.
Visual studio créé dorénavant cette section par défaut et donc cela est transparent pour vous.
Il est donc possible de modifier cette section pour, par exemple, définir plusieurs sites, une application virtuelle ou un répertoire virtuel :

<Sites>
  <Site name="Web">
    <VirtualApplication name="VApp1" physicalDirectory="C:\Projects\VirtualApp1\" />
    <Bindings>
      <Binding name="HttpIn" endpointName="HttpIn" />
    </Bindings>
  </Site>
  <Site name="Site2" physicalDirectory="C:\Projects\Site2">
    <Bindings>
      <Binding hostHeader="site2.example.com" name="HttpIn" endpointName="HttpIn"/>
    </Bindings>
  </Site>
</Sites>

Différences entre HWC et IIS

Il existe des différences significatives selon que votre WebRole est hébergé dans Azure avec HWC ou IIS.

  • HWC : La méthode RoleEntryPoint (ainsi que la méthode dérivée OnStart du WebRole) et le site web lui-même s'exécutent dans le même process WaWebHost.exe
  • IIS : La méthode RoleEntryPoint s'exécute dans le process WaIISHost.exe alors que le site s'éxecute lui dans le process w3wp.exe.
Comme le code source du WebRole est issu d'un un même projet visual studio et compile dans une seule DLL, cela peut entrainer des comportements inattendus...

Lecture des fichiers de configuration :

Si vous avez des éléments de config dans le fichier de configuration web.config, votre application web pourra y accéder mais le code de RoleEntryPoint ne pourra pas car il ne s'exécute pas dans le même process que le site.

Pour accéder au fichier de config depuis RoleEntryPoint vous devez créer une copie de web.config dans un nouveau fichier nommé WaIISHost.exe.config.
Ne pas oublier de spécifier les propriétés de ce fichier comme "Copy to Output Directory" et "Copy Always".

Accès au membres Static et initialisation des delegates :

Toutes les données qui ont une portée de AppDomain ne seront plus partagées entre votre RoleEntryPoint et votre application web, en particulier les variables Static.

Attention si vous avez initialisé le CloudStorageAccount.SetConfigurationSettingPublisher dans le WebRole.OnStart !
Cette initialisation sera sans effet car dans un AppDomain différent... et donc l'appel CloudStorageAccount.FromConfigurationSetting lévera une exception.
Il faut donc prendre soin de tout initialiser dans le même AppDomain et la méthode Application_Start est appropriée pour initialiser le Publisher.
Vous pouvez aussi vous passer de l'initialisation d'un delegate en remplaçant :
      var storageAccount = CloudStorageAccount.FromConfigurationSetting("ConnectionString");
par
       var storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("ConnectionString")); 

Chaque site dans son propre App Pool :

Dans un unique WebRole il est donc possible de faire tourner plusieurs sites web ou application virtuelle. Chaque site ou application virtuelle s'exécute dans son propre Application Pool et sous son propre compte utilisateur. Cela permet d'envisager des scénarios complexes où, par exemple, plusieurs sites pourront avoir des droits d'accès différents vers des ressources locales ou des certificats. Pour faire cela, il suffit de spécifier une tâche au démarrage "startup task" pour élever les privilèges. Ceci peut s'effectuer en lançant un script PowerShell qui définit explicitement les privilèges souhaités.

Conclusion :

Les différences entre IIS "standard" et le IIS dans Azure sont subtiles et ne devraient poser aucun problème dans la plupart des cas, néanmoins, le portage d'applicatifs "on premise" vers Azure peut poser quelques problèmes de comportement... et la connaissance intime du fonctionnement de IIS dans Azure permet de les résoudre dans la plupart des cas.

 

Commentaires

Il n'y a encore aucun commentaire, soyez le premier...

Poster un commentaire

Only registered users may post comments.