IIS

En ligne avec IIS 7.0

Fergus Strachan

En un coup d'œil :

• Déploiement d'IIS 7.0 dans un environnement de batterie de serveurs Web
• Améliorations des performances et de la sécurité
• Migration d'applications Web ASP.NET de IIS 6.0 vers IIS 7.0
• Migration d'applications Web PHP vers IIS 7.0

Sommaire

Attention, installez, testez !
Mon installation de test
Améliorations importantes pour les administrateurs informatiques
Architecture IIS
Modes Intégré et Classique
Modules et fonctionnalités
Migration d'applications Web
Conclusion

L'équipe IIS de Microsoft affirme qu'Internet Information Services (IIS) 7.0 représente la publication la plus importante dans l'histoire d'IIS. Cette version établit de nouvelles normes, offre d'importantes améliorations et

propose de nouvelles capacités de consolidation des environnements Web. IIS 7.0, qui est inclus avec Windows Server® 2008 et Windows Vista® SP1, alimente déjà Microsoft.com, et plusieurs entreprises d'hébergement Web ont déjà commencé à fournir un hébergement IIS 7.0 aux concepteurs et développeurs de sites Web qui souhaitent migrer leurs applications Web existantes vers la nouvelle plate-forme de serveur Web.

Dans cet article, j'examinerai les améliorations d'IIS 7.0 qui importent le plus aux professionnels de l'informatique et aborderai ensuite dans les détails la migration d'applications Web ASP.NET et PHP. Toutefois, je voudrais tout d'abord définir un laboratoire de test qui ressemble à un environnement de production de base.

Il s'agit là d'une étape importante. Avant de déployer IIS 7.0 vers vos serveurs de production, vous devez effectuer des tests approfondis dans un environnement de laboratoire pour vous assurer que vos applications Web s'exécutent facilement sur le nouveau serveur Web.

Attention, installez, testez !

Mon laboratoire de test inclut des systèmes exécutant Windows Server 2003 et IIS 6.0 qui hébergent des applications ASP.NET de même que des serveurs exécutant la distribution Ubuntu 7.10 Linux et Apache HTTP Server 2.2 qui hébergent des applications Web de type PHP. Mon principal objectif est de déployer Windows Server 2008 sur des systèmes de préparation et production puis effectuer la transition d'applications Web complexes pour remplacer IIS 6.0 et des instances Apache par IIS 7.0.

Je dispose de deux applications Web clés : DotNetNuke 4.7 et osCommerce 3.0a4. DotNetNuke est une infrastructure d'application Web fondée sur ASP.NET 2.0 et Microsoft® SQL Server®. L'autre application (osCommerce) est la toute dernière version alpha d'une solution e-commerce complète fondée sur PHP et MySQL. Plaçons donc ces applications avancées sur IIS 7.0 !

Je voudrais souligner que mon intention n'est pas de comparer des versions, produits ou plates-formes logiciels. Il existe, toutefois, un certain nombre d'avantages à standardiser sur Windows Server 2008 et IIS 7.0 que je dois signaler, notamment le fait que la complexité administrative est réduite et que vous pouvez réduire le nombre de serveurs Web que vous exécutez.

La figure 1 montre une présentation du laboratoire de test que j'utilise pour cet article. Si vous voulez suivre mes explications dans votre propre environnement de test, vous trouverez des liens vers les composants logiciels nécessaires de même que des instructions détaillées sur l'installation dans la documentation associée disponible dans la section de téléchargements de codes du site Web de TechNet Magazine.

Figure 1 L'environnement de test pour le déploiement d'IIS 7.0 (cliquer sur l'image pour l'agrandir)

Notez qu'au moment où je rédigeais la conclusion de cet article, Microsoft a publié un outil de ligne de commande (MSDeploy.exe) dont le but est d'aider les utilisateurs à déployer, synchroniser et migrer les applications Web vers IIS 6.0 et 7.0. Je vous conseille d'essayer cet outil. Vous trouverez des informations détaillées à ce sujet sur le blog de l'équipe de déploiement Web de Microsoft sur go.microsoft.com/fwlink/?LinkId=118272.

Mon installation de test

Au moment où je rédigeais cet article, Windows Server 2008 était toujours en version préliminaire et je n'ai donc pas remplacé Windows Server 2003 sur le contrôleur de domaine ou les serveurs de base de données. Avec la version officielle de Windows Server 2008, vous voudrez peut-être envisager de migrer également votre infrastructure Active Directory®. La migration des bases de données SQL Server® 2005 et MySQL vers SQL Server 2008 n'entre pas non plus dans le cadre de cet article.

J'ai déployé SQL Server 2008 sur mon serveur intermédiaire principalement parce que cette opération est plus aisée que l'installation de SQL Server 2005 avec Service Pack 2. DotNetNuke n'a eu aucun problème à s'exécuter avec une base de données SQL Server  2008. En outre, l'installation de MySQL 5.0 sur Windows Server 2008 s'est faite sans aucune complication.

IIS 7.0 est disponible sur Server Core, mais je n'ai pas utilisé d'installation Server Core en raison des certaines exigences associées mes tests. Mon serveur intermédiaire nécessitait une installation complète parce qu'il s'agissait de mon système de test principal. Par ailleurs, Microsoft .NET Framework n'est pas disponible sur Server Core.

PHP s'exécute convenablement sur Server Core, mais mon objectif est de consolider les applications ASP.NET et PHP et il n'est donc pas question d'utiliser Server Core. Tant que .NET Framework n'est pas pris en charge sur Server Core, vous devrez exécuter une installation complète pour prendre en charge les applications ASP.NET. Pour obtenir des instructions détaillées sur l'installation d'un environnement de test, consultez le fichier 01_install_testlab.htm de la documentation associée.

J'ai choisi d'effectuer une installation propre de Windows Server 2008 (au lieu de mettre à niveau les serveurs existants). L'installation propre facilite notamment l'implémentation d'un scénario de migration tel que celui de la figure 2. La stratégie sous-jacente est de laisser les batteries de serveurs Web existantes s'exécuter jusqu'à ce que tous les composants d'applications Web appropriés aient été testés sur le serveur intermédiaire et transférés à la nouvelle batterie de serveurs IIS 7.0.

Figure 2 Passage à IIS 7.0 (cliquer sur l'image pour l'agrandir)

Vous pouvez déplacer toutes les applications Web existantes d'un seul coup ou progressivement, selon la complexité de votre environnement. Pour chaque application ou site Web, après avoir exécuté un dernier test d'acceptation sur la nouvelle batterie de serveurs Web, vous pouvez effectuer la transition en modifiant les enregistrements DNS appropriés afin de diriger les navigateurs vers la nouvelle batterie de serveurs Web IIS 7.0. Ceci permet de minimiser les pertes de temps et les interruptions.

Améliorations importantes pour les administrateurs informatiques

MSDN® Magazine comprend un excellent article de Mike Volodarsky intitulé « Exploration du serveur Web pour Windows Vista et autres fonctionnalités » (disponible sur msdn2.microsoft.com/magazine/cc163453.aspx) qui vous permet de prendre connaissance rapidement des améliorations d'IIS 7.0.

Vous trouverez un autre document dans le blog de l'équipe Microsoft.com. Il s'intitule « The Tasty Morsels Found in Dogfood » (disponible sur go.microsoft.com/fwlink/?LinkId=117436). Cet article résume les premières expériences d'IIS 7.0 des membres de l'équipe. En gros, ils ont classé les principales améliorations comme suit :

1. Installation simplifiée.
2. Superbe compatibilité.
3. Plus de métabase.
4. Configuration centralisée par l'intermédiaire du fichier applicationHost.config placé sur un partage UNC.
5. Configuration déléguée au moyen de fichiers web.config dans les annuaires d'applications.
6. Outils de gestion améliorés.
7. Suivi des requêtes en erreur.
8. Filtrage des requêtes sans avoir besoin d'URLScan.
9. Disponibilité de la synchronisation de contenu simplifiée grâce aux partages UNC.

Mise en cache de la sortie de contenu dynamique.

L'installation simplifiée m'intéresse particulièrement. Dans son billet de blog, l'équipe Microsoft.com montre comment déployer toutes les fonctionnalités d'IIS 7.0 (ou, bien sûr, juste celles que vous voulez) avec une seule ligne de commande. Je n'ai pas hésité à intégrer cette approche dans mes instructions d'installation du laboratoire de test, avec la ligne de commande affichée à la figure 3.

Il est vrai que cette commande est plutôt longue. (Si vous voulez la copier, je vous conseille de la copier et coller du site Web de TechNet Magazine au lieu de la retaper à la main). Bien que cette commande place tous les modules disponibles sur l'ordinateur IIS 7.0, elle n'inclut pas PHP. IIS 7.0 n'inclut pas PHP et l'idée de télécharger et d'installer des packages Debian sur Internet n'est pas connue de Windows® Package Manager (pkgmgr.exe). C'est là qu'intervient le Kit d’installation automatisée (Windows AIK).

Figure 3 Déploiement de fonctionnalités IIS 7.0 avec une seule ligne de commande

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-­WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (<a href=\"https://blogs.technet.com/mscom\" xmlns=\"http://www.w3.org/1999/xhtml\">blogs.technet.com/mscom</a>).

Avec AIK, vous pouvez créer un DVD d'installation personnalisé pour Windows Server 2008 qui inclut IIS 7.0 et PHP 5. Vous pouvez également inclure MySQL, des fichiers d'application Web et tout autre composant dont vous avez besoin pour votre déploiement. Tous les composants peuvent faire partie de votre Installation Windows Server 2008, ce qui vous permet d'appliquer des personnalisations régulièrement sur tous vos serveurs Web. Vous n'avez pas besoin d'utiliser des lignes de commande ou de modifier des fichiers de configuration.

Vous pouvez même créer un DVD personnalisé pour les installations sans assistance. Le kit AIK inclut la documentation et les outils servant à créer un fichier AutoUnattend.xml que vous placez ensuite dans le dossier racine du DVD. Le fichier Deployment.htm de l'image personnalisée de la documentation associée propose des instructions détaillées.

Nombreux sont les administrateurs qui reconnaissent également l'importance clé de cette compatibilité. Au départ, je m'attendais à quelques problèmes de compatibilité avec DotNetNuke et osCommerce, mais la transition à IIS 7.0 s'est faite sans heurt, malgré le fait que ces applications Web incluaient toutes deux des fonctionnalités avancées telles que l'authentification de formulaires et des URL compatibles avec les moteurs de recherche.

Avec DotNetNuke, je n'ai rencontré de problème que lorsque je suis passé à un scénario de batterie de serveurs Web complexe avec partage de contenu UNC sur une plate-forme 64 bits. Toutefois, ce problème n'était pas très sérieux. En fin de compte, cette compatibilité améliorée vous permet de passer moins de temps à exécuter vos applications Web sur IIS 7.0.

Si vous rencontrez les problèmes de compatibilité avec vos applications Web, la prise en charge de diagnostic et de suivi intégrée deviendra rapidement une de vos nouvelles fonctionnalités préférées. Les informations de diagnostic détaillées sont très importantes et les solutions suggérées sont utiles et efficaces.

La figure 4 montre les informations de diagnostic que vous obtenez lorsque vous exécutez DotNetNuke 4.7 sur IIS 7.0 en mode intégré. Dans cet exemple, il existe trois options (affichées dans la section « Choses à essayer »). Modifier l'application de sorte à prendre en charge le mode intégré est probablement le meilleur choix pour les développeurs DotNetNuke. Ignorer l'erreur n'est probablement pas une bonne idée. J'aime le troisième choix, celui qui consiste à activer le mode classique en faisant passer l'application Web au .NET AppPool classique, car je souhaite exécuter DotNetNuke 4.7 sans aucun changement sur IIS 7.0.

Figure 4 Informations de diagnostic pour DotNetNuke exécuté en mode intégré (cliquer sur l'image pour l'agrandir)

Architecture IIS

Vous pourriez vous demander ce que signifient ces modes intégrés et classiques et pourquoi ils ont un effet sur l'application ASP.NET (DotNetNuke) mais pas sur l'application PHP (osCommerce). Pour bien comprendre ce phénomène, vous devez tout d'abord jeter un coup d'œil sur l'architecture d'IIS 7.0. Les versions précédentes intègrent le service d'exécution ASP.NET au serveur Web de base, principalement par le biais d'une extension ISAPI (aspnet_isapi.dll). IIS 7.0, d'un autre côté, permet de brancher les modules ASP.NET directement sur le serveur Web de base par l'intermédiaire d'un module HTTP de niveau global appelé ManagedEngine qui charge la DLL de support d'ASP.NET (webengine.dll) dans le pipeline de traitement de requêtes d'IIS 7.0.

Les modules natifs utilisent l'API de base du serveur Web d'IIS pour s'inscrire à des événements spécifiques dans le pipeline tels que BeginRequest, Authenticate­Request, AuthorizeRequest et Execute­RequestHandler. En outre, ManagedEngine fournit la prise en charge nécessaire pour intégrer les modules ASP.NET au pipeline de requêtes. Avec cette nouvelle architecture, IIS 7.0 peut invoquer des modules natifs et ASP.NET à n'importe quelle étape du traitement de requêtes quel que soit type de contenu demandé.

En guise d'exemple, considérons l'authentification utilisateur ASP.NET. Dans IIS 6.0, il est possible pour un module HTTP basé sur ASP.NET de s'inscrire à des événements On­Authenticate (tels que Forms­Authentication.OnAuthenticate et Win­dows­Authentication.OnAuthenticate) pour définir l'identité de l'utilisateur dans le HttpContext actuel. Ceci est idéal dans le service d'exécution d'ASP.NET, mais vous ne pouvez pas utiliser ce code ASP.NET pour protéger des ressources exposées par le biais d'une application Web de type PHP.

Conformément à sa configuration scriptmap, IIS 6.0 transfert des requêtes de types de contenu ASP.NET à aspnet_isapi.dll mais il ne transfert pas de requête de types de contenu PHP à l'extension ISAPI pour ASP.NET. Après tout, ASP.NET ne traite pas le code PHP, mais cela signifie également que le code d'authentification ASP.NET ne s'exécute pas si une page PHP est demandée. Ainsi, avec IIS 6.0, vous devez dupliquer la logique d'authentification parce que les applications PHP doivent implémenter leurs propres mécanismes d'authentification.

IIS 7.0 utilise un modèle de traitement piloté par les événements qui prend en charge le mélange et la correspondance de modules individuels dans le pipeline de requêtes. Parmi les autres composants d'IIS 7.0, notons les modules WindowsAuthentication et FormsAuthentication gérés qui déclenchent des événements OnAuthenticate lorsque le pipeline de requêtes lance l'événement AuthenticateRequest. Désormais, un module natif tel que Request­FilteringModule or IpRestrictionModule peut traiter l'événement BeginRequest pour rejeter des requêtes critiques dès que possible, puis exécuter le code d'authentification ASP.NET personnalisé à l'événement AuthenticateRequest et faire en sorte que FastCgiModule exécute le moteur de script PHP (php-cgi.exe) à l'événement Execute­RequestHandler pour traiter les pages PHP.

Le résultat de cette architecture intégrée est que les développeurs Web n'ont pas à dupliquer le code pour implémenter une logique métier courante. Vous pouvez utiliser le code d'authentification ASP.NET personnalisé pour protéger toutes vos ressources IIS, y compris les applications PHP. En outre, vous pouvez exécuter d'autres tâches de pré et post-traitement par l'intermédiaire des modules ASP.NET, notamment la réécriture des URL, le suivi personnalisé et la journalisation des erreurs.

Modes intégrés et classiques

L'effet secondaire créé par cette nouvelle architecture est que les applications ASP.NET existantes pourraient nécessiter des modifications de code et configuration qui devraient être exécutées par des développeurs d'applications afin d'éviter de créer des conflits de modules dans le pipeline de requêtes. Toutefois, si ne vous pouvez pas immédiatement migrer une application Web existante, vous pouvez activer le mode classique dans le pool d'applications que le processus de travail utilise pour exécuter l'application Web. IIS 7.0 ne charge pas ManagedEngine dans les processus de travail classiques, ce qui implique, dans ce cas, que le pipeline de requêtes ne peut pas corriger ou invoquer des modules ASP.NET. Au lieu de cela, IIS 7.0 active un certain nombre de gestionnaires ISAPI, basés sur IsapiModule (aspnet_isapi.dll), pour traiter les types de contenu ASP.NET identiques à IIS 6.0. Vous le verrez en analysant la section des gestionnaires sous system.web­Server du fichier applicationHost.config que vous trouverez par défaut dans le dossier %WinDir%\­System32\InetSrv\Config.

Recherchez la chaîne aspx en guise d'exemple et vous trouverez une entrée pointant vers PageHandlerFactory-Integrated (chargée dans les processus de travail de pool d'applications en mode intégré conformément au paramètre preCondition="integratedMode") et d'autres entrées pointant vers PageHandlerFactory-ISAPI-2.0 et PageHandlerFactory-ISAPI-2.0-64 (chargées dans les processus de travail de pool d'applications en mode classique conformément au paramètre preCondition="classicMode").

Vu que le mode de pipeline est défini au niveau du pool d'applications, IIS 7.0 peut exécuter des applications Web en mode intégré et en mode classique simultanément. En outre, les processus de travail ont seulement besoin de s'exécuter dans différents pools d'applications mais peuvent être hébergés sur le même serveur.

N'oubliez pas que le mode intégré et le mode classique n'affectent que la manière dont IIS 7.0 intègre ASP.NET au pipeline de requêtes. Ces modes de pipeline n'ont aucun effet direct sur les applications PHP. Le module FastCgiModule et autres modules natifs se chargent sans aucune condition préliminaire liée au mode du pipeline en mode intégré et en mode classique. FastCGI est l'interface préférée pour l'exécution du moteur de script PHP sur IIS 7.0. Au lieu d'utiliser FastCGI, vous pouvez créer un mappage de gestionnaires pour le moteur de script PHP par le biais de CGI ou utiliser IsapiModule avec PHP-ISAPI (php4isapi.dll).

Je pense, cependant, que ces options de configuration de type IIS 6.0 sont obsolètes maintenant que FastCGI propose des performances et une stabilité considérablement améliorées. CGI est plus lent étant donné qu'IIS doit initialiser un nouveau processus CGI pour chaque requête HTTP tandis que FastCGI réutilise les processus CGI pour plusieurs requêtes. ISAPI nécessite une génération PHP sécurisée au niveau du thread, ce qui implique plus d'efforts que l'exécution d'une génération PHP non sécurisée au niveau du thread.

Ce qui est probablement encore plus important, c'est que les extensions PHP ne sont pas toutes disponibles en version sécurisée au niveau du thread, et il n'est pas conseillé d'exécuter des extensions non sécurisées au niveau du thread avec ISAPI car cela risque de causer des problèmes de stabilité sur le serveur. FastCGI, par contre, est un environnement à simultanéité simple comme CGI. Utilisé pour exécuter un PHP non sécurisé au niveau du thread, FastCGI est stable et rapide et il représente clairement l'option à utiliser avec PHP 5 sur IIS 7.0. Il est également disponible sur IIS 6.0 au cas où vous ne seriez pas encore prêt à effectuer la transition vers IIS 7.0.

Modules et fonctionnalités

IIS 7.0 est doté d'une architecture hautement modularisée ou, comme disent les développeurs IIS, d'un ensemble de fonctionnalités à plusieurs composants. Ceci représente une bonne nouvelle pour les administrateurs Web qui veulent garder l'empreinte mémoire et la surface d'attaque d'IIS 7.0 aussi petites que possible. En activant des modules différents ou peut-être même en remplaçant des modules standard par des modules personnalisés, vous pouvez obtenir le contrôle intégral des fonctionnalités d'IIS 7.0 sur vos serveurs Web.

Pour exécuter ASP.NET en mode intégré ou en mode classique de même que des applications PHP sur le même serveur, vous devez au moins installer le rôle Web Server et les modules de base prenant en charge le traitement de requêtes, la configuration de serveur, ASP.NET, ISAPI et CGI (qui inclut le module FastCGI). Vous pouvez le faire avec la ligne de commande suivante :

start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

En général, je préfère installer IIS 7.0 avec toutes les options disponibles sur mon serveur de transit pour m'assurer que tous les composants et outils d'administration sont disponibles pour m'aider à exécuter mes applications Web aussi rapidement que possible. Ma stratégie est de m'assurer tout d'abord que tout fonctionne normalement avant de réduire la configuration en désinstallant des services de rôle et désactivant des modules. Lorsqu'une application Web commence à éprouver des difficultés, j'ajoute les services de rôle ou les modules que je viens de supprimer.

Vous pouvez également utiliser le Gestionnaire de packages (pkgmgr.exe) ou l'outil de ligne de commande d'IIS 7.0 (appcmd.exe) ou modifier directement la section globalModules du fichier applicationHost.config. Je trouve, toutefois, les outils graphiques très commodes. N'oubliez pas que certains modules, tels que RequestFilteringModule et StaticCompressionModule, sont très utiles bien que, strictement parlant, vous n'en ayez pas besoin pour exécuter vos applications Web. Si vous désinstallez un module qui est nécessaire pour un pool d'applications, vous recevez une erreur HTTP lorsque vous accédez à votre application Web, comme le montre la figure 5.

Figure 5 Une application ASP.NET ne s'exécute pas en mode classique car il manque le module IsapiModule (cliquer sur l'image pour l'agrandir)

Remarque : Assurez-vous que la même série de modules est toujours installée et activée sur tous vos serveurs IIS 7.0. Pour voir les composants installés, allez à HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ et vérifiez les clés de registre. Une valeur REG_DWORD de 0000 0001 pour une clé de registre, par exemple pour NetFxEnvironment ou CGI, indique que le composant correspondant est installé.

Migration d'application Web

Assez de théorie maintenant ! Il est temps de passer à la pratique et de migrer des applications Web vers IIS 7.0 ! Comme je l'ai mentionné précédemment, mon serveur de transit exécute IIS 7.0 avec tous les composants disponibles et PHP 5 non sécurisé au niveau du thread enregistrés avec FastCGI. Avant que de commencer, je dois essayer de répondre à quelques questions fondamentales :

• L'application Web nécessite-t-elle un système de gestion de données tel que SQL Server ou MySQL ?
• Ai-je besoin d'installer ou configurer des composants supplémentaires tels que les connexions ODBC, les objets COM ou les certificats SSL ?
• L'application Web nécessite-t-elle des comptes de service spéciaux et des autorisations d'accès local ou à distance élevées vers des partages de fichiers et autres ressources ?
• Y a-t-il des dépendances sur des fonctionnalités spécifiques aux plates-formes qui ne sont pas disponibles sur IIS 7.0 telles que les dépendances sur le module Apache pour la réécriture d'URL (mod_rewrite) ?

De telles questions vous aideront à exécuter plus rapidement vos applications Web sur IIS 7.0. Par exemple, si vous essayez de migrer une application PHP d'Apache 2.2 qui utilise mod_rewrite (disons, pour une question de convivialité avec les moteurs de recherche ou pour empêcher le détournement de la bande passante à travers les images de type inline), vous connaîtrez des problèmes tant que vous n'avez pas implémenté une solution de réécriture d'URL personnalisée compatible sur IIS 7.0. Fort heureusement, osCommerce ne nécessite pas de fonctionnalités mod_rewrite sur IIS 7.0, mais certains packages d'optimisation de moteur de recherche pourraient les exiger.

À présent que j'ai déterminé et installé les composants supplémentaires requis sur le serveur de transit, je suis prêt à exécuter mes applications Web. Là aussi, je devrais me poser un certain nombre de questions :

• Quelle est la configuration la plus simple à utiliser pour prendre en charge l'application Web ?
• Quelle configuration est actuellement utilisée dans l'environnement de production ?
• Puis-je optimiser la configuration d'application Web sur la nouvelle plate-forme ?
• Quel est l'ensemble minimal de services de rôle et de modules requis par l'application Web pour fonctionner dans la configuration désirée ?

L'exécution de l'application Web dans la configuration la plus simple est une façon rapide de voir si elle fonctionne. Si tout a l'air normal, il est temps d'appliquer une configuration identique à l'environnement de production existant et d'importer des données de production dans les bases de données de test. Bien sûr, certains problèmes ne pourraient apparaître que dans les configurations avancées.

Vous pourriez également remarquer qu'il existe des possibilités d'amélioration lorsque vous mettez en miroir votre configuration de production dans un laboratoire de test. Un bon moyen de centraliser la configuration de plusieurs serveurs Web est de placer le fichier applicationHost.config sur un partage UNC. Pour augmenter la tolérance aux pannes par le biais de la redondance et de la synchronisation de contenu, pensez à implémenter la réplication de système de fichiers distribués (DFS) qui est un moteur de réplication multi maître basé sur les états, disponible avec Windows Server 2003 R2 et Windows Server 2008. Vous pouvez également réduire les besoins en matière de stockage sur les serveurs Web frontaux en plaçant les fichiers de contenu de vos applications Web sur des partages UNC.

D'autres optimisations potentielles peuvent impliquer la sécurité ou la mise en cache dynamique. Je n'ai pas abordé les questions liées aux optimisations de la sécurité et des performances dans mon laboratoire de test parce qu'elles n'entrent pas dans le cadre de cet article. Je n'ai pas non plus configuré DFS pour éviter d'installer d'autres serveurs. Les instructions détaillées de la documentation associée proposent un exemple simplifié de la manière dont vous pouvez héberger un fichier applicationHost.config et du contenu Web sur les partages UNC. La figure 6 montre comment implémenter une batterie de serveurs Web de type UNC avec DFS.

Figure 6 Déploiement dune batterie de serveurs Web avec un fichier applicationHost.config et du contenu Web sur les partages UNC (cliquer sur l'image pour l'agrandir)

Conclusion

IIS 7.0 est une plate-forme de serveur Web impressionnante. Elle propose une architecture de base reconçue tout en conservant la presque totalité de la compatibilité descendante avec IIS 6.0. Elle devrait être capable d'exécuter la plupart des applications Web ASP.NET existantes sans aucune modification. Toutefois, étant donné l'étendue des modifications architecturales, vous ne pouvez pas supposer que vous ne rencontrez aucun problème de compatibilité.

Si vous migrez des applications Web ASP.NET ou PHP vers IIS 7.0, il est préférable d'adopter une approche échelonnée en mettant l'accent sur la planification, la préparation, le test et la documentation des modifications du code et de la configuration.

IIS 7.0 est un outil d'une grande utilité. Il propose de nombreuses améliorations dans les domaines tels que la sécurité, les performances, la configurabilité et la flexibilité. Il faudrait tout un ouvrage pour les passer en revue. Configuration centralisée et partage de contenu basé sur les partages UNC, configuration déléguée au moyen de fichiers web.config dans les annuaires d'applications, outils de gestion améliorés, informations de diagnostic détaillées et suivi des requêtes en erreur et mise en cache dynamique de la sortie, autant de fonctionnalités qui garantissent une réaction positive de la part des administrateurs Web.

La possibilité de mélanger les modules natifs et les modules gérés dans le pipeline de traitement de requêtes est très utile pour les développeurs ASP.NET. En outre, les améliorations des performances et de la stabilité qui sont proposées avec FastCGI sur IIS 7.0 représentent une excellente nouvelle pour les développeurs d'applications PHP.

Enfin, il existe une autre fonctionnalité importante qui aide les professionnels de l'informatique à réussir avec IIS 7.0 : le portail de la communauté IIS de Microsoft (www.iis.net). Il contient toute les informations dont vous avez besoin, y compris des articles détaillés sur la nouvelle architecture et le code source pour les développeurs C++ et ASP.NET montrant comment créer des modules IIS 7.0 ainsi que des instructions détaillées qui vous aideront à lancer des applications PHP. Ne manquez surtout pas de consulter ce site ! Il vous aidera à trouver des réponses à toutes vos questions sur IIS.

Fergus Strachan est fondateur et directeur de Maestra Ltd London, une entreprise de conseil qui se spécialise dans la conception d'infrastructure informatique et le support de la gestion de projet, dont les clients incluent les banques internationales et les institutions spécialisées dans l'enseignement au Royaume-Uni. Il écrit des articles sur la technologie de serveur de Microsoft et est l'auteur de l'ouvrage Intégration d'ISA Server 2006 à Microsoft Exchange 2007. Il est également coauteur du Kit de ressources Microsoft Exchange Server 2003.

© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.