Elegir el enfoque adecuado para la implementación web

por Jason Lee

Descargar PDF

Cuando se trabaja 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:

  • Implemente la aplicación desde una ubicación remota con el destino web Deployment Agent Service (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 con el destino del controlador de Web Deploy IIS en el servidor de destino.
  • Implemente la aplicación copiando manualmente el paquete web en el servidor de destino e importándose a través del 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 normalmente se adaptan a cada enfoque.

Enfoque Ventajas Inconvenientes Escenarios típicos
Agente remoto Es fácil de configurar. Es adecuado para actualizaciones periódicas de contenido y aplicaciones web. 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 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.
Web Deploy controlador Los usuarios que no son administradores pueden implementar contenido. Es adecuado para actualizaciones periódicas de contenido y aplicaciones web. Es mucho más complejo configurarlo. Entornos de ensayo. Entornos de producción de intranet. Entornos hospedados.
Implementación sin conexión Es muy 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 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 web Deployment Agent (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

Note

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

Los administradores del servidor pueden implementar paquetes web desde una ubicación remota, como un equipo para desarrolladores o un servidor de compilación, especificando esta dirección de punto de conexión. Por ejemplo, suponga que Matt Fabrikamk en Fabrikam, Inc. ha creado el proyecto de aplicación web 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 Web Deploy necesarios para instalar el paquete. Si Matt es administrador del servidor TESTWEB1, puede implementar la aplicación web en el servidor web de prueba mediante la ejecución de este comando en su máquina para desarrolladores:

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

De hecho, el Web Deploy ejecutable 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

Note

Para obtener más información sobre Web Deploy sintaxis de línea de comandos y archivos .deploy.cmd, vea Cómo: Instalar 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 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 implementación en escenarios de desarrollo o pruebas, donde no es raro que los desarrolladores tengan control de administrador total sobre un entorno de servidor de prueba y las aplicaciones se vuelvan a compilar y volver a implementar con mucha frecuencia. Sin embargo, este enfoque suele ser menos aceptable para entornos de ensayo o de producción.

Para obtener un ejemplo completo de un escenario que usa el enfoque del agente remoto, vea 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 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 quitan todos los archivos temporales.

Si desea 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

Note

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 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 se ve afectado por las mismas limitaciones principales 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 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 a petición.

Usar el controlador de Web Deploy de datos

Para IIS 7 en adelante, Web Deploy ofrece un enfoque de implementación alternativo a través del controlador de Web Deploy IIS. El controlador 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

Note

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

La gran ventaja del controlador de Web Deploy sobre el agente remoto y el agente temporal es que puede configurar IIS para permitir que los usuarios que no son administradores implemente aplicaciones y contenido en sitios web específicos de IIS. El controlador Web Deploy también admite la autenticación básica, por lo que puede proporcionar credenciales alternativas como parámetros en Web Deploy comandos. El principal inconveniente es que el controlador de Web Deploy es inicialmente mucho más complicado de configurar 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
For example, suppose a build process is configured to automatically deploy a web application to a staging environment after every successful build. If you used the remote agent approach, you'd need to make the build process identity an administrator on your destination servers. In contrast, using the Web Deploy Handler approach you can give a non-administrator user—**FABRIKAM\stagingdeployer** in this case—permission to a specific IIS website only, and the build process can provide these credentials to deploy the web package. Note the following example is using `%ContactManagerPublishPassword%`, which is pulling the password value from an environment variable. To successfully execute the script, `%ContactManagerPublishPassword%`  variable must be defined with the correct value.

[!code-console[Main](choosing-the-right-approach-to-web-deployment/samples/sample7.cmd)]

> [!NOTE]
> For more information on Web Deploy command-line operations and syntax, see [Web Deploy Command Line Reference](https://technet.microsoft.com/library/dd568991(v=ws.10).aspx). For more information on using the *.deploy.cmd* file, see [How to: Install a Deployment Package Using the deploy.cmd File](https://msdn.microsoft.com/library/ff356104.aspx).

The Web Deploy Handler provides a useful approach to deployment in staging environments, hosted environments, and intranet-based production environments, where remote access to the server is available but administrator credentials are not.

For an end-to-end example of a scenario that uses the Web Deploy Handler approach, see [Scenario: Configuring a Staging Environment for Web Deployment](scenario-configuring-a-staging-environment-for-web-deployment.md).

## Using Offline Deployment

In some cases, it's not possible or practical to deploy applications and content to an IIS website from a remote location. For example, the source and destination computers may be in isolated networks or network segments, or firewall policy may not permit remote access.

In scenarios like these, you can still use the packaging and publishing capabilities of Web Deploy; you just can't use them from a remote location. Instead, an administrator on the destination server must copy the web package onto the server and import it through IIS Manager.

![](choosing-the-right-approach-to-web-deployment/_static/image1.png)

The offline deployment approach is typically useful in Internet-facing production environments, where servers in a perimeter network may have restricted connectivity with computers in the internal network.

For an end-to-end example of a scenario that uses the offline deployment approach, see [Scenario: Configuring a Production Environment for Web Deployment](scenario-configuring-a-production-environment-for-web-deployment.md).

## Further Reading

For more information on Web Deploy command-line operations and syntax, see [Web Deploy Command Line Reference](https://technet.microsoft.com/library/dd568991(v=ws.10).aspx). For more information on using the *.deploy.cmd* file, see [How to: Install a Deployment Package Using the deploy.cmd File](https://msdn.microsoft.com/library/ff356104.aspx).

For more general guidance on the different ways in which you can deploy web packages from a remote computer, see [Using Web Deploy Remotely](https://technet.microsoft.com/library/ee461175(WS.10).aspx). For more information on using Web Deploy On Demand, see [Web Deploy On Demand](https://technet.microsoft.com/library/ee517345(WS.10).aspx).

> [!div class="step-by-step"]
> [Previous](configuring-server-environments-for-web-deployment.md)
> [Next](scenario-configuring-a-test-environment-for-web-deployment.md)