Configuración de entornos de ensayo en Azure App Service

Al implementar la aplicación web, la aplicación web en Linux, el back-end móvil o la aplicación API en Azure App Service, puede implementarlas en una ranura de implementación independiente en lugar de en la ranura de producción predeterminada si realiza la ejecución en el nivel de plan Estándar, Premium o Aislado de App Service. Las ranuras de implementación son aplicaciones activas con sus propios nombres de host. Los elementos de contenido y configuraciones de aplicaciones se pueden intercambiar entre dos ranuras de implementación, incluida la ranura de producción.

La implementación de la aplicación en un espacio que no sea de producción ofrece las siguientes ventajas:

  • Puede validar los cambios en la aplicación en una ranura de implementación de ensayo antes de intercambiarla con la ranura de producción.
  • La implementación de una aplicación en un espacio y su posterior paso a producción garantiza que todas las instancias del espacio están preparadas antes de dicho paso a producción. Esto elimina tiempos de inactividad a la hora de implementar la aplicación. El redireccionamiento del tráfico es perfecta y no se pierde ninguna solicitud en las operaciones de intercambio. Todo este flujo de trabajo se puede automatizar mediante la configuración del intercambio automático cuando no sea necesario realizar ninguna validación antes del intercambio.
  • Después del intercambio, la ranura con la aplicación de ensayo anterior ahora ocupa la aplicación de producción anterior. Si las modificaciones que se han intercambiado en el espacio de producción no son los que esperaba, puede volver a realizar un intercambio inmediatamente para tener el "último sitio que sabe que funciona correctamente".

Cada nivel del plan de App Service admite un número distinto de ranuras de implementación. El uso de las ranuras de implementación no tiene costo adicional. Para averiguar el número de ranuras que admite el nivel de la aplicación, consulte Límites de App Service.

Para escalar la aplicación a un nivel diferente, asegúrese de que el nivel de destino admite el número de ranuras que la aplicación ya usa. Por ejemplo, si la aplicación tiene más de cinco, no se puede reducir verticalmente al nivel Estándar, ya que este nivel solo admite cinco ranuras de implementación.

Incorporación de una ranura

Para poder habilitar varias espacios de implementación, la aplicación debe ejecutarse en los niveles Estándar, Premium o Aislado.

  1. En Azure Portal, busque y seleccione App Services y luego elija la aplicación.

    Búsqueda de App Services

  2. En el panel izquierdo, seleccione Ranuras de implementación>Agregar ranura.

    Agregar una nueva ranura de implementación

    Nota

    Si la aplicación no está aún en los niveles Estándar, Premium o Aislado, recibirá un mensaje que indica los niveles compatibles para habilitar la publicación almacenada provisionalmente. Llegados a este punto, tiene la opción de seleccionar Actualizar e ir a la pestaña Escala de la aplicación antes de continuar.

  3. En el cuadro de diálogo Agregar ranura, asígnele un nombre a la ranura y seleccione si desea que la configuración de la aplicación se clone de otra ranura de implementación. Haga clic en Agregar para continuar.

    Origen de la configuración

    La configuración se puede clonar de una ranura existente. La configuración que se puede clonar incluye los valores de la aplicación, las cadenas de conexión, versiones del marco del lenguaje, los sockets web, la versión de HTTP y el valor de bits de la plataforma.

Nota

Actualmente, un punto de conexión privado no se clona entre ranuras.

  1. Tras agregar la ranura, seleccione Cerrar para cerrar el cuadro de diálogo. La nueva ranura se muestra en la página Ranuras de implementación. De forma predeterminada, en la nueva ranura el valor de Tráfico % es 0 y todo el tráfico de los clientes se enruta a la ranura de producción.

  2. Seleccione la nueva ranura de implementación para abrir su página de recursos.

    Título de la ranura de implementación

    Como las restantes aplicaciones de App Service, el espacio de ensayo tiene una página de administración. La configuración del espacio se puede cambiar. Para recordarle que está viendo la ranura de implementación, el nombre de la aplicación se muestra como <app-name>/<slot-name> y el tipo de aplicación es App Service (ranura). También puede ver la ranura como una aplicación independiente en el grupo de recursos, con las mismas designaciones.

  3. Seleccione la dirección URL de la aplicación en la página de recursos de la ranura. La ranura de implementación tiene su propio nombre de host y es también una aplicación activa. Para limitar el acceso público a la ranura de implementación, consulte el artículo sobre Restricciones de IP de Azure App Service.

El nuevo espacio de implementación no tiene contenido, aunque se clone la configuración de otro espacio. Por ejemplo, puede publicar en esta ranura mediante Git. La implementación en el espacio se puede realizar desde otra rama del repositorio o desde otro repositorio.

La dirección URL de la ranura tendrá el formato http://sitename-slotname.azurewebsites.net. Para mantener la longitud de la dirección URL dentro de los límites de DNS necesarios, el nombre del sitio se truncará a 40 caracteres, el nombre de la ranura se truncará a 19 caracteres y se anexarán otros 4 caracteres aleatorios para asegurarse de que el nombre de dominio resultante sea único.

Qué ocurre durante un intercambio

Pasos del intercambio

Al intercambiar dos ranuras (normalmente de una ranura de ensayo a la ranura de producción), App Service hace lo siguiente para asegurarse de que la ranura de destino no experimente tiempo de inactividad:

  1. Aplique las siguientes opciones de configuración de la ranura de destino (por ejemplo, la de producción) a todas las instancias de la ranura de origen:

    Cualquiera de estos casos desencadena el reinicio de todas las instancias de la ranura de origen. Durante el intercambio con vista previa, esta marca el final de la primera fase. La operación de intercambio se pausará y podrá validar que la ranura de origen funciona correctamente con la configuración de la ranura de destino.

  2. Espere a que todas las instancias de la ranura de origen se hayan reiniciado. Si el reinicio no se puede realizar en alguna instancia, el intercambio revierte todos los cambios en la ranura de origen y detiene la operación.

  3. Si la caché local está habilitada, desencadene la inicialización de la caché local mediante una solicitud HTTP a la raíz de la aplicación ("/") en cada instancia de la ranura de origen. Espere a que todas las instancias devuelvan cualquier respuesta HTTP. La inicialización de la caché local produce otro reinicio en cada instancia.

  4. Si el intercambio automático está habilitado con preparación personalizada, desencadene la inicialización de la aplicación mediante una solicitud HTTP a la raíz de la aplicación ("/") en cada instancia de la ranura de origen.

    Si applicationInitialization no se especifica, desencadene una solicitud HTTP a la raíz de la aplicación de la ranura de origen en cada instancia.

    Si una instancia devuelve cualquier respuesta HTTP, se considera que se ha preparado.

  5. Si todas las instancias de la ranura de origen se han preparado correctamente, intercambie las dos ranuras; para ello, cambie las reglas de enrutamiento de las dos ranuras. Después de este paso, la ranura de destino (por ejemplo, la de producción) tendrá la aplicación que se preparó previamente en la ranura de origen.

  6. Ahora que la ranura de origen tiene la aplicación que se preparó previamente antes del intercambio, realice la misma operación; aplique la configuración y reinicie las instancias.

Durante intercambio, todo el trabajo de inicialización de las aplicaciones intercambiadas se realiza en la ranura de origen. La ranura de destino permanece en línea mientras la de origen se está preparando, independientemente de en qué punto el intercambio se realice o no correctamente. Para intercambiar una ranura de ensayo con la de producción, asegúrese de que esta última es siempre la de destino. De este modo, el intercambio no afecta a la aplicación de producción.

Nota

Las instancias de las instancias de producción anteriores (las que se intercambiarán en el almacenamiento provisional después de esta operación de intercambio) se reciclarán rápidamente en el último paso del proceso de intercambio. En caso de que tenga operaciones de larga duración en la aplicación, se abandonarán cuando se reciclen los nodos de trabajo. Esto también se aplica a las aplicaciones de funciones. Por lo tanto, el código de la aplicación se debe escribir de una forma tolerante a errores.

¿Qué configuración se intercambia?

Cuando crea un clon de la configuración de otro espacio de implementación, la configuración clonada se puede editar. Algunos elementos de configuración siguen al contenido en los intercambios (no son específicos de la ranura), mientras que otros permanecen en la misma ranura después de este (específicos). Las listas siguientes muestran la configuración que cambia cuando se intercambian las ranuras.

Configuraciones que se intercambian:

  • Configuración general: por ejemplo, versión de Framework, 32 o 64 bits, Web Sockets
  • Configuración de la aplicación (puede configurarse para ajustarse a un espacio)
  • Cadenas de conexión (puede configurarse para ajustarse a un espacio)
  • Asignaciones de controlador
  • Certificados públicos
  • Contenido de WebJobs
  • Conexiones híbridas *
  • Puntos de conexión de servicio *
  • Azure Content Delivery Network *
  • Asignaciones de ruta de acceso

Se prevé que las características marcadas con un asterisco (*) no se intercambien.

Valores que no se intercambian:

  • Extremos de publicación
  • Nombres de dominio personalizados
  • Certificados no públicos y configuración de TLS/SSL
  • Configuración de escala
  • Programadores de WebJobs
  • Restricciones de IP
  • Always On
  • Configuración de diagnóstico
  • Uso compartido de recursos entre orígenes (CORS)
  • Integración de la red virtual
  • Identidades administradas
  • Configuración que termina con el sufijo _EXTENSION_VERSION

Nota

Para que la configuración mencionada anteriormente sea intercambiable, agregue la configuración de la aplicación WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS en todas las ranuras de la aplicación y establezca su valor en 0 o false. Esta configuración se puede intercambiar o no. Recuerde que no puede hacer que solo algunos valores de configuración sean intercambiables y que los demás no lo sean. Las identidades administradas nunca se intercambian y no se ven afectadas por esta invalidación de la configuración de la aplicación

Algunas configuraciones de aplicaciones que se aplican a configuraciones no intercambiadas no se intercambian. Por ejemplo, como los valores de diagnóstico no se intercambian, los valores de aplicaciones relacionados como WEBSITE_HTTPLOGGING_RETENTION_DAYS y DIAGNOSTICS_AZUREBLOBRETENTIONDAYS tampoco lo hacen, aunque no se muestren como valores de ranura.

Para configurar la aplicación o una cadena de conexión de esta para que se ajuste a una ranura específica (sin intercambio), vaya a la página Configuración de esa ranura. Agregue configuración o modifíquela y seleccione configuración de ranura de implementación. Al seleccionar esta casilla se indica a App Service que la configuración no se puede intercambiar.

Configuración de espacios

Intercambio de dos espacios

Las ranuras de implementación se pueden intercambiar en las páginas Ranuras de implementación e Información general de la aplicación. Para detalles técnicos sobre el intercambio de ranuras, consulte Qué ocurre durante un intercambio.

Importante

Antes de intercambiar una aplicación de una ranura de implementación a producción, asegúrese de la de producción es la ranura de destino y de que todas las configuraciones de la ranura de origen son exactamente como las quiere en producción.

Para intercambiar ranuras de implementación:

  1. Vaya a la página Ranuras de implementación y seleccione Intercambiar.

    Botón Intercambiar

    El cuadro de diálogo Intercambiar muestra la configuración de la ranura de origen y de destino seleccionadas que se van a cambiar.

  2. Seleccione los espacios Origen y Destino. Por lo general, el destino suele ser el espacio de producción. Además, seleccione las pestañas Cambios de origen y Cambios de destino, y compruebe que los cambios en la configuración son los esperados. En cuanto termine, puede intercambiar los espacios. Para ello solo debe seleccionar Intercambiar.

    Intercambio completo

    Para ver cómo funcionaría la ranura de destino con la nueva configuración antes de que se realice el intercambio, no seleccione Intercambiar, siga las instrucciones de Intercambio con vista previa.

  3. Cuando haya terminado, seleccione Cerrar para cerrar el cuadro de diálogo.

Si tiene problemas, consulte Solución de problemas con los intercambios.

Intercambio con vista previa (intercambio en varias fases)

Antes de cambiar a producción como ranura de destino, valide que la aplicación se ejecute con la configuración intercambiada. La ranura de origen también se ha preparado antes de que finalice el intercambio, algo que es conveniente para las aplicaciones críticas.

Al realizarse un intercambio con vista previa, App Service realiza el mismo intercambio, pero se detiene tras el primer paso. En ese momento puede comprobar el resultado en la ranura de ensayo antes de completar el intercambio.

Si cancela el intercambio, App Service vuelve a aplicar los elementos de configuración en la ranura de origen.

Para realizar el intercambio con vista previa:

  1. Siga los pasos que se indican en Intercambio de ranuras de implementación, pero seleccione Realizar intercambio con versión preliminar .

    Intercambio con vista previa

    El cuadro de diálogo muestra cómo cambia la configuración de la ranura de origen en la fase 1 y cómo cambian tanto la ranura de origen como la de destino en la fase 2.

  2. Cuando esté listo para iniciar el intercambio, seleccione Iniciar intercambio.

    Cuando se complete la fase 1, se le notificará en el cuadro de diálogo. Vaya a https://<app_name>-<source-slot-name>.azurewebsites.net para obtener una vista previa del intercambio en la ranura de origen.

  3. Cuando esté listo para completar el intercambio pendiente, seleccione Completar intercambio en Acción de intercambio y seleccioneCompletar intercambio.

    Para cancelar un intercambio pendiente, seleccione Cancelar intercambio en su lugar.

  4. Cuando haya terminado, seleccione Cerrar para cerrar el cuadro de diálogo.

Si tiene problemas, consulte Solución de problemas con los intercambios.

Para automatizar un intercambio en varias fases, consulte Automatización con Azure PowerShell.

Reversión de intercambios

Si aparecen errores en el espacio de destino (por ejemplo, el espacio de producción) después de un intercambio de espacios, restaure los espacios al estado que tenían antes del intercambio. Para ello, vuelva a intercambiarlos de inmediato.

Configuración del intercambio automático

Nota

El intercambio automático no se admite en aplicaciones web en Linux y Web App for Containers.

El intercambio automático optimiza los escenarios de Azure DevOps en los que se desee implementar una aplicación continuamente sin arranques en frío ni tiempos de inactividad para los clientes de la aplicación. Cuando se habilita el intercambio automático para una ranura a producción, cada vez que se insertan los cambios de código en esa ranura, App Service cambia automáticamente la aplicación a producción después de que se haya preparado en la de origen.

Nota

Antes de configurar el intercambio automático en la ranura de producción, considere la posibilidad de probarlo en una ranura de destino distinta de la de producción.

Para configurar el intercambio automático:

  1. Vaya a la página de recursos de la aplicación. Seleccione Ranuras de implementación><ranura de origen deseada>>Configuración>Configuración general.

  2. Para Intercambio automático habilitado, seleccione Activado. A continuación, seleccione la ranura de destino deseada como Ranura de implementación de intercambio automático y seleccione Guardar en la barra de comandos.

    Selecciones para configurar el intercambio automático

  3. Ejecute una inserción de código en el espacio de origen. El intercambio automático se realiza al poco tiempo y la actualización se refleja en la dirección URL de la ranura de destino.

Si tiene problemas, consulte Solución de problemas con los intercambios.

Especificación de Preparación personalizada

Algunas aplicaciones pueden requerir acciones de preparación personalizadas para el intercambio. El elemento de configuración applicationInitialization de web.config permite especificar acciones de inicialización personalizadas. El intercambio espera hasta que se completa esta preparación personalizada para realizar el intercambio con la ranura de destino. He aquí un fragmento de ejemplo del archivo web.config.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Para más información sobre la personalización del elemento applicationInitialization, consulte Most common deployment slot swap failures and how to fix them (Errores de intercambio de ranuras de implementación más comunes y soluciones).

También puede personalizar el comportamiento de la preparación con una o ambas de las siguientes opciones de configuración de la aplicación:

  • WEBSITE_SWAP_WARMUP_PING_PATH: la ruta de acceso para hacer ping a través de HTTP para preparar el sitio. Agregue esta configuración de aplicación especificando una ruta de acceso personalizada que comience con una barra diagonal como valor. Un ejemplo es /statuscheck. El valor predeterminado es /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: códigos de respuesta HTTP válidos para la operación de preparación. Agregue esta configuración de aplicación con una lista de códigos HTTP separados por comas. Un ejemplo sería 200,202. Si el código de estado devuelto no está en la lista, las operaciones de preparación e intercambio se detienen. Por defecto, todos los códigos de respuesta son válidos.
  • WEBSITE_WARMUP_PATH: una ruta de acceso relativa en el sitio al que se debe hacer ping cada vez que se reinicie (no solo durante los intercambios de ranura). Los valores del ejemplo incluyen /statuscheck o la ruta de acceso raíz, /.

Nota

El elemento de configuración <applicationInitialization> forma parte de cada inicio de la aplicación, mientras que los dos valores de aplicación de comportamiento de preparación solo se aplican a los intercambios de ranura.

Si tiene problemas, consulte Solución de problemas con los intercambios.

Supervisión de un intercambio

Si el intercambio tarda mucho tiempo en completarse, puede obtener información sobre su estado en el registro de actividad.

En la página de recursos de la aplicación del portal, en el panel izquierdo, seleccione Registro de actividad.

Una operación de intercambio aparece en la consulta de registro como Swap Web App Slots. Puede expandirla y seleccionar una de los suboperaciones o errores para ver los detalles.

Enrutamiento del tráfico

De forma predeterminada, todas las solicitudes que realiza el cliente a la dirección URL de producción de la aplicación (http://<app_name>.azurewebsites.net) se enrutan al espacio de producción. Una parte del tráfico se puede enrutar a otro espacio. Esta característica es útil si se necesitan los comentarios de los usuarios al respecto de una nueva actualización, pero dicha actualización aún no está lista para enviarla a producción.

Enrutamiento automático del tráfico de producción

Para enrutar automáticamente el tráfico de producción:

  1. Vaya a la página de recursos de la aplicación y seleccione Ranuras de implementación.

  2. En la columna Tráfico % del espacio que se desea enrutar, especifique un porcentaje (entre 0 y 100) que represente la cantidad del tráfico total que desea enrutar. Seleccione Guardar.

    Configuración de un porcentaje de tráfico

Una vez guardado el valor, el porcentaje especificado de clientes se enruta aleatoriamente a la ranura que no es de producción.

Después de que un cliente se enrute automáticamente a una ranura específica, se "ancla" a esa ranura durante una hora o hasta que se eliminen las cookies. En el explorador del cliente, para ver a qué espacio está anclada la sesión debe examinar la cookie x-ms-routing-name en los encabezados HTTP. Las solicitudes que se enrutan a al espacio "de ensayo" tienen la cookie x-ms-routing-name=staging. Las solicitudes que se enrutan al espacio de producción tienen la cookie x-ms-routing-name=self.

Nota

También puede usar el comando az webapp traffic-routing set de la CLI de Azure para establecer los porcentajes de enrutamiento desde herramientas de CI/CD, como Acciones de GitHub, canalizaciones DevOps u otros sistemas de automatización.

Enrutamiento manual del tráfico de producción

Además del enrutamiento automático del tráfico, App Service puede enrutar solicitudes a un espacio concreto. Esto es útil cuando desee que los usuarios puedan escoger el enrutamiento a la aplicación beta, o la exclusión voluntaria de esta. Para enrutar el tráfico de producción de manera manual se usa el parámetro de consulta x-ms-routing-name.

Para permitir que los usuarios opten por la exclusión del enrutamiento a la aplicación beta, por ejemplo, puede poner este vínculo en la página web:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

La cadena x-ms-routing-name=self especifica la ranura de producción. Cuando el explorador del cliente accede al vínculo, se le redirige a la ranura de producción. Cada solicitud posterior tiene la cookie x-ms-routing-name=self que ancla la sesión a la ranura de producción.

Para permitir a los usuarios participar en la aplicación de la versión beta, establezca el mismo parámetro de consulta con el nombre de la ranura que no es de producción. Este es un ejemplo:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

De forma predeterminada, las ranuras nuevas tienen una regla de enrutamiento del 0%, en gris. Cuando se establece explícitamente este valor en 0% (en negro), los usuarios pueden acceder a la ranura de ensayo manualmente mediante el parámetro de consulta x-ms-routing-name. Pero no se les enrutará automáticamente a la ranura, ya que el porcentaje se ha establecido en 0. Se trata de un escenario avanzado donde puede "ocultar" su ranura de ensayo del público y permitir que los equipos internos prueben los cambios en la ranura al mismo tiempo.

Eliminación de una ranura

Busque y seleccione la aplicación. Seleccione Ranuras de implementación><ranura para eliminar>>Información general. El tipo de aplicación se muestra como App Service (ranura) para recordarle que está viendo una ranura de implementación. En la barra de comandos, seleccione Eliminar.

Eliminación de una ranura de implementación

Automatización con PowerShell

Nota:

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Consulte Instalación de Azure PowerShell para empezar. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Azure PowerShell es un módulo que proporciona cmdlets para administrar Azure mediante Windows PowerShell, incluida la compatibilidad para administrar ranuras de implementación de Azure App Service.

Para obtener información acerca de cómo instalar y configurar Azure PowerShell y cómo autenticar Azure PowerShell con su suscripción de Azure, consulte Instalación y configuración de Azure PowerShell.


Creación de una aplicación web

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Creación de una ranura

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Inicio de un intercambio con vista previa (intercambio en varias fases) y aplicación de configuración de la ranura de destino a la ranura de origen

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Cancelación de un intercambio pendiente (intercambio con vista previa) y restauración de configuración de la ranura de origen

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Intercambio de ranuras de implementación

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Supervisión de los eventos de intercambio en el registro de actividad

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor  

Eliminación de una ranura

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

Para realizar un intercambio de ranuras desde el espacio de producción, la identidad necesita (como mínimo) permisos para realizar la operación Microsoft.Web/sites/slotsswap/Action. Para más información, consulte Operaciones del proveedor de recursos

Automatización con plantillas de Resource Manager

Las plantillas de Resource Manager son archivos JSON declarativos que se usan para automatizar la implementación y la configuración de los recursos de Azure. Para intercambiar ranuras mediante plantillas de Resource Manager, establecerá dos propiedades en los recursos Microsoft.Web/sites/slots and Microsoft.Web/sites:

  • buildVersion: esta es una propiedad de cadena que representa la versión actual de la aplicación implementada en la ranura. Por ejemplo: "v1", "1.0.0.1" o "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: esta es una propiedad de cadena que especifica qué buildVersion debe tener la ranura. Si targetBuildVersion no es igual a la buildVersion actual, esto activará la operación de intercambio al encontrar la ranura que tiene la buildVersion especificada.

Ejemplo de plantilla de Resource Manager

La siguiente plantilla de Resource Manager actualizará el objeto buildVersion del espacio de ensayo y establecerá el objeto targetBuildVersion en el espacio de producción. Esto intercambiará las dos ranuras. La plantilla supone que ya tiene una aplicación web creada con una ranura llamada "almacenamiento provisional".

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Esta plantilla de Resource Manager es idempotente, lo que significa que puede ejecutarse repetidamente y producir el mismo estado de las ranuras. Después de la primera ejecución, targetBuildVersion coincidirá con el buildVersion actual, por lo que no se activará un intercambio.

Automatización con la CLI

Para información sobre los comandos de la CLI de Azure que se usan con las ranuras de implementación, consulte az webapp deployment slot.

Solución de problemas con los intercambios

Si se produce algún error durante un intercambio de ranuras, se registra en D:\home\LogFiles\eventlog.xml. También se archiva en el registro de errores específicos de la aplicación.

Estos son algunos errores de intercambio habituales:

  • Se superó el tiempo de una solicitud HTTP a la raíz de la aplicación. La operación de intercambio espera 90 segundos para cada solicitud HTTP y lo vuelve a intentar hasta 5 veces. Si se agota el tiempo de espera de todos los intentos, el intercambio se detiene.

  • La inicialización de la caché local puede producir un error cuando el contenido de la aplicación supera la cuota de disco local especificada para la memoria caché local. Para más información, consulte la Introducción a la caché local.

  • Durante la preparación personalizada, las solicitudes HTTP se realizan internamente (sin pasar por la dirección URL externa). Pueden producirse errores en ciertas reglas de reescritura de dirección URL en Web.config. Por ejemplo, las reglas de redirección de nombres de dominio o la exigencia de HTTPS pueden impedir que las solicitudes de alcancen el código de la aplicación. Para solucionar este problema, modifique las reglas de reescritura mediante la incorporación de las dos siguientes condiciones:

    <conditions>
      <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Las reglas de reescritura de dirección URL sin preparación personalizada pueden bloquear las solicitudes HTTP. Para solucionar este problema, modifique las reglas de reescritura mediante la incorporación de la siguiente condición:

    <conditions>
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Después de los intercambios de ranura, la aplicación puede experimentar reinicios inesperados. El motivo es que después de un intercambio, la configuración de enlace del nombre de host deja de estar sincronizada, lo que de por sí no provoca reinicios. Sin embargo, algunos eventos de almacenamiento subyacentes (como las conmutaciones por error de volúmenes de almacenamiento) pueden detectar estas discrepancias y forzar el reinicio de todos los procesos de trabajo. Para reducir estos tipos de reinicios, establezca la configuración de la aplicación WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 en todas las ranuras. Sin embargo, esta configuración de la aplicación no funciona con aplicaciones de Windows Communication Foundation (WCF).

Pasos siguientes

Bloqueo del acceso a espacios que no sean de producción