Elegir el enfoque adecuado para la implementación web

por Jason Lee

Al trabajar con la herramienta de implementación web (Web Deploy) de Internet Information Services (IIS) 2.0 o versiones posteriores, hay tres enfoques principales que puede usar para obtener las aplicaciones web empaquetadas en un servidor web. Puede:

• Implementar la aplicación desde una ubicación remota mediante el destino del Servicio Agente de implementación web (también conocido como "agente remoto") en el servidor de destino.
• Implemente la aplicación desde una ubicación remota mediante Web Deploy a petición (también conocido como "agente temporal").
• Implemente la aplicación desde una ubicación remota mediante el destino del controlador de Web Deploy de IIS en el servidor de destino.
• Implemente la aplicación mediante la copia manual del paquete web en el servidor de destino e impórtela mediante el Administrador de IIS.

La configuración de los servidores web de destino dependerá del enfoque de implementación que quiera usar. Este tema le ayudará a decidir qué enfoque de implementación es adecuado para usted.

En esta tabla se muestran las principales ventajas y desventajas de cada enfoque de implementación, junto con los escenarios que suelen adaptarse a cada enfoque.

Enfoque	Ventajas	Inconvenientes	Escenarios típicos
Agente remoto	Es fácil de configurar. Es adecuado para las actualizaciones periódicas de las aplicaciones web y del contenido.	El usuario debe ser administrador en el servidor de destino. El usuario no puede proporcionar credenciales alternativas.	Entornos de desarrollo. Entornos de prueba.
Agente temporal	No es necesario instalar Web Deploy en el equipo de destino. La versión más reciente de Web Deploy se usa automáticamente.	El usuario debe ser administrador en el servidor de destino. El usuario no puede proporcionar credenciales alternativas.	Entornos de desarrollo. Entornos de prueba.
Controlador de Web Deploy	Los usuarios que no son administradores pueden implementar el contenido. Es adecuado para las actualizaciones periódicas de las aplicaciones web y del contenido.	Es mucho más complejo de configurar.	Entornos de ensayo. Entornos de producción de intranet. Entornos hospedados.
Implementación sin conexión	Es fácil de configurar. Es adecuado para entornos aislados.	El administrador del servidor debe copiar e importar manualmente el paquete web cada vez.	Entornos de producción accesibles desde Internet. Entornos de red aislados.

Uso del agente remoto

Al instalar Web Deploy con la configuración predeterminada en un servidor de destino, el Servicio Agente de implementación web (el "agente remoto") se instala e inicia automáticamente. De forma predeterminada, el agente remoto expone un punto de conexión HTTP en esta dirección:

http://[server]/MSDEPLOYAGENTSERVICE

Nota:

Puede reemplazar [servidor] por el nombre de equipo del servidor web, una dirección IP para el servidor web o un nombre de host que se resuelva en el servidor web.

Los administradores del servidor pueden implementar paquetes web desde una ubicación remota, como una máquina para desarrolladores o un servidor de compilación, especificando esta dirección de punto de conexión. Por ejemplo, supongamos que Matt Hink en Fabrikam, Inc. ha creado el proyecto de aplicación web de ContactManager.Mvc en su máquina para desarrolladores. El proceso de compilación genera un paquete web, junto con un archivo .deploy.cmd que contiene los comandos de Web Deploy necesarios para instalar el paquete. Si Matt es administrador del servidor en el servidor de TESTWEB1, puede implementar la aplicación web en el servidor web de prueba; para ello, ejecute este comando en su máquina para desarrolladores:

ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM

De hecho, el ejecutable de Web Deploy puede deducir la dirección del punto de conexión del agente remoto si proporciona el nombre de la máquina, por lo que Matt solo necesita escribir esto:

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /a:NTLM

Nota:

Para más información sobre la sintaxis en línea de comandos y los archivos .deploy.cmd de Web Deploy, consulte Procedimiento: Instalación de un paquete de implementación mediante el archivo deploy.cmd.

El agente remoto ofrece una manera sencilla de implementar contenido desde una ubicación remota y este enfoque puede funcionar bien con una implementación automatizada o con un solo clic. Sin embargo, el usuario que ejecuta el comando de implementación también debe ser un administrador de dominio o miembro del grupo de administradores locales en el servidor de destino. Además, el agente remoto no admite la autenticación básica, por lo que no puede pasar credenciales alternativas en la línea de comandos.

El agente remoto proporciona un enfoque útil para la implantación en escenarios de desarrollo o pruebas, en los que no es infrecuente que los desarrolladores tengan pleno control de administrador sobre un entorno de servidor de pruebas, y las aplicaciones suelen recompilarse y volverse a implementar con mucha frecuencia. Sin embargo, este enfoque suele ser menos aceptable para entornos de ensayo o producción.

Para obtener un ejemplo completo de un escenario que usa el enfoque del agente remoto, consulte Escenario: Configuración de un entorno de prueba para la implementación web.

Uso del agente temporal

El enfoque del agente temporal para la implementación es similar al enfoque del agente remoto. Sin embargo, a diferencia del enfoque del agente remoto, no es necesario instalar Web Deploy en el servidor web de destino. En su lugar, al realizar la implementación, Web Deploy instalará una versión temporal del Servicio Agente de implementación web en el servidor de destino y lo usará para implementar el contenido en IIS. Una vez completada la implementación, se quitan todos los archivos temporales.

Si quiere usar la configuración del proveedor de agente temporal, agregue la marca /g al comando de implementación:

ContactManager.Mvc.deploy.cmd /y /m:TESTWEB1 /g:true

Nota:

No puede usar el agente temporal si el Servicio Agente de implementación web está instalado en el equipo de destino, incluso si el servicio no se está ejecutando.

La ventaja de este enfoque es que no es necesario mantener las instalaciones de Web Deploy en los servidores de destino. Además, no es necesario asegurarse de que los equipos de origen y destino ejecutan la misma versión de Web Deploy. Sin embargo, este enfoque sufre las mismas limitaciones de la entidad de seguridad que el enfoque del agente remoto, es decir, que debe ser administrador local en el servidor de destino para implementar contenido y solo se admite la autenticación NTLM. El enfoque del agente temporal también requiere una configuración mucho más inicial del entorno de destino.

Para más información sobre el uso del agente temporal, consulte Procedimiento: Instalación de un paquete de implementación mediante el archivo deploy.cmd y Web Deploy a petición.

Uso del controlador de Web Deploy

Para IIS 7 en adelante, Web Deploy ofrece un enfoque de implementación alternativo a través del controlador de Web Deploy de IIS. El controlador de Web Deploy está estrechamente integrado con el Servicio de administración web de IIS (WMSvc), que está diseñado para permitir a los usuarios administrar sitios web de IIS desde ubicaciones remotas.

De forma predeterminada, el agente remoto expone un punto de conexión HTTP en esta dirección:

https://[server]:8172/MSDeploy.axd

Nota:

Puede reemplazar [servidor] por el nombre de equipo del servidor web, una dirección IP para el servidor web o un nombre de host que se resuelva en el servidor web.

La gran ventaja del controlador de Web Deploy a través del agente remoto, y el agente temporal, es que puede configurar IIS para permitir que los usuarios que no son administradores implementen aplicaciones y contenido en sitios web de IIS específicos. El controlador Web Deploy también admite la autenticación básica, por lo que puede proporcionar credenciales alternativas como parámetros en los comandos de Web Deploy. El principal inconveniente es que el controlador de Web Deploy es inicialmente mucho más complicado de instalar y configurar.

En el caso de los usuarios que no son administradores, el Servicio de administración web (WMSvc) solo permitirá al usuario conectarse a IIS mediante una conexión de nivel de sitio, en lugar de una conexión de nivel de servidor. Para acceder a un sitio determinado, puede incluir una cadena de consulta específica del sitio en la dirección del punto de conexión:

https://[server]:8172/MSDeploy.axd?site=DemoSite

Sugerencia Por ejemplo, suponga que un proceso de compilación está configurado para implementar automáticamente una aplicación web en un entorno de ensayo después de cada compilación correcta. Si usó el enfoque del agente remoto, tendría que convertir la identidad del proceso de compilación en un administrador en los servidores de destino. Por el contrario, con el enfoque del controlador de Web Deploy puede conceder a un usuario no administrador (FABRIKAM\stagingdeployer en este caso) permiso solo para un sitio web de IIS específico y el proceso de compilación puede proporcionar estas credenciales para implementar el paquete web. Tenga en cuenta que en el ejemplo siguiente se usa %ContactManagerPublishPassword%, que extrae el valor de contraseña de una variable de entorno. Para ejecutar correctamente el script, la variable %ContactManagerPublishPassword% debe definirse con el valor correcto.

msdeploy.exe 
  -source:package='…\ContactManager.Mvc.zip' 
  -dest:auto,
        computerName='https://STAGEWEB1:8172/MSDeploy.axd?site=DemoSite',
        userName='FABRIKAM\stagingdeployer',
        password=%ContactManagerPublishPassword%,
        authtype='Basic', 
  -verb:sync 
  -setParamFile:"…\ContactManager.Mvc.SetParameters.xml"   
  -allowUntrusted

Nota:

Para más información sobre las operaciones y la sintaxis de la línea de comandos de Web Deploy, consulte Referencia de la línea de comandos de Web Deploy. Para más información sobre el uso del archivo .deploy.cmd, consulte Procedimiento: Instalación de un paquete de implementación mediante el archivo deploy.cmd.

El controlador de Web Deploy proporciona un enfoque útil para la implementación en entornos de ensayo, entornos hospedados y entornos de producción basados en intranet, donde el acceso remoto al servidor está disponible, pero no las credenciales de administrador.

Para obtener un ejemplo completo de un escenario que usa el enfoque del controlador de Web Deploy, consulte Escenario: Configuración de un entorno de ensayo para la implementación web.

Uso de la implementación sin conexión

En algunos casos, no es posible ni práctico implementar aplicaciones y contenido en un sitio web de IIS desde una ubicación remota. Por ejemplo, los equipos de origen y destino pueden estar en redes aisladas o en segmentos de red, o puede que la directiva de firewall no permita el acceso remoto.

En escenarios como estos, todavía puede usar las funcionalidades de empaquetado y publicación de Web Deploy; no se pueden usar desde una ubicación remota. En su lugar, un administrador del servidor de destino debe copiar el paquete web en el servidor e importarlo a través del Administrador de IIS.

El enfoque de implementación sin conexión suele ser útil en entornos de producción accesibles desde Internet, donde los servidores de una red perimetral pueden tener conectividad restringida con equipos de la red interna.

Para obtener un ejemplo completo de un escenario que usa el enfoque de implementación sin conexión, consulte Escenario: Configuración de un entorno de producción para la implementación web.

Lecturas adicionales

Para más información sobre las operaciones y la sintaxis de la línea de comandos de Web Deploy, consulte Referencia de la línea de comandos de Web Deploy. Para más información sobre el uso del archivo .deploy.cmd, consulte Procedimiento: Instalación de un paquete de implementación mediante el archivo deploy.cmd.

Para obtener instrucciones más generales sobre las distintas formas en las que puede implementar paquetes web desde un equipo remoto, consulte Uso de Web Deploy de forma remota. Para más información sobre el uso de Web Deploy a petición, consulte Web Deploy On Demand.

AnteriorSiguiente