• Artigo

IIS

Go-Live com o IIS 7.0

Fergus Strachan

Visão geral:

  • Implantação do IIS 7.0 em um ambiente de farm da Web
  • Aprimoramentos de segurança e desempenho
  • Migração de aplicativos Web ASP.NET do IIS 6.0 para o IIS 7.0
  • Migração de aplicativos Web PHP para o IIS 7.0

Conteúdo

Preparar, configurar, testar
Minha configuração de teste
Aprimoramentos importantes para administradores de TI
Arquitetura do IIS
Modos clássico e integrado
Módulos e funcionalidade
Migração de aplicativo Web
Conclusão

A equipe do IIS na Microsoft diz que o IIS (Internet Information Services) 7.0 é a maior versão na história do IIS. Essa versão define novos padrões, oferece melhorias fundamentais e

apresenta novos recursos para consolidar ambientes da Web. O IIS 7.0, incluído com o Windows Server® 2008 e Windows Vista® SP1, já capacita o Microsoft.com, e várias empresas de hospedagem da Web já começaram a fornecer hospedagem pelo IIS 7.0 a Web designers e desenvolvedores que desejam conduzir seus aplicativos Web existentes para a nova plataforma de servidor Web.

Neste artigo, irei explorar as principais melhorias do IIS 7.0 mais importantes para profissionais de TI e, em seguida, entrarei em detalhes sobre a migração do ASP.NET e aplicativos Web PHP. Mas, primeiro, quero descrever um laboratório de teste que seja parecido com um ambiente de produção básico.

Essa é uma tarefa importante. Antes de implantar o IIS 7.0 nos seus servidores de produção, você precisa passar um tempo fazendo um teste completo em um ambiente de laboratório para garantir que seus aplicativos Web sejam executados sem problemas no novo servidor Web.

Preparar, configurar, testar

Meu laboratório de teste inclui sistemas que executam o Windows Server 2003 e IIS 6.0, que hospedam aplicativos ASP.NET, bem como servidores que executam a distribuição do Linux Ubuntu 7.10 e Apache HTTP Server 2.2, que hospedam aplicativos Web baseados em PHP. Meu objetivo final é implantar o Windows Server 2008 em sistemas de preparação e produção e, em seguida, fazer a transição de aplicativos Web complexos para substituir instâncias do Apache e o IIS 6.0 pelo IIS 7.0.

Tenho dois aplicativos Web principais: DotNetNuke 4.7 e osCommerce 3.0a4. O DotNetNuke é uma estrutura de aplicativo Web baseada em ASP.NET 2.0 e Microsoft® SQL Server®. O outro aplicativo, osCommerce, é a versão alfa mais recente de uma solução de comércio eletrônico cheia de recursos criada com base em PHP e MySQL. Então, vamos colocar esses aplicativos avançados no IIS 7.0!

Quero deixar claro que não é minha intenção comparar versões de software, produtos ou plataformas. Existem, no entanto, várias vantagens para se padronizar para o Windows Server 2008 e IIS 7.0 que eu devo salientar. Ou seja, a complexidade administrativa é reduzida e você pode minimizar o número total de servidores Web em execução.

A Figura 1 apresenta uma visão geral do laboratório de teste que estou usando para este artigo. Se deseja seguir minhas explicações no seu próprio ambiente de teste, você pode encontrar links para os componentes de software necessários, bem como instruções de instalação detalhadas, passo a passo no material complementar disponível na seção de downloads de códigos no site da TechNet Magazine em .com.

fig01.gif

Figura 1 O ambiente de teste para implementar o IIS 7.0 (Clique na imagem para ampliá-la)

Observe que, no momento em que eu estava concluindo este artigo, a Microsoft lançou uma ferramenta de linha de comando (MSDeploy.exe) para suportar a implantação dos clientes, a sincronização e a migração de aplicativos Web para o IIS 6.0 e 7.0. Recomendo que você conheça essa ferramenta. Informações detalhadas podem ser encontradas no blog da equipe de implantação Web da Microsoft em go.microsoft.com/fwlink/?LinkId=118272.

Minha configuração de teste

No momento em que este artigo foi escrito, o Windows Server 2008 ainda estava em pré-lançamento, então, portanto, eu não substituí o Windows Server 2003 em servidores de bancos de dados ou controlador de domínio. Com a versão oficial do Windows Server 2008, convém considerar também a migração da sua infra-estrutura do Active Directory®. Migrar bancos de dados SQL Server® 2005 e MySQL para o SQL Server 2008 também está além do escopo deste artigo.

Eu implantei o SQL Server 2008 no meu servidor de preparação principalmente porque é preciso menos esforço do que para instalar o SQL Server 2005 com Service Pack 2. O DotNetNuke não apresentou problemas ao ser executado com um banco de dados do SQL Server 2008. A instalação do MySQL 5.0 no Windows Server 2008 também foi simples, sem complicações.

Embora o IIS 7.0 esteja disponível em Server Core, eu não usei uma instalação Server Core devido a certos requisitos para o meu teste. Meu servidor de preparação exigia uma instalação completa porque esse foi meu primeiro sistema de teste. Além disso, o Microsoft .NET Framework não está disponível em Server Core.

O PHP é executado bem em Server Core, mas meu objetivo é consolidar aplicativos ASP.NET e PHP, então o Server Core simplesmente não é uma opção. Até que o .NET Framework seja suportado em Server Core, você precisará executar uma instalação completa para suportar aplicativos ASP.NET. Para obter diretrizes passo a passo detalhadas para instalar o ambiente de teste, consulte o arquivo 01_install_testlab.htm no material complementar.

Eu optei por executar uma instalação limpa do Windows Server 2008 (em vez de atualizar servidores existentes). Entre outras coisas, a instalação limpa facilita a implementação de um cenário de migração preparado como o da Figura 2. A estratégia subjacente é manter as farms da Web existentes em execução até que todos os componentes relevantes dos aplicativos Web tenham sido testados com êxito no servidor de preparação e movidos para a nova farm da Web do IIS 7.0.

fig02.gif

Figura 2 Preparando a transferência para o IIS 7.0 (Clique na imagem para ampliá-la)

Você pode mover todos os aplicativos Web existentes de uma vez ou gradualmente, dependendo da complexidade do seu ambiente. Para cada aplicativo Web ou site, após executar um teste final de aceitação na nova farm da Web, você pode fazer a transferência alterando registros DNS relevantes para direcionar os navegadores para a nova farm da Web do IIS 7.0. Isso mantém o mínimo de tempo de inatividade e interrupções.

Aprimoramentos importantes para administradores de TI

A MSDN® Magazine possui um excelente artigo de Mike Volodarsky chamado "Explore o servidor Web do Windows Vista e muito mais" (disponível em msdn2.microsoft.com/magazine/cc163453.aspx), que rapidamente chama a sua atenção para que você conheça as melhorias encontradas no IIS 7.0.

Outra boa leitura é uma postagem do blog da equipe do Microsoft.com, chamada "Os pedaços saborosos encontrados na "ração para cachorro" (disponível em go.microsoft.com/fwlink/?LinkId=117436). A postagem resume as experiências iniciais com o IIS 7.0 dos membros da equipe. Em resumo, eles classificaram as principais melhorias como:

  1. Configuração simplificada.
  2. Excelente compatibilidade.
  3. Inexistência de metabase.
  4. Configuração centralizada por meio do arquivo applicationHost.config colocado em um compartilhamento UNC.
  5. Configuração delegada por meio dos arquivos web.config em diretórios de aplicativos
  6. Ferramentas de gerenciamento aprimoradas.
  7. Rastreamento de solicitação com falha.
  8. Filtragem de solicitação sem a necessidade de URLScan.
  9. Disponibilidade de sincronização de conteúdo simplificada por meio de compartilhamentos UNC.
  10. Cache de saída de conteúdo dinâmico.

A configuração simplificada definitivamente está na minha lista. Na postagem do seu blog, a equipe do Microsoft.com demonstra como você pode implantar todos os recursos do IIS 7.0 (ou, é claro, apenas os recursos que desejar) com uma única linha de comando. Eu incorporei ansiosamente essa abordagem nas instruções de configuração do meu laboratório de teste, com a linha de comando exibida na Figura 3.

De fato, esse comando é bem longo. (Se você desejar copiar esse comando, recomendo que você copie e cole-o a partir do site da TechNet Magazine, em vez de redigitá-lo a mão.) Embora esse comando coloque todos os módulos disponíveis no computador do IIS 7.0, ele não inclui PHP. O IIS 7.0 não inclui PHP e a noção de baixar e instalar pacotes Debian pela Internet é um conceito estranho para o Gerenciador de Pacotes do Windows® (pkgmgr.exe). Informe o Kit de Instalação Automatizada (AIK) do Windows.

Figura 3 Implantação dos recursos do IIS 7.0 com uma única linha de 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>).

Com o AIK, você pode criar um DVD de instalação personalizado para o Windows Server 2008 que inclua o IIS 7.0 e PHP 5. Você também pode incluir o MySQL, arquivos de aplicativos Web e qualquer outro componente necessário na sua implantação. Todos os componentes podem ser parte da sua Instalação do Windows Server 2008, permitindo que você aplique personalizações de forma consistente em todos os seus servidores Web. Não há a necessidade de linhas de comando ou edição de arquivos de configuração.

Você pode até mesmo criar um DVD personalizado para instalações totalmente autônomas. O AIK inclui documentação e ferramentas para criar um arquivo AutoUnattend.xml, que você, em seguida, coloca na pasta raiz do DVD. O arquivo Custom Image Deployment.htm no material complementar oferece instruções passo a passo.

Vários administradores também concordam que a compatibilidade é uma melhoria-chave. Eu esperava encontrar alguns problemas de compatibilidade com o DotNetNuke e osCommerce, mas a transição para o IIS 7.0 foi bem tranqüila, apesar do fato de que esses dois aplicativos Web incluem recursos avançados, como autenticação de formulário e URLs de mecanismo de pesquisa amigáveis.

Com o DotNetNuke, não encontrei nenhum problema até que passei para um cenário de farm da Web complexo com compartilhamento de conteúdo UNC em uma plataforma de 64 bits. O problema, no entanto, foi pouco relevante. No final das contas, essa compatibilidade aprimorada significa que menos tempo é necessário para colocar seus aplicativos Web em execução no IIS 7.0.

Se, por acaso, você encontrar problemas de compatibilidade com seus aplicativos Web, o diagnóstico interno e o suporte a rastreamento rapidamente se tornarão um dos seus recursos novos favoritos. As informações detalhadas de diagnóstico são muito significativas e os caminhos de solução sugeridos são úteis e realmente funcionam.

A Figura 4 mostra as informações de diagnóstico que você obtém ao executar o DotNetNuke 4.7 no IIS 7.0 no modo integrado. Neste exemplo, existem três opções (exibidas na seção "Coisas que você pode tentar"). Alterar o aplicativo para suportar o modo integrado é provavelmente a melhor escolha para desenvolvedores do DotNetNuke. Ignorar o erro é provavelmente uma má idéia. Eu gosto da terceira opção, habilitar o modo clássico alternando o aplicativo Web para o AppPool clássico do .NET, porque quero executar o DotNetNuke 4.7 inalterado no IIS 7.0.

fig04.gif

Figura 4 Informações de diagnóstico para DotNetNuke em execução no modo integrado (Clique na imagem para ampliá-la)

Arquitetura do IIS

Você pode estar pensando o que esses modos integrado e clássico são e por que eles afetam o aplicativo ASP.NET (DotNetNuke), mas não o aplicativo PHP (osCommerce). Para compreender melhor isso, você primeiro deve dar uma olhada na arquitetura do IIS 7.0. Versões anteriores integram o runtime do ASP.NET no servidor Web principal, principalmente por uma extensão ISAPI (aspnet_isapi.dll). O IIS 7.0, por outro lado, permite que módulos ASP.NET se conectem diretamente no servidor Web principal por meio de um módulo HTTP de nível global chamado ManagedEngine, que carrega a DLL de suporte do ASP.NET (webengine.dll) no pipeline de processamento de solicitação do IIS 7.0.

Módulos nativos usam a API de Server Core da Web do IIS para se registrarem em eventos específicos no pipeline, como BeginRequest, AuthenticateRequest, AuthorizeRequest e ExecuteRequestHandler. ManagedEngine fornece o suporte necessário para integrar módulos ASP.NET no pipeline de solicitação também. Com essa nova arquitetura, o IIS 7.0 pode invocar módulos nativos e do ASP.NET em qualquer estágio, durante o processamento da solicitação, independentemente do tipo de conteúdo solicitado.

Como exemplo, vamos considerar a autenticação do usuário do ASP.NET. No IIS 6.0, é possível para um módulo HTTP baseado em ASP.NET se registrar para eventos OnAuthenticate (como FormsAuthentication.OnAuthenticate e WindowsAuthentication.OnAuthenticate) para definir a identidade do usuário no HttpContext atual. Isso funciona muito bem dentro do runtime do ASP.NET, mas você não pode usar esse código do ASP.NET para proteger recursos expostos por meio de um aplicativo Web baseado em PHP.

De acordo com a configuração do seu mapa de script, o IIS 6.0 encaminha solicitações para os tipos de conteúdo do ASP.NET a aspnet_isapi.dll, mas ele não encaminha solicitações para tipos de conteúdo PHP à extensão ISAPI para o ASP.NET. Afinal, o ASP.NET não processa códigos PHP, mas isso também significa que o código de autenticação do ASP.NET não é executado se uma página PHP for solicitada. portanto, com o IIS 6.0, você precisa duplicar a lógica de autenticação porque aplicativos PHP devem implementar seus próprios mecanismos de autenticação.

O IIS 7.0 usa um modelo de processamento acionado por evento que suporta a combinação e a correspondência de módulos individuais no pipeline de solicitação. Entre outros componentes, o IIS 7.0 acompanha módulos gerenciados WindowsAuthentication e FormsAuthentication que geram eventos OnAuthenticate quando o pipeline de solicitação dispara o evento AuthenticateRequest. Você pode agora possuir um módulo nativo, como RequestFilteringModule ou IpRestrictionModule, manipular o evento BeginRequest para recusar solicitações críticas o mais cedo possível e, em seguida, executar código de autenticação do ASP.NET personalizado no evento AuthenticateRequest e fazer com que FastCgiModule execute o mecanismo de script PHP (php-cgi.exe) no evento ExecuteRequestHandler para processar páginas PHP.

O resultado dessa arquitetura integrada é que desenvolvedores da Web não precisam duplicar códigos para implementar uma lógica de negócios comum. Você pode usar código de autenticação do ASP.NET personalizado para proteger todos os seus recursos do IIS, incluindo aplicativos PHP. E você pode executar outras tarefas de pré e pós-processamento por meio de módulos do ASP.NET, como a reconfiguração de URL, o rastreamento personalizado e o log de erros.

Modos clássico e integrado

O efeito colateral causado por essa nova arquitetura é que aplicativos ASP.NET existentes podem requerer alterações de código e configuração que devem ser executadas por desenvolvedores de aplicativos para garantir que as alterações não levem a conflitos de módulos no pipeline de solicitação. Mas, se você não puder conduzir imediatamente um aplicativo Web existente, pode habilitar o modo clássico no pool de aplicativos que o processo de trabalho usa para executar o aplicativo Web. O IIS 7.0 não carrega o ManagedEngine nos processos de trabalho do modo clássico, o que implica, neste caso, que o pipeline de solicitação não pode resolver ou invocar módulos ASP.NET. Em vez disso, o IIS 7.0 ativa um número de manipuladores ISAPI, baseados em IsapiModule (aspnet_isapi.dll), para processar tipos de conteúdo ASP.NET similares ao IIS 6.0. Você poderá ver isso, se analisar a seção de manipuladores em system.webServer no arquivo applicationHost.config, que pode encontrar por padrão na pasta %WinDir%\System32\InetSrv\Config.

Procure a cadeia de caracteres aspx, como exemplo, e você encontrará uma entrada apontando para PageHandlerFactory-Integrated (carregado nos processos de trabalho do pool de aplicativos do modo integrado, de acordo com a configuração preCondition="integratedMode") e outras entradas apontando para PageHandlerFactory-ISAPI-2.0 e PageHandlerFactory-ISAPI-2.0-64 (carregados nos processos de trabalho do pool de aplicativos do modo clássico, de acordo com a configuração preCondition="classicMode").

Como o modo de pipeline está definido no nível do pool de aplicativos, o IIS 7.0 pode executar aplicativos Web nos modos integrado e clássico simultaneamente. E os processos de trabalho apenas precisam ser executados em diferentes pools de aplicativos, mas podem ser hospedados no mesmo servidor.

Tenha em mente que os modos integrado e clássico afetam apenas como o IIS 7.0 integra o ASP.NET no pipeline de solicitação. Esses modos de pipeline não afetam aplicativos PHP diretamente. O FastCgiModule e todos os outros módulos nativos são carregados sem pré-condições do modo pipeline nos modos integrado e clássico. FastCGI é a interface preferida para executar o mecanismo de script PHP no IIS 7.0. Em vez de usar FastCGI, você também pode criar um mapeamento de manipulador para o mecanismo de script PHP por CGI ou pode usar o IsapiModule em conjunto com PHP-ISAPI (php4isapi.dll).

Eu, no entanto, considero essas alternativas de configuração de estilo do IIS 6.0 ultrapassadas, agora que o FastCGI oferece desempenho e estabilidade substancialmente aprimorados. O CGI é mais lento, pois o IIS deve inicializar um novo processo de CGI para cada solicitação de HTTP enquanto o FastCGI reutiliza processos CGI para várias solicitações. O ISAPI requer uma compilação segura para thread, que envolve mais sobrecarga do que executar PHP não seguro para thread.

Talvez, ainda mais importante, nem todas as extensões PHP estejam disponíveis em uma versão segura para thread, e executar extensões não seguras para thread com ISAPI seja uma má idéia porque pode causar problemas de estabilidade no servidor. O FastCGI, por outro lado, é um ambiente de uma única simultaneidade como o CGI. Usado para executar PHP não seguro para thread, o FastCGI é estável e rápido e é claramente a melhor maneira para se usar com PHP 5 no IIS 7.0. Ele também está disponível no IIS 6.0, se você ainda não estiver pronto para uma transição para o IIS 7.0.

Módulos e funcionalidade

O IIS 7.0 apresenta uma arquitetura altamente modularizada — ou, como o desenvolvedor do IIS diz, um conjunto de recursos dividido em componentes. Isso é uma boa notícia para os administradores da Web que desejam manter a superfície da memória e do ataque do IIS 7.0 o menor possível. Habilitando diferentes módulos ou talvez, até mesmo, substituindo módulos padrão por módulos personalizados, você pode obter o controle total sobre os recursos do IIS 7.0 nos seus servidores Web.

Para executar o ASP.NET no modo integrado ou clássico, bem como aplicativos PHP no mesmo servidor, você deve instalar, como mínimo, a função do servidor Web e os módulos principais para suportar o processamento de solicitação, a configuração do servidor, ASP.NET, ISAPI e CGI (que inclui o módulo FastCGI). Isso pode ser feito com a seguinte linha de 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

Eu geralmente prefiro instalar o IIS 7.0 com todas as opções disponíveis no meu servidor de preparação para garantir que todos os componentes e ferramentas administrativas estejam disponíveis para colocar meus aplicativos Web em funcionamento rapidamente. Minha estratégia é verificar se as coisas estão funcionando e, então, eu restrinjo a configuração desinstalando serviços de função e desabilitando módulos. Quando um aplicativo Web começa a não funcionar direito, eu adiciono serviços de função de apoio ou módulos que removi.

Você também tem a opção de usar o Gerenciador de Pacotes (pkgmgr.exe) ou a ferramenta de linha de comando do IIS 7.0 (appcmd.exe) ou editar a seção globalModules no arquivo applicationHost.config diretamente, mas eu considero as ferramentas gráficas muito convenientes. Tenha em mente que alguns módulos, como RequestFilteringModule e StaticCompressionModule, são bem úteis, mesmo que não sejam — a rigor — necessários para seus aplicativos Web serem executados. Se você desinstalar um módulo necessário para um pool de aplicativos, você receberá um erro de HTTP ao acessar seu aplicativo Web, como ilustrado na Figura 5.

fig05.gif

Figura 5 Um aplicativo ASP.NET não será executado no modo clássico porque IsapiModule está faltando (Clique na imagem para ampliá-la)

Observação: como uma prática recomendada, certifique-se de que o mesmo conjunto de módulos esteja instalado e habilitado em todos os seus servidores do IIS 7.0. Para verificar os componentes instalados, vá para HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ e verifique as chaves do Registro. Um valor REG_DWORD de 0000 0001 para uma chave do Registro, como para NetFxEnvironment ou CGI, indica que o componente correspondente está instalado.

Migração de aplicativo Web

Chega de teoria, agora é hora de arregaçar as mangas e mover alguns aplicativos Web para o IIS 7.0. Como mencionei anteriormente, meu servidor de preparação executa o IIS 7.0 com todos os componentes disponíveis e PHP 5 não seguro para thread registrado com FastCGI. Antes de começar, preciso fazer algumas perguntas básicas:

  • O aplicativo Web requer um sistema de gerenciamento de banco de dados, como SQL Server ou MySQL?
  • Eu preciso instalar ou configurar componentes adicionais, como conexões ODBC, objetos COM ou certificados SSL?
  • O aplicativo Web requer contas de serviço especiais e permissões de acesso remoto ou local elevadas para compartilhamentos de arquivos e outros recursos?
  • Existe alguma dependência de recursos específicos da plataforma indisponíveis no IIS 7.0, como dependências do módulo Apache para reconfiguração de URL (mod_rewrite)?

Fazer perguntas como essas ajudará a colocar seus aplicativos Web em execução no IIS 7.0 mais rapidamente. Por exemplo, se você estiver tentando migrar um aplicativo PHP do Apache 2.2 que usa mod_rewrite (digamos, para um mecanismo de pesquisa amigável ou para impedir o seqüestro de largura de banda por imagens vinculadas), terá problemas até implementar uma solução de reconfiguração de URL personalizada compatível no IIS 7.0. Felizmente, o osCommerce não requer funcionalidade mod_rewrite no IIS 7.0, mas alguns pacotes de otimização de mecanismo de pesquisa podem exigir.

Agora que determinei e instalei os componentes adicionais necessários no servidor de preparação, estou pronto para colocar meus aplicativos Web em funcionamento. Novamente, existem algumas coisas que quero perguntar a mim mesmo:

  • Qual é a configuração mais simples que posso usar para suportar o aplicativo Web?
  • Que configuração é usada atualmente no ambiente de produção?
  • Posso otimizar a configuração do aplicativo Web na nova plataforma?
  • Qual é o conjunto mínimo de serviços de função e módulos que o aplicativo Web precisa para funcionar na configuração desejada?

Colocar o aplicativo Web em execução na configuração mais simples é uma forma rápida de certificar-se de que ele funciona. Se tudo der certo, é hora de aplicar uma configuração similar ao ambiente de produção existente e importar os dados de produção nos bancos de dados de teste. É claro que alguns problemas podem apenas surgir em configurações avançadas.

Você pode notar também oportunidades para melhorias ao fazer o espelhamento da sua configuração de produção em um laboratório de teste. Colocar o arquivo applicationHost.config em um compartilhamento UNC é uma ótima maneira de centralizar a configuração de vários servidores Web. Para aumentar a tolerância a falhas pela redundância e sincronização de conteúdo, considere a implementação de replicação de Sistema de Arquivos Distribuído (DFS), que é um mecanismo de replicação multimestre baseado em estado disponível com o Windows Server 2003 R2 e Windows Server 2008. Você pode também minimizar os requisitos de armazenamento em front-ends da Web colocando os arquivos de conteúdo dos seus aplicativos Web em compartilhamentos UNC.

Outras otimizações possíveis podem envolver segurança ou cache dinâmico. Eu não resolvi otimizações de segurança e desempenho no meu laboratório de teste porque isso está além do escopo deste artigo. Nem configurei DFS para evitar a instalação de mais servidores. As instruções passo a passo no material complementar fornecem um exemplo simplificado de como hospedar o arquivo applicationHost.config e conteúdo da Web em compartilhamentos UNC. E a Figura 6 ilustra como implementar uma farm da Web baseada em UNC com o DFS.

fig06.gif

Figura 6 Implantação de farm da Web com arquivo applicationHost.config e conteúdo da Web em compartilhamentos UNC (Clique na imagem para ampliá-la)

Conclusão

O IIS 7.0 é uma plataforma de servidor Web impressionante. Ele apresenta uma arquitetura básica reprojetada, ao mesmo tempo em que mantém aproximadamente 100% de compatibilidade com a versão anterior IIS 6.0. Ele deve poder executar a maioria dos aplicativos Web ASP.NET existentes sem modificação. Mas, devido à extensão das alterações na arquitetura, não é possível supor que você não encontrará problemas de compatibilidade.

Esteja você migrando aplicativos Web ASP.NET ou PHP para o IIS 7.0, é melhor assumir uma abordagem de preparação com ênfase no planejamento adequado, na preparação, nos testes e na documentação de códigos e alterações de configuração.

O IIS 7.0 vale o trabalho envolvido. Existem várias melhorias em áreas como segurança, desempenho, configuração e flexibilidade. Seria necessário um livro todo para discutir todas elas. A configuração centralizada e o compartilhamento de conteúdo com base em compartilhamentos UNC, a configuração delegada por meio de arquivos web.config em diretórios de aplicativos, ferramentas de gerenciamento aprimoradas, informações detalhadas de diagnóstico e rastreamento de solicitação com falha e o cache de saída dinâmico são maneiras certeiras de ganhar os corações dos administradores da Web.

O recurso de combinar módulos nativos e gerenciados no pipeline de processamento de solicitação beneficia os desenvolvedores de ASP.NET. E as melhorias no desempenho e na estabilidade que acompanham o FastCGI no IIS 7.0 são notícias excelentes para desenvolvedores de aplicativos PHP.

E há mais uma coisa importante que ajuda os profissionais de TI a obterem sucesso com o IIS 7.0: o portal da comunidade do IIS da Microsoft (www.iis.net). Ele contém todas as informações de que você precisa, incluindo artigos detalhados sobre a nova arquitetura, código-fonte para desenvolvedores de C++ e ASP.NET, demonstrando como criar módulos do IIS 7.0, e instruções passo a passo para colocar os aplicativos PHP em funcionamento. Você definitivamente irá querer visitar esse site. É uma boa primeira parada para obter respostas para suas perguntas relacionadas ao IIS.

Fergus Strachan é fundador e diretor da Maestra Ltd London, uma firma de consultoria especializada em design de infra-estrutura de TI e suporte a gerenciamento de projetos, que atende bancos internacionais e instituições educacionais do Reino Unido. Ele escreve artigos sobre a tecnologia de servidor da Microsoft e é autor do livro Integrating ISA Server 2006 with Microsoft Exchange 2007 (Integrando o ISA Server 2006 com o Microsoft Exchange 2007). Ele também é co-autor do livro Microsoft Exchange Server 2003 Resource Kit (Kit de Recursos do Microsoft Exchange Server 2003).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.