Hoy aprendí algunas cosas más al continuar con mis aventuras de desarrollo ASP.NET en Windows Vista. Muchas de estas cosas aparentemente no son nuevas, vienen desde IIS 6 que era la versión incluida con Windows Server 2003, pero yo nunca los usé, así que hasta ahora me vengo enterando.
La primer lección salió cuando andaba buscando el usuario ASPNET de mi máquina para asignarle permisos de escritura sobre un directorio donde mi aplicación permite que los usuarios suban archivos. Después de un rato de jugar Where's Waldo con el usuario, me convencí que simplemente no existía. Resulta que el ASP.NET Worker Process—el proceso bajo el cual se ejecuta el código de ASP.NET—corre ahora por default bajo la cuenta NETWORK SERVICE (aunque esto se puede cambiar fácilmente). Ah, y por cierto, el Worker Process ahora se llama w3wp.exe, en lugar de aspnet_wp.exe.
La segunda lección vino cuando quise correr mi aplicación. Resulta que si usas módulos HTTP (<httpModules>) en tu web.config, recibirás un mensaje de error porque IIS 7 intenta correr las aplicaciones por default en un Application Pool llamado—duh—DefaultAppPool, y éste tiene un Managed Pipeline Mode puesto a Integrated.
¿Güat? A ver si me puedo explicar. Si abres la consola administrativa de IIS y te vas a Application Pools, verás algo como esto:
De cajón, Vista traía los dos primeros—Classic .NET AppPool y DefaultAppPool. El tercero fue creado cuando instalé SQL Server Reporting Services, así que por ahora ignóralo.
Lo primero que me pregunté fue ¿qué $#!N&@2 demonios es eso de los Application Pools?
Resulta que es una manera muy padre de segregar y asignar una aplicación Web—o más correctamente su Application Domain—a un Worker Process determinado. Un Pool puede tener varios AppDomains, y estos estarán separados de los que corran en otros pools. Considera este ejemplo:
Aquí tenemos tres aplicaciones de ASP.NET, cada una con su directorio virtual. Las primeras dos están asignadas al primer Application Pool, y la tercera aplicación está asignada al segundo. Esto es EXCELENTE por varias razones:
¿Que pasaba antes si una falla en una de las aplicaciones web hacía que se reciclara el Worker Process? Pues todas las aplicaciones se "reiniciaban"—botando posiblemente a las sesiones y todo el show—porque los Application Domains están corriendo en el mismo proceso ejecutable. Me ha pasado. Teníamos una applicación Web corriendo en el mismo servidor que un servicio Web (en una máquina con Windows 2000 si mal no recuerdo), y de vez en cuando la aplicación hacía que se reciclara el Worker Process—maldito Crystal Reports—llevándose entre las patas al Web Service. Ahora es posible asilar ese tipo de fallas.
¿O qué pasaría si quiero correr una aplicación de ASP.NET v1.x en el mismo servidor que una de ASP.NET v2.x? Un Worker Process solo puede correr una versión del .NET Framework, hasta donde sé, así que con Application Pools ahora puedes lograrlo.
Y más relevante para el problema que yo tenía, IIS 7 tiene una manera distinta de manejar los httpModules—llamado Managed Pipeline Mode. DefaultAppPool usa Integrated. Así que lo que tenía que hacer en mi caso era asignar el directorio virtual de mi aplicación al Classic .NET AppPool que utiliza el modo Classic, para no tener que cambiar la configuración (y posiblemente código) de mi aplicación.
Si inspeccionas las opciones avanzadas de un Application Pool te das cuenta que puedes configurar cosas interesantes.
Las que me llamaron la atención fueron:
- .NET Framework Version. Para seleccionar qué versión quieres utilizar para las aplicaciones Web que corren en el Pool, o si no quieres permitir que corra código administrado (p.ej. una aplicación de ASP clásico o PHP que no tenga nada que ver con .NET).
- Managed Pipeline Mode. Integrated utiliza el modo IIS 7, donde la configuración de los httpModules están centralizados y supuestamente tiene varios beneficios que aún no conozco; Classic permite que cada aplicación web mantenga su configuración.
- Identity. La cuenta de usuario y bajo el cual corre el Worker Process. Esto afecta directamente los permisos de seguridad de las aplicaciones en el Pool. Los valores posibles son: NetworkService, LocalService, LocalSystem, SpecificUser; este último por si quieres especificar una cuenta creada por ti.
- Identity Specific User Credentials. Para poner las "credenciales" (el password pues) del usuario si usas Identity=SpecificUser.
- CPU Limit, Limit Interval y Limit Action. Sirven para limitar el porcentaje de CPU que consume el Worker Process en un tiempo determinado y hacer algo si se excede, como por ejemplo, matarlo.
- Private Memory Limit y Virtual Memory Limit. Sirven para limitar la memoria real y virtual que utiliza el Worker Process. ¿Alguna vez le has pegado a un System.OutOfMemoryException? Yo si, y no es divertido.
Una vez que comencé a entender este rollo, asignar mi aplicación al Pool correcto fue súper sencillo. Simplemente te vas a las opciones avanzadas de tu directorio virtual y lo cambias.
Enjoy
Por RSS o Atom
Por e-mail
