Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
de Jason Lee
Al trabajar con la Herramienta de implementación web de Internet Information Services (IIS) (Web Deploy) 2.0 o posterior, hay tres enfoques principales que puede usar para obtener las aplicaciones web empaquetadas en un servidor web. Puede hacer lo siguiente:
- Implemente la aplicación desde una ubicación remota dirigiéndose al servicio del 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 On Demand (también conocido como "agente temporal").
- Implemente la aplicación desde una ubicación remota teniendo como destino el controlador de implementación web de IIS en el servidor de destino.
- Implemente la aplicación copiando manualmente el paquete web en el servidor de destino e importándolo a través del Administrador de IIS.
La forma de configurar los servidores web de destino dependerá del enfoque de implementación que desee utilizar. Este tema le ayudará a decidir qué enfoque de implementación es el adecuado para usted.
En esta tabla se muestran las principales ventajas y desventajas de cada enfoque de implementación, junto con los escenarios que más suelen adaptarse a cada enfoque.
Enfoque | Ventajas | Desventajas | Escenarios típicos |
---|---|---|---|
Agente remoto | Es fácil de configurar. Es adecuado para actualizaciones periódicas de aplicaciones y contenido web. | El usuario debe ser un 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 un administrador en el servidor de destino. El usuario no puede proporcionar credenciales alternativas. | Entornos de desarrollo. Entornos de prueba. |
Controlador de implementación web | Los usuarios que no son administradores pueden implementar contenido. Es adecuado para actualizaciones periódicas de aplicaciones y contenido web. | Es mucho más complejo de configurar. | Entornos de ensayo. Entornos de producción de intranet. Entornos alojados. |
Implementación sin conexión | Es muy fácil de configurar. Es adecuado para ambientes aislados. | El administrador del servidor debe copiar e importar manualmente el paquete web cada vez. | Entornos de producción orientados a 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 del Agente de Web Deployment (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] con el nombre del equipo de su servidor web, una dirección IP para su servidor web o un nombre de host que se resuelva en su servidor web.
Los administradores de servidores pueden implementar paquetes web desde una ubicación remota, como un equipo de desarrollo o un servidor de compilación, especificando esta dirección de punto de conexión. Por ejemplo, supongamos que Matt Hink de Fabrikam, Inc. ha creado el proyecto de aplicación web ContactManager.Mvc en su equipo de desarrollo. 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 un administrador de servidor en el servidor TESTWEB1, puede implementar la aplicación web en el servidor web de prueba ejecutando este comando en su equipo de desarrollador:
ContactManager.Mvc.deploy.cmd /y /m:http://TESTWEB1/MSDEPLOYAGENTSERVICE a/:NTLM
De hecho, el ejecutable de Web Deploy puede inferir 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 obtener más información sobre la sintaxis de la línea de comandos de Web Deploy y los archivos de .deploy.cmd , vea Cómo: Instalar un paquete de implementación mediante el archivo deploy.cmd.
El agente remoto ofrece una forma 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 un 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 implementación en escenarios de desarrollo o prueba, donde no es raro que los desarrolladores tengan control total de administrador sobre un entorno de servidor de prueba y las aplicaciones se recompilan y vuelven 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 de 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 de 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 del agente de implementación web en el servidor de destino y la usará para implementar el contenido en IIS. Una vez completada la implementación, se eliminan todos los archivos temporales.
Si desea usar la configuración del proveedor del 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 del 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 instalaciones de Web Deploy en los servidores de destino. Además, no es necesario asegurarse de que los equipos de origen y destino ejecuten la misma versión de Web Deploy. Sin embargo, este enfoque adolece de las mismas limitaciones principales que el enfoque de agente remoto, es decir, que debe ser un 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 mucha más configuración inicial del entorno de destino.
Para obtener más información sobre el uso del agente temporal, vea Cómo: Instalar un paquete de implementación mediante el archivo deploy.cmd y Web Deploy On Demand.
Uso del controlador de implementación web
A partir de IIS 7, Web Deploy ofrece un enfoque de implementación alternativo a través del controlador de Web Deploy de IIS. El controlador de implementación web 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] con el nombre del equipo de su servidor web, una dirección IP para su servidor web o un nombre de host que se resuelva en su servidor web.
La gran ventaja del controlador de implementación web sobre el 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 específicos de IIS. El controlador de 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 implementación web 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á que el usuario se conecte 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, supongamos 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 de agente remoto, tendría que hacer que la identidad del proceso de compilación sea un administrador en los servidores de destino. Por el contrario, con el enfoque del controlador de implementación web, puede conceder a un usuario que no sea 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 utiliza %ContactManagerPublishPassword%
, que extrae el valor de la contraseña de una variable de entorno. Para ejecutar correctamente el script, %ContactManagerPublishPassword%
la variable 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=,
authtype='Basic',
-verb:sync
-setParamFile:"…\ContactManager.Mvc.SetParameters.xml"
-allowUntrusted
Nota:
Para obtener más información sobre las operaciones y la sintaxis de la línea de comandos de Web Deploy, vea Referencia de la línea de comandos de Web Deploy. Para obtener más información sobre el uso del archivo .deploy.cmd , vea Cómo: Instalar un paquete de implementación mediante el archivo deploy.cmd.
El controlador de implementación web 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 las credenciales de administrador no.
Para obtener un ejemplo completo de un escenario que usa el enfoque de controlador de Web Deploy, consulte Escenario: Configuración de un entorno de ensayo para Web Deployment.
Uso de la implementación sin conexión
En algunos casos, no es posible o práctico implementar aplicaciones y contenido en un sitio web de IIS desde una ubicación remota. Por ejemplo, es posible que los equipos de origen y destino estén en redes o segmentos de red aislados, o que la directiva de firewall no permita el acceso remoto.
En escenarios como estos, todavía puede usar las capacidades de empaquetado y publicación de Web Deploy; simplemente no puedes usarlos 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 orientados a Internet, donde los servidores de una red perimetral pueden tener conectividad restringida con los equipos de la red interna.
Para obtener un ejemplo completo de un escenario que usa el enfoque de implementación sin conexión, vea Escenario: Configuración de un entorno de producción para la implementación web.
Lecturas adicionales
Para obtener más información sobre las operaciones y la sintaxis de la línea de comandos de Web Deploy, vea Referencia de la línea de comandos de Web Deploy. Para obtener más información sobre el uso del archivo .deploy.cmd , vea Cómo: Instalar un paquete de implementación mediante el archivo deploy.cmd.
Para obtener instrucciones más generales sobre las distintas formas en que puede implementar paquetes web desde un equipo remoto, consulte Uso de Web Deploy de forma remota. Para obtener más información sobre el uso de Web Deploy On Demand, consulte Web Deploy On Demand.