IIS

Come usare subito IIS 7.0

Fergus Strachan

Panoramica:

  • Distribuzione di IIS 7.0 in un ambiente di Web farm
  • Miglioramenti della sicurezza e delle prestazioni
  • Migrazione delle applicazioni Web ASP.NET da IIS 6.0 a IIS 7.0
  • Migrazione delle applicazioni Web PHP a IIS 7.0

Indice

Preparazione, configurazione e test
Configurazione del test
Miglioramenti importanti per gli amministratori IT
Architettura IIS
Modalità classica e integrata
Moduli e funzionalità
Migrazione delle applicazioni Web
Conclusioni

Il team IIS di Microsoft sostiene che IIS (Internet Information Services) 7.0 è la versione migliore nella storia di IIS. Questa versione imposta nuovi standard, presenta miglioramenti sostanziali e

apporta nuove capacità per consolidare gli ambienti Web. IIS 7.0, inclusa in Windows Server® 2008 e Windows Vista® SP1, è già in forza a Microsoft.com e diverse società di hosting Web hanno già iniziato a fornire l'hosting di IIS 7.0 ai progettisti e agli sviluppatori Web che intendono trasportare le loro applicazioni Web esistenti alla nuova piattaforma per server Web.

In questo articolo esaminerò i miglioramenti principali di IIS 7.0 che sono essenziali per i professionisti IT ed approfondirò la migrazione ASP.NET e le applicazioni Web PHP. Ma prima di tutto voglio definire un laboratorio di test che assomiglia a un ambiente di produzione di base.

Si tratta di un'attività importante. Prima di distribuire IIS 7.0 ai server di produzione, è necessario dedicare del tempo al test in un ambiente di laboratorio per verificare che le applicazioni Web vengano eseguite senza problemi nel nuovo server Web.

Preparazione, configurazione e test

Il mio test di laboratorio include sistemi in cui sono in esecuzione Windows Server 2003 e IIS 6.0, che ospitano applicazioni ASP.NET e server in cui sono in esecuzione la distribuzione Ubuntu 7.10 Linux e Apache HTTP Server 2.2, che ospitano applicazioni Web basate su PHP. Il mio obiettivo finale è distribuire Windows Server 2008 in sistemi di gestione e produzione e quindi complesse applicazioni Web di transizione al fine di sostituire le istanze di IIS 6.0 e di Apache con IIS 7.0.

Dispongo di due applicazioni Web principali: DotNetNuke 4.7 e osCommerce 3.0a4. DotNetNuke è un framework di applicazione Web basato su ASP.NET 2.0 e Microsoft® SQL Server®. L'altra applicazione, osCommerce, è l'ultima versione alfa di una ricca soluzione di e-commerce creata in PHP in MySQL. Pertanto inseriamo queste applicazioni avanzate in IIS 7.0.

Voglio chiarire che non è mia intenzione fare confronti tra versioni, prodotti o piattaforme software. Tuttavia esistono diversi vantaggi nella standardizzazione di Windows Server 2008 e IIS 7.0 che devo sottolineare. Vale a dire, la ridotta complessità di gestione e la possibilità di ridurre al minimo il numero globale di server Web in esecuzione.

Nella Figura 1 viene fornita una panoramica del laboratorio di test che uso per questo articolo. Se si intende seguire le mie spiegazioni nel proprio ambiente di test, è possibile reperire collegamenti ai componenti software necessari e istruzioni dettagliate per l'installazione nel materiale di accompagnamento disponibile nella sezione Code Downloads del sito Web TechNet Magazine.

fig01.gif

Figura 1 Ambiente di test per implementare IIS 7.0 (fare clic sull'immagine per ingrandirla)

Notare che, mentre stavo scrivendo questo articolo, Microsoft ha rilasciato uno strumento per la riga di comando (MSDeploy.exe) per supportare la distribuzione, la sincronizzazione e la migrazione di applicazioni Web in IIS 6.0 e 7.0 da parte dei clienti. Consiglio di prendere in considerazione questo strumento. Informazioni dettagliate sono reperibili presso il blog del team Microsoft Web Deployment all'indirizzo go.microsoft.com/fwlink/?LinkId=118272.

Configurazione del test

Al momento di scrivere questo articolo, Windows Server 2008 era ancora in fase di prerilascio, pertanto non ho potuto sostituire Windows Server 2003 nei server di database o controller di dominio. Con il rilascio ufficiale di Windows Server 2008, entra in ballo anche la migrazione dell'infrastruttura di Active Directory®. Anche la migrazione dei database SQL Server® 2005 e MySQL in SQL Server 2008 va oltre l'ambito di questo articolo.

Ho distribuito SQL Server 2008 nel mio server di gestione principalmente perché è più semplice che installare SQL Server 2005 con Service Pack 2. L'esecuzione di DotNetNuke con un database SQL Server 2008 non ha presentato problemi. Anche l'installazione di MySQL 5.0 in Windows Server 2008 è avvenuta senza complicazioni.

Sebbene IIS 7.0 sia disponibile in Server Core, non ho usato un'installazione Server Core per via di determinati requisiti per il mio test. Il server di gestione richiedeva un'installazione completa in quanto si trattava del sistema di test primario. Inoltre, Microsoft .NET Framework non è disponibile in Server Core.

PHP viene eseguito correttamente in Server Core, ma il mio obiettivo è consolidare le applicazioni ASP.NET e PHP, pertanto Server Core semplicemente non costituisce un'opzione. Finché .NET Framework non sarà supportato in Server Core, sarà necessario eseguire un'installazione completa per supportare le applicazioni ASP.NET. Per istruzioni dettagliate su come installare l'ambiente di test, esaminare il file 01_install_testlab.htm nel materiale di accompagnamento.

Ho optato per l'esecuzione di un'installazione pulita di Windows Server 2008 (invece di aggiornare i server esistenti). Tra le altre cose, l'installazione pulita facilita l'implementazione di uno scenario di migrazione gestita come quello della Figura 2. La strategia implicita è conservare le Web farm esistenti finché tutti i componenti delle applicazioni Web pertinenti non sono stati regolarmente verificati nel server di gestione e spostati nella nuova Web farm IIS 7.0.

fig02.gif

Figura 2 Gestione del passaggio a IIS 7.0 (fare clic sull'immagine per ingrandirla)

È possibile spostare tutte le applicazioni Web esistenti in una sola volta o gradualmente, a seconda della complessità dell'ambiente. Per ogni applicazione o sito Web, dopo aver eseguito un test finale di accettazione nella nuova Web farm, è possibile effettuare il passaggio modificando i record DNS pertinenti in modo da indirizzare i browser alla nuova Web farm IIS 7.0. In questo modo si riducono al minimo i fermi e le interruzioni.

Miglioramenti importanti per gli amministratori IT

In MSDN® Magazine è pubblicato un articolo eccellente di Mike Volodarsky dal titolo "Esplorazione del server Web per Windows Vista e altro ancora" (disponibile all'indirizzo msdn2.microsoft.com/magazine/cc163453.aspx), che insegna subito a mettere a frutto i miglioramenti riscontrati in IIS 7.0.

Un'altra lettura utile è un articolo sul blog del team di Microsoft.com dal titolo "The Tasty Morsels Found in Dogfood", disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=117436 (in inglese). L'articolo riepiloga le esperienze iniziali del team in merito a IIS 7.0. In breve, classificano i principali miglioramenti come:

  1. Configurazione semplificata.
  2. Grande compatibilità.
  3. Non più metabase.
  4. Configurazione centralizzata per mezzo del file applicationHost.config che si trova in una condivisione UNC.
  5. Configurazione delegata per mezzo di file web.config nelle directory delle applicazioni.
  6. Strumenti di gestione migliorati.
  7. Traccia delle richieste non riuscite.
  8. Filtraggio delle richieste senza la necessità di URLScan.
  9. Semplificazione della disponibilità della sincronizzazione del contenuto per mezzo delle condivisioni UNC.

10. Cache di output del contenuto dinamico.

La semplificazione della configurazione è uno dei miei obiettivi principali. Nell'articolo sul blog, il team di Microsoft.com dimostra come è possibile distribuire tutte le funzionalità di IIS 7.0 (o, naturalmente, solo quelle che interessano) con una sola riga di comando. Ho incorporato questo approccio con entusiasmo nelle istruzioni per la configurazione del laboratorio di test; la riga di comando è mostrata nella Figura 3.

Dichiaratamente questo comando è piuttosto lungo (se si intende copiare questo comando, consiglio di copiarlo e incollarlo dal sito Web TechNet Magazine invece di ridigitarlo a mano). Sebbene questo comando inserisca tutti i moduli disponibili nel computer IIS 7.0, non include PHP. IIS 7.0 non include PHP e il concetto di scaricare e installare pacchetti Debian in Internet è estraneo a Windows® Package Manager (pkgmgr.exe). Accedere a Windows Automated Installation Kit (AIK).

Figura 3 Distribuzione delle funzionalità IIS 7.0 con una sola riga di comando

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>).

AIK consente di creare un DVD di installazione personalizzato per Windows Server 2008, contenente IIS 7.0 e PHP 5. È possibile includere anche MySQL, file di applicazioni Web e tutti gli altri componenti che sono necessari alla propria distribuzione. Tutti i componenti possono far parte dell'installazione di Windows Server 2008; in tal modo è possibile applicare personalizzazioni a tutti i server Web in modo coerente. Righe di comando o modifiche al file di configurazione non sono necessarie.

È possibile creare un DVD personalizzato anche per le installazioni completamente autonome. L'AIK include documentazione e strumenti per creare un file AutoUnattend.xml, che può essere quindi inserito nella cartella principale del DVD. Il file Custom Image Deployment.htm nel materiale di accompagnamento offre istruzioni dettagliate.

Molti amministratori concordano anche sul fatto che la compatibilità è un miglioramento essenziale. Procedendo mi aspettavo di incontrare alcuni problemi di compatibilità con DotNetNuke e osCommerce ma la transizione a IIS 7.0 è andata piuttosto liscia, nonostante il fatto che entrambe queste applicazioni Web includono funzionalità avanzate come l'autenticazione dei moduli e URL facili da trovare con i motori di ricerca.

Con DotNetNuke, non ho incontrato nessun problema finché non sono passato a uno scenario di Web farm complesso, con condivisione del contenuto in una piattaforma a 64 bit. Il problema era comunque di lieve entità. In definitiva, grazie a questa compatibilità migliorata, l'esecuzione delle applicazioni Web in IIS 7.0 richiede meno tempo.

Se si dovessero verificare problemi di compatibilità con le applicazioni Web, il supporto incorporato per la diagnostica e la traccia si rivelerà una delle nuove funzionalità più utili. Le informazioni dettagliate della diagnostica sono molto istruttive e i percorsi di soluzione sono utili ed efficaci.

Nella Figura 4 sono mostrate le informazioni di diagnostica ottenute quando si esegue DotNetNuke 4.7 in IIS 7.0 in modalità integrata. In questo esempio, ci sono tre opzioni (mostrate nella sezione "Possibili operazioni"). Modificare l'applicazione in modo da supportare la modalità integrata probabilmente è la scelta migliore per gli sviluppatori DotNetNuke. È invece una cattiva idea ignorare l'errore. Preferisco la terza scelta e attivare la modalità classica cambiando l'applicazione Web nella classica .NET AppPool, perché voglio che l'esecuzione di DotNetNuke 4.7 sia invariata in IIS 7.0.

fig04.gif

Figura 4 Informazioni di diagnostica per l'esecuzione di DotNetNuke in modalità integrata (fare clic sull'immagine per ingrandirla)

Architettura IIS

È lecito chiedersi cosa siano queste modalità integrata e classica e perché influiscano sull'applicazione ASP.NET (DotNetNuke) ma non sull'applicazione PHP (osCommerce). Per una maggiore comprensione, è necessario innanzitutto dare uno sguardo all'architettura di IIS 7.0. Le versioni precedenti integrano il runtime ASP.NET nel server Web di base, principalmente attraverso un'estensione ISAPI (aspnet_isapi.dll). IIS 7.0, d'altro canto, consente ai moduli ASP.NET di collegarsi direttamente al server Web di base per mezzo di un modulo HTTP a livello globale chiamato ManagedEngine, che carica la DLL di supporto ASP.NET (webengine.dll) nella pipeline di elaborazione della richiesta di IIS 7.0.

I moduli nativi usano l'API del server Web principale di IIS per la registrazione per specifici eventi nella pipeline, ad esempio BeginRequest, Authenticate­Request, AuthorizeRequest e Execute­RequestHandler. ManagedEngine fornisce il supporto necessario a integrare anche i moduli ASP.NET nella pipeline di elaborazione della richiesta. Con questa nuova architettura, IIS 7.0 può richiamare i moduli nativi e ASP.NET in qualsiasi momento durante l'elaborazione della richiesta, indipendentemente dal tipo di contenuto della richiesta.

Prendiamo in considerazione, ad esempio, l'autenticazione utente ASP.NET. In IIS 6.0, un modulo HTTP basato su ASP.NET può registrarsi per eventi On­Authenticate (ad esempio Forms­Authentication.OnAuthenticate e Win­dows­Authentication.OnAuthenticate) per impostare l'identità dell'utente nel HttpContext corrente. Questo funziona benissimo all'interno del runtime ASP.NET ma non è possibile usare questo codice ASP.NET per proteggere le risorse esposte attraverso un'applicazione Web basata su PHP.

In base alla configurazione della scriptmap, IIS 6.0 inoltra le richieste per i tipi di contenuto ASP.NET a aspnet_isapi.dll ma non inoltra le richieste per i tipi di contenuto PHP all'estensione ISAPI per ASP.NET. Dopo tutto, ASP.NET non elabora il codice PHP ma ciò significa anche che il codice di autenticazione ASP.NET non viene eseguito se è richiesta una pagina PHP. Pertanto, con IIS 6.0, è necessario duplicare la logica di autenticazione perché le applicazioni PHP devono implementare i loro meccanismi di autenticazione.

IIS 7.0 usa un modello di elaborazione guidato da eventi che supporta la combinazione e l'associazione di singoli moduli nella pipeline di elaborazione della richiesta. Tra gli altri componenti, IIS 7.0 è dotato di moduli WindowsAuthentication e FormsAuthentication gestiti che generano eventi OnAuthenticate quando la pipeline di elaborazione della richiesta genera l'evento AuthenticateRequest. A questo punto è possibile che un modulo nativo, come Request­FilteringModule o IpRestrictionModule, gestisca l'evento BeginRequest in modo da rifiutare richieste critiche, quindi esegua il codice di autenticazione ASP.NET personalizzato in corrispondenza dell'evento AuthenticateRequest e che FastCgiModule esegua il motore di scripting di PHP (php-cgi.exe) in corrispondenza dell'evento Execute­RequestHandler per elaborare le pagine PHP.

Il risultato di questa architettura integrata è che gli sviluppatori Web non devono duplicare il codice per implementare la comune logica aziendale. È possibile usare il codice di autenticazione ASP.NET personalizzato per proteggere tutte le risorse IIS, comprese le applicazioni PHP. È possibile anche eseguire altre attività di pre e post elaborazione per mezzo dei moduli ASP.NET, come la riscrittura di URL, la traccia personalizzata e la registrazione degli errori.

Modalità integrata e classica

L'effetto collaterale causato da questa nuova architettura è che le applicazioni ASP.NET esistenti potrebbero richiedere modifiche al codice e alla configurazione che dovrebbero essere eseguite dagli sviluppatori delle applicazioni, per garantire che le modifiche non comportino conflitti tra i moduli nella pipeline di elaborazione della richiesta. Ma se non è possibile trasferire immediatamente un'applicazione Web esistente, è possibile attivare la modalità classica nel pool di applicazioni usato dal processo di lavoro per eseguire l'applicazione Web. IIS 7.0 non carica ManagedEngine nei processi di lavoro in modalità classica, di conseguenza, in questo caso, la pipeline di elaborazione della richiesta non può risolvere o richiamare i moduli ASP.NET. IIS 7.0 invece attiva diversi gestori degli eventi che sono basati su IsapiModule (aspnet_isapi.dll), per elaborare i tipi di contenuto ASP.NET simili a IIS 6.0. Questo fatto è evidente dall'analisi della sezione dei gestori degli eventi in system.web­Server nel file di configurazione applicationHost.config, che si trova per impostazione predefinita nella cartella %WinDir%\­System32\InetSrv\Config.

Ad esempio, se si cerca la stringa aspx, si trova una voce che punta a PageHandlerFactory-Integrated (caricato nei processi di lavoro del pool di applicazioni in modalità integrata secondo l'impostazione preCondition="integratedMode") e si trovano altre voci che puntano a PageHandlerFactory-ISAPI-2.0 e PageHandlerFactory-ISAPI-2.0-64 (caricati nei processi di lavoro del pool di applicazioni in modalità classica secondo l'impostazione preCondition="classicMode").

Poiché la modalità della pipeline è impostata a livello di pool di applicazioni, IIS 7.0 può eseguire le applicazioni Web in modalità integrata e in modalità classica contemporaneamente. Quindi i processi di lavoro dovranno semplicemente essere eseguiti in diversi pool di applicazioni ma potranno essere ospitati nello stesso server.

Ricordare che la modalità integrata e la modalità classica influiscono solo su come IIS 7.0 integra ASP.NET nella pipeline di elaborazione della richiesta. Queste modalità della pipeline non influiscono direttamente sulle applicazioni PHP. Il modulo FastCgiModule e tutti gli altri moduli nativi vengono caricati senza precondizioni di modalità pipeline sia nella modalità integrata che in quella classica. FastCGI è l'interfaccia preferita per l'esecuzione del motore di scripting PHP in IIS 7.0. Invece di usare FastCGI, è possibile creare anche un mapping dei gestori per il motore di scripting PHP per mezzo di CGI oppure è possibile usare IsapiModule insieme a PHP-ISAPI (php4isapi.dll).

Tuttavia ritengo che queste alternative di configurazione degli stili IIS 6.0 siano superate ora che FastCGI offre sostanzialmente prestazioni e stabilità migliori. CGI è più lenta dato che IIS deve inizializzare un nuovo processo CGI per ogni richiesta HTTP mentre FastCGI riusa i processi CGI per più richieste. ISAPI richiede una build PHP thread-safe che comporta maggiore overhead rispetto all'esecuzione PHO non thread-safe.

Forse è ancora più importante notare che non tutte le estensioni PHP sono disponibili in una versione thread-safe e che l'esecuzione delle estensioni non thread-safe con ISAPI è una pessima idea in quanto può causare problemi di stabilità nel server. FastCGI, d'altro canto, è un ambiente a singola concorrenza come CGI. Usato per eseguire PHP non thread-safe, è stabile e veloce ed è chiaramente il modo migliore per usare PHP 5 in IIS 7.0. È anche disponibile in IIS 6.0 se non si è ancora pronti per una transizione a IIS 7.0.

Moduli e funzionalità

IIS 7.0 presenta un'architettura strutturata in moduli o, se gli sviluppatori IIS la inseriscono, una serie di funzionalità basate su componenti. Si tratta di una buona notizia per gli amministratori Web che intendono mantenere il footprint e la superficie di attacco della memoria di IIS 7.0 più piccoli possibili. Attivando diversi moduli o perfino sostituendo moduli standard con moduli personalizzati, è possibile avere il controllo completo delle funzionalità IIS 7.0 nei server Web.

Per eseguire ASP.NET in modalità integrata o classica nonché applicazioni PHP nello stesso server, è necessario installare almeno il ruolo di server Web e i moduli principali per supportare l'elaborazione delle richieste, la configurazione del server, ASP.NET, ISAPI e CGI (che include il modulo FastCGI). A questo scopo usare la seguente riga di comando:

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

In genere preferisco installare IIS 7.0 con tutte le opzioni disponibili nel mio server di gestione per garantire che tutti i componenti e gli strumenti amministrativi siano disponibili per attivare ed eseguire velocemente le applicazioni Web. La mia strategia consiste nell'assicurarmi che tutto funzioni e poi restringo la configurazione disinstallando i servizi di ruolo e disattivando i moduli. Quando un'applicazione Web inizia ad agire, aggiungo i servizi o i moduli che ho appena rimosso.

È possibile anche usare Package Manager (pkgmgr.exe) o lo strumento della riga di comando IIS 7.0 (appcmd.exe) oppure modificare la sezione globalModules direttamente nel file applicationHost.config ma trovo che gli strumenti grafici siano molto comodi. Tenere presente che alcuni moduli, come RequestFilteringModule e StaticCompressionModule, sono piuttosto utili anche se, a dire il vero, non sono necessari per l'esecuzione delle applicazioni Web. Se si disinstalla un modulo che è necessario per un pool di applicazioni, si riceve un errore HTTP quando si accede all'applicazione Web, come illustrato nella Figura 5.

fig05.gif

Figura 5 Un'applicazione ASP.NET non verrà eseguita in modalità classica perché manca IsapiModule (fare clic sull'immagine per ingrandirla)

Nota: si consiglia di assicurarsi che su tutti i server IIS 7.0 sia installata e attivata la stessa serie di moduli. Per verificare i componenti installati, andare a HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ e controllare le chiavi del Registro di sistema. Un valore REG_DWORD pari a 0000 0001 per una chiave del Registro, ad esempio per NetFxEnvironment o CGI, indica che il componente corrispondente è installato.

Migrazione delle applicazioni Web

Finora ho fatto molta teoria ma è giunto il momento di rimboccarsi le maniche e spostare alcune applicazioni Web in IIS 7.0. Come accennato prima, il server di gestione esegue IIS 7.0 con tutti i componenti disponibili e PHP 5 non thread-safe registrato con FastCGI. Prima di iniziare, devo pormi alcune domande fondamentali:

  • L'applicazione Web richiede un sistema di gestione del database come, ad esempio, SQL Server o MySQL?
  • Devo installare o configurare altri componenti, ad esempio connessioni ODBC, oggetti COM o certificati SSL?
  • L'applicazione Web richiede speciali account di servizio ed elevate autorizzazioni di accesso in locale o in remoto alle condivisioni file e ad altre risorse?
  • Esistono dipendenze nelle funzionalità specifiche della piattaforma che non sono disponibili in IIS 7.0, ad esempio le dipendenze nel modulo Apache per la riscrittura di URL (mod_rewrite)?

Il porsi queste domande aiuta a fare in modo che le applicazioni Web vengano eseguite in IIS 7.0 più velocemente. Ad esempio, se si tenta di eseguire la migrazione di un'applicazione PHP da Apache 2.2 che usa mod_rewrite (diciamo per semplicità del motore di ricerca o per impedire il dirottamento della larghezza di banda tramite immagini collegate in linea), si verificheranno problemi finché non si implementa una soluzione di riscrittura di URL personalizzata e compatibile in IIS 7.0. Fortunatamente, osCommerce non richiede la funzionalità mod_rewrite in IIS 7.0, ma potrebbero richiederla alcuni pacchetti di ottimizzazione del motore di ricerca.

Ora che ho stabilito e installato gli altri componenti necessari nel server di gestione, sono pronto per attivare ed eseguire le applicazioni Web. Anche in questo caso, voglio pormi alcune domande:

  • Qual è la configurazione più semplice che posso usare per supportare l'applicazione Web?
  • Quale configurazione è attualmente usata nell'ambiente di produzione?
  • Posso ottimizzare la configurazione dell'applicazione Web nella nuova piattaforma?
  • Qual è la serie minima di servizi di ruolo e di moduli necessaria all'applicazione Web per funzionare nella configurazione desiderata?

Facendo in modo che l'applicazione Web venga eseguita nella configurazione più semplice ci si assicura subito che funzioni. Se tutto va bene, è ora di applicare una configurazione simile all'ambiente di produzione esistente e importare i dati di produzione nei database di test. Naturalmente, alcuni problemi potrebbero emergere solo nelle configurazioni avanzate.

È possibile notare possibilità di miglioramento quando si esegue il mirroring della configurazione di produzione in un laboratorio di test. Inserendo il file applicationHost.config in una configurazione UNC si centralizza la configurazione di più server Web. Per aumentare la tolleranza d'errore con la ridondanza e la sincronizzazione del contenuto, è possibile implementare la replica DFS (Distributed File System), che è un motore di replica multimaster basato sullo stato e disponibile con Windows Server 2003 R2 e Windows Server 2008. È possibile anche ridurre al minimo i requisiti di archiviazione dalla parte Web inserendo i file di contenuto delle applicazioni Web nelle condivisioni UNC.

Altre ottimizzazioni potenziali possono riguardare la sicurezza o la cache dinamica. Non ho affrontato le ottimizzazioni della sicurezza e delle prestazioni nel mio laboratorio di test in quanto sarebbero andate oltre l'ambito di questo articolo. Non ho nemmeno configurato DFS per evitare l'installazione di altri server. Le istruzioni dettagliate nel materiale di accompagnamento forniscono un esempio semplificato di come ospitare il file applicationHost.config e il contenuto Web nelle condivisioni UNC. Nella Figura 6 è illustrato come implementare una Web farm basata su UNC con DFS.

fig06.gif

Figura 6 Distribuzione di una Web farm con il file applicationHost.config e il contenuto Web nelle condivisioni UNC (fare clic sull'immagine per ingrandirla)

Conclusioni

IIS 7.0 è un'eccezionale piattaforma server Web. Presenta un'architettura principale riprogettata mentre conserva circa il 100% della compatibilità con IIS 6.0. Dovrebbe essere in grado di eseguire la maggior parte delle applicazioni Web ASP.NET esistenti senza modifiche. Ma, data l'entità delle modifiche all'architettura, non è possibile dare per scontato che non si verificheranno problemi di compatibilità.

Sia nel caso della migrazione delle applicazioni Web ASP.NET che di quelle PHP in IIS 7.0, è meglio adottare un approccio graduale prestando particolare attenzione alla pianificazione, alla preparazione, al test e alla documentazione del codice e alle modiche delle configurazione.

IIS 7.0 vale tutto il lavoro che richiede. Esistono molti miglioramenti in aree quali la sicurezza, le prestazioni, la possibilità di configurazione e la flessibilità. Ci vorrebbe un libro intero per parlarne esaurientemente. La configurazione centralizzata e la condivisione del contenuto basato sulle condivisioni UNC, la configurazione delegata per mezzo di file web.config nelle directory delle applicazioni, gli strumenti di gestione migliorati, le informazioni dettagliate di diagnostica e la traccia delle richieste non riuscite e la cache di output dinamico sono metodi infallibili per conquistare gli amministratori Web.

La capacità di combinare moduli nativi e moduli gestiti nella pipeline di elaborazione della richiesta è un vantaggio per gli sviluppatori ASP.NET. I miglioramenti delle prestazioni e della stabilità inclusi in FastCGI in IIS 7.0 sono notizie eccellenti per gli sviluppatori di applicazioni PHP.

C'è un'altra cosa importante che aiuta i professionisti IT a sfruttare IIS 7.0: il portale Microsoft IIS Community Portal (www.iis.net). Vi sono contenute tutte le informazioni necessarie, compresi articoli dettagliati sulla nuova architettura, il codice sorgente per gli sviluppatori C++ e ASP.NET, dimostrazioni di come creare moduli IIS 7.0 e istruzioni dettagliate per attivare ed eseguire le applicazioni PHP. È un sito da non perdere in cui si trovano le risposte alle domande su IIS.

Fergus Strachan è fondatore e direttore di Maestra Ltd London, una società di consulenza specializzata nella progettazione di infrastrutture IT e nel supporto alla gestione dei progetti, che offre i suoi servizi a banche internazionali e istituti scolastici nel Regno Unito. Scrive articoli sulla tecnologia per server Microsoft ed è l'autore di Integrating ISA Server 2006 with Microsoft Exchange 2007. È anche coautore di Microsoft Exchange Server 2003 Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.