Después de pasarme más de tres días intentando resolver una incidencia al configurar WebDeploy en un Azure WebRole –concretamente añadiendo dicha característica al DNN Azure Accelerator-, no me queda más remedio que documentar y compartir la solución para aliviar el sufrimiento a quien le pueda suceder algo parecido.
¿Para qué WebDeploy?
Web Deploy simplifica el despliegue de aplicaciones y sitios web en servidores IIS. Se puede usar para sincronizar servidores IIS o migrar a nuevas versiones del mismo –por ejemplo, migrar de un entorno on-premise a la nube o viceversa.
Permite realizar operaciones de empaquetado y despliegue de aplicaciones web de una manera sencilla, integrándose perfectamente con herramientas como Visual Studio o WebMatrix para ayudar a los desarrolladores en esta tarea. Se pueden empaquetar tanto contenido de las aplicaciones, configuración, bases de datos y cualquier otro artefacto como entradas en el registro, objetos COM, ensamblados en la GAC etc. pudiéndose parametrizar los valores de configuración según entorno. Una vez empaquetados estos paquetes se pueden utilizar usando una aplicación de comandos de Web Deploy o IIS Manager sin requerir privilegios administrativos.
Con la salida de Web Deploy 3.0, tenemos una serie de interesantes características:
- Migración de servidores web desde IIS6 a IIS 7 o IIS 8
- Sincronización eficiente de tu granja de servidores
- Integración con Visual Studio y WebMatrix
- Integración con Web Platform Installer para instalar aplicaciones web de la comunidad
- Empaquetado de aplicaciones web, incluyendo las bases de datos asociadas, ACLs, COM, GAC, etc.
- Despliegue de aplicaciones web sin requerir permisos administrativos, pudiendo parametrizar la configuración en cada entorno, así como integración con el IIS Web Management Service (WMSVC) para despliegue remoto por usuarios no administradores
- Sincronización y migración de servidores web, sincronizando sólo los datos que han sido modificados
- Copia de seguridad automática de los sitios web antes de realizar ningún cambio
- Acceso a través de IIS Manager, Visual Studio, WebMatrix, línea de comandos, PowerShell Cmdlets y APIs.
¿Por qué en el DNN Azure Accelerator?
Como os podéis imaginar, añadir esta característica al DNN Azure Accelerator va a permitir realizar una serie de tareas administrativas no disponibles hasta ahora. Se me vienen a la mente unas cuantas, aunque por nombrar algunas:
- Posibilidad de migrar la instancia de DNN de un IIS a otro. Esto incluye migrar desde on-premise a Azure –ya sea Azure WebSites o PaaS-, de Azure WebSites a Azure PaaS ó viceversa, etc.
- Acceder y modificar el contenido del site a través de WebMatrix, ¡sin tener que acceder por RDP a las instancias en Azure ni tener que montar el VHD drive con Azure Connect!
- Instalar actualizaciones de DotNetNuke, simplemente desplegando el paquete de upgrade a través de WebDeploy y ejecutando el asistente de actualización
- Crear y restaurar copias de seguridad de nuestro sitio
Como véis, son unas buenas razones para añadir esta característica, que estará disponible en la próxima release del asistente de DNN Azure Accelerator –el código ya está disponible en CodePlex por si no quieres esperar al empaquetado.
¿Tres días para añadir esta característica?
No sólo tres días sino además unos 50 despliegues para poner en funcionamiento la misma, debido a había Luna llena en Aries y dos errores muy interesantes.
Pero antes que nada, echemos un vistazo a cómo está implementado. Para añadir esta característica sin disparar una línea de código –sin contar los cambios de interfaz en el asistente de instalación-, el enfoque fue el siguiente:
- Añadir un EndPoint en los web roles para permitir el tráfico a través del puerto 8172
- Incorporar la aplicación de comandos de Web Platform Installer WebPICMD.exe en una startup task del webrole, para automatizar la instalación de WebDeploy. Esto permite, además de no incrementar el tamaño del paquete de servicio del Accelerator, instalar del mismo modo cualquier otro paquete disponible y que requiera nuestro despliegue, como MVC3, Silverlight, node.js, etc.
- Habilitar el servicio de administración remota de IIS en una startup task del webrole
Problema nº1: Web Platform Installer no consigue instalar el paquete de WebDeploy
Tras intentar instalar el paquete de WebDeploy con una instrucción como la siguiente, el webrole se quedaba ciclado por un error en la ejecución de la tarea:
1: ~dp0WebPICMD.exe /Install /Products:WDeploy /AcceptEULA
Después de añadir los correspondientes logs siguiendo las buenas prácticas, el problema se trataba de que al intentar descomprimir los paquetes de instalación una vez que se han descargado, da un error. Este error es debido a que las tareas elevadas se ejecutan como “NT AUTHORITYSYSTEM”, cuya carpeta de perfil de usuario se encuentra bajo el directorio “system32”. Esto es especial, ya que en máquinas de 64bits (como todas las VMs de Windows Azure), los procesos de 64bits ven esta carpeta, pero los procesos de 32bits ven la carpeta “SysWOW64). Los paquetes de WebDeploy se descargan en la carpeta “system32” al ser WebPICMD.exe de 64bits, pero algunas dependencias usan un ejecutable auto-extraible de 32bits, dando origen al error descrito.
Para solucionar este error, la única referencia en la web es la de nuestro Ángel de la Guarda Steve Marx en el post “Windows Azure Startup Tasks Tips and Tricks”, donde se da más detalle del mismo.
De este modo, la solución al problema 1 es cambiar en la registry la ubicación de esta carpeta antes de ejecutar la instalación y dejarla como estaba después de la misma. Quedaría de la siguiente forma:
1: md "%~dp0appdata"
2: reg add "hku.defaultsoftwaremicrosoftwindowscurrentversionexploreruser shell folders" /v "Local AppData" /t REG_EXPAND_SZ /d "%~dp0appdata" /f
3: "%~dp0webpicmd" /Install /Products:WDeploy /AcceptEula >>log.txt 2>>err.txt
4: reg add "hku.defaultsoftwaremicrosoftwindowscurrentversionexploreruser shell folders"/v "Local AppData" /t REG_EXPAND_SZ /d %%USERPROFILE%%AppDataLocal /f
La segunda tarea de instalar el servicio de administración remota era muy sencilla, simplemente habilitar esta característica en la VM y arrancar el servicio, no sin antes tocar algún parámetro en el registro de Windows:
1: start /w ocsetup IIS-ManagementService
2: reg add HKEY_LOCAL_MACHINESOFTWAREMicrosoftWebManagementServer /v EnableRemoteManagement /t REG_DWORD /d 1 /f
3: net start wmsvc
Problema nº2: al intentar conectar a través de WebMatrix desde dentro o fuera de la VM, aparece el error “Unable to establish connection”
Este fue muy “gracioso”, por el número de horas que tuve que dedicarle el fin de semana y por los más de otros 30 despliegues más probando otras alternativas. Digo gracioso por cuál fue la solución.
El síntoma era que una vez que las startup tasks realizaron su trabajo (el puerto 8172 abierto, se instaló correctamente WebDeploy y estaba habilitado el servicio IIS Remote Management), al intentar conectar a través de WebMatrix, me aparecía el warning de advertencia de que no confiaba en el certificado del servidor –cosa totalmente correcta-, pero a continuación me aparecía el mensaje “Unable to establish connection”:
El puerto 8172 abierto, las credenciales correctas, el nombre del sitio correcto –nótese que desde esta release el site en IIS se denomina “DotNetNuke”-, la URL correcta y nombre de servidor correctos. ¿Qué fallaba?
Después de intentar ver algo en el visor de sucesos remoto, comenzar a utilizar artillería –PSTools, Fiddler, etc.- nada concluyente. La única información diferente era la otorgada por la aplicación de consola “msdeploy.exe”, devolviendo el código de error “ERROR_DESTINATION_NOT_REACHABLE” seguido de un precioso “404 Not Found”.
Sin más información ni nada interesante tras dos días de búsqueda por foros técnicos, casi da vergüenza comentar la solución.
La solución al problema 2 es simplemente cambiar el orden de las startup tasks, esto es, instalar primero IIS Management Service y a continuación instalar Web Deploy. Parece que al contrario, Web Deploy no se registra correctamente y hay que reinstalarlo.
La conclusión mereció un tweet:
Conclusión
Espero que sirva de ayuda, tanto la nueva característica de WebDeploy en el DNN Azure Accelerator como las soluciones a los problemas encontrados. En breve estará todo empaquetado en una nueva release con muchas novedades aparte de esta.
Un saludo y happy coding!
