Compartir a través de


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 de API en Azure App Service, puede implementarlas en una ranura de implementación independiente en lugar de en la ranura de producción predeterminada. Este enfoque está disponible si lo ejecuta en el nivel Estándar, Premium o Aislado de un plan de Servicio de Aplicaciones. Las ranuras de implementación son aplicaciones activas con sus propios nombres de host. El contenido de la aplicación y los elementos de configuración 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 de la aplicación antes de mover la ranura a producción.

  • Puede asegurarse de que todas las instancias de la ranura se activen antes de cambiarla a producción. Este enfoque elimina tiempos de inactividad a la hora de implementar la aplicación. La redirección del tráfico es perfecta. No se pierde ninguna solicitud debido a 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.

El uso de las ranuras de implementación no tiene costo adicional. Cada nivel del plan de App Service admite un número distinto de ranuras de implementación. 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 otro nivel, asegúrese de que el nivel de destino admite el número de ranuras que la aplicación ya usa. Por ejemplo, si tu aplicación tiene más de cinco ranuras, no se puede bajar al nivel Estándar. El nivel Estándar solo admite cinco ranuras de implementación.

El vídeo siguiente complementa los pasos de este artículo ilustrando cómo configurar entornos de ensayo en Azure App Service.

Requisitos previos

  • Permisos para realizar la operación de ranura que desea. Para obtener información sobre los permisos necesarios, consulte Operaciones del proveedor de recursos. Busque ranura, por ejemplo.

Incorporación de una ranura

Para habilitar varias ranuras de implementación, la aplicación debe ejecutarse en el nivel Estándar, Premium o Aislado.

  1. En Azure Portal, vaya a la página de administración de la aplicación.

  2. En el menú de la izquierda, seleccione Implementación>Ranuras de implementación. A continuación, seleccione Agregar.

    Nota

    Si la aplicación aún no está en el nivel Estándar, Premium o Aislado, seleccione Actualizar. Vaya a la pestaña Escala de la aplicación antes de continuar.

  3. En el cuadro de diálogo Agregar ranura , asigne un nombre a la ranura y seleccione si quiere clonar una configuración de aplicación desde otra ranura de implementación. Seleccione Agregar para continuar.

    Captura de pantalla que muestra las selecciones para configurar una nueva ranura de implementación denominada

    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.

  4. Después de escribir la configuración, seleccione Cerrar para cerrar el cuadro de diálogo. La nueva ranura aparece ahora en la página Ranuras de implementación. De forma predeterminada, traffic % se establece en 0 para la nueva ranura, con todo el tráfico del cliente enrutado a la ranura de producción.

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

    Captura de pantalla que muestra cómo abrir la página de administración de una ranura de implementación en el portal.

    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 y el nombre de ranura aparecen en la dirección URL. 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.

  6. En la página de recursos de la ranura, seleccione la dirección URL de la aplicación. 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 Configuración de restricciones de acceso 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. El artículo Obtener un perfil de publicación de Azure App Service puede proporcionar la información necesaria para implementar la ranura. Visual Studio puede importar el perfil para implementar contenido en la ranura.

La URL de la ranura tiene el formato http://sitename-slotname.azurewebsites.net. Para mantener la longitud de la dirección URL dentro de los límites DNS necesarios, el nombre del sitio se trunca a 40 caracteres. El nombre de la ranura y el del sitio, combinados, deben tener menos de 59 caracteres.

Comprender lo que sucede durante un intercambio

Pasos del intercambio

Al intercambiar dos ranuras, App Service hace lo siguiente para asegurarse de que la ranura de destino no experimenta 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:

    Cuando se aplica cualquiera de las opciones de configuración a la ranura de origen, el cambio desencadena todas las instancias de la ranura de origen para reiniciarse. Durante un intercambio con vista previa, esta acción marca el final de la primera fase. La operación de intercambio está en pausa. Puede 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 caché local mediante la realización de 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 calentamiento personalizado, desencadene la inicialización de la aplicación personalizada 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. 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 de intercambio previo que se encontraba anteriormente en la ranura de destino, realice la misma operación aplicando toda la configuración y reiniciando las instancias.

En cualquier momento de la operación de intercambio, todo el trabajo de inicialización de las aplicaciones intercambiadas se produce 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 producción anteriores se intercambian en el almacenamiento provisional después de esta operación de intercambio. Esas instancias se reciclan en el último paso del proceso de intercambio. Si tiene 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. Asegúrese de que el código de la aplicación está escrito de forma tolerante a errores.

Pasos para hacer que una ranura no se pueda intercambiar

Cuando clona una configuración de otra ranura de implementación, la configuración clonada se puede editar. Algunos elementos de configuración siguen el contenido en un intercambio (no son específicos de la ranura). Otros elementos de configuración permanecen en la misma ranura después de un intercambio (son específico de la ranura).

Al intercambiar ranuras, esta configuración se intercambia:

  • Pila de lenguaje y versión, 32 bits y 64 bits
  • Configuración de la aplicación (puede configurarse para ajustarse a un espacio)
  • Cadenas de conexión (puede configurarse para ajustarse a un espacio)
  • Cuentas de almacenamiento montadas (se pueden configurar para ajustarse a una ranura)
  • Asignaciones de controlador
  • Certificados públicos
  • Contenido de WebJobs
  • Conexiones híbridas (actualmente)
  • Puntos de conexión de servicio (actualmente)
  • Azure Content Delivery Network (actualmente)
  • Asignaciones de ruta de acceso
  • Integración de la red virtual

Al intercambiar ranuras, esta configuración no se intercambia:

  • Configuración general no mencionada en la lista anterior
  • 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
  • Siempre Encendido
  • Configuración de diagnóstico
  • Uso compartido de recursos entre orígenes (CORS)
  • Identidades administradas y configuración relacionada
  • Configuración que termina con el sufijo _EXTENSION_VERSION
  • Configuración creada por Service Connector

Nota

Para que la configuración se pueda intercambiar, agregue la configuración WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS de la aplicación en cada ranura de la aplicación. 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. Esta configuración de la aplicación de invalidación no las afecta.

Algunas configuraciones de aplicaciones que se aplican a configuraciones no intercambiadas no se intercambian. Por ejemplo, dado que las configuraciones de diagnóstico no se intercambian, las configuraciones de la aplicación relacionadas, como WEBSITE_HTTPLOGGING_RETENTION_DAYS y DIAGNOSTICS_AZUREBLOBRETENTIONDAYS, tampoco se intercambian, aunque no aparezcan como configuraciones de ranura.

Para configurar una configuración de la aplicación o una cadena de conexión para que permanezca en un espacio específico que no se cambia:

  1. Vaya a Configuración>Variable de entorno para esa ranura.

  2. Agregue o edite una configuración y, a continuación, seleccione Configuración de ranura de implementación. Al activar esta casilla se indica a App Service que la configuración no se puede intercambiar.

  3. Selecciona Aplicar.

Captura de pantalla que muestra la casilla de verificación para configurar una aplicación como una configuración de ranura en Azure Portal.

Intercambio de ranuras de implementación

Las ranuras de implementación se pueden intercambiar en las páginas Ranuras de implementación e Información general de la aplicación.

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.

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

    Captura de pantalla que muestra las selecciones para iniciar una operación de intercambio en el portal.

    El 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 ranura de origen y Cambios de ranura de destino y compruebe que los cambios de configuración sean los esperados. Cuando termine, puede intercambiar las ranuras inmediatamente seleccionando Iniciar intercambio.

    Captura de pantalla que muestra las selecciones para configurar y completar un intercambio en el portal.

    Para ver cómo se ejecutaría la ranura de destino con la nueva configuración antes de que se produzca el intercambio, no seleccione Iniciar intercambio. Siga las instrucciones de Intercambio con vista previa más adelante en este artículo.

  3. Seleccione Cerrar para cerrar el cuadro de diálogo.

Si tiene algún problema, consulte Solución de problemas de intercambios más adelante en este artículo.

Intercambio con versión preliminar (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.

Nota

No puede usar el intercambio con vista previa cuando la autenticación de sitio está habilitada en una de las ranuras.

  1. Siga los pasos de la sección Intercambiar ranuras de implementación, pero seleccione Realizar intercambio con previsualización.

    El cuadro de diálogo muestra cómo cambia la configuración de la ranura de origen en la primera fase y cómo cambia la ranura de origen y destino en la segunda fase.

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

    Cuando finalice la primera fase, el cuadro de diálogo le notifica.

  3. Cuando esté listo para completar el intercambio pendiente, seleccione Completar Intercambio en Intercambiar acción y, a continuación, seleccione el botón Completar Intercambio.

    Recorte de pantalla que muestra cómo configurar un intercambio con versión preliminar en el portal.

    Para cancelar un intercambio pendiente, seleccione Cancelar intercambio en su lugar y, a continuación, seleccione el botón Cancelar intercambio .

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

Si tiene algún problema, consulte Solución de problemas de intercambios más adelante en este artículo.

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

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

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

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.

  1. Vaya a la página de recursos de la aplicación. Seleccione Ranuras de implementación> y, a continuación, seleccione la ranura de origen deseada.

  2. En el menú de la izquierda, seleccione Configuración>Configuración General>.

  3. Para Intercambio automático habilitado, seleccione Activado. En la ranura de implementación de intercambio automático, seleccione la ranura de destino. A continuación, seleccione Guardar en la barra de comandos.

    Captura de pantalla que muestra las selecciones para configurar el intercambio automático en el espacio de producción en el portal.

  4. Ejecute una inserción de código en el espacio de origen. El intercambio automático se produce después de un breve tiempo. La actualización se refleja en la dirección URL de la ranura de destino.

Si tiene algún problema, consulte Solución de problemas de intercambios más adelante en este artículo.

Especificación de preparación personalizada

Algunas aplicaciones pueden requerir acciones de preparación personalizadas para el intercambio. Puede especificar estas acciones personalizadas mediante el applicationInitialization elemento de configuración de Web.config. El intercambio espera hasta que se completa esta preparación personalizada para realizar el intercambio con la ranura de destino. Este es un fragmento de ejemplo Web.config :

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

Para obtener más información sobre cómo personalizar el applicationInitialization elemento, consulte la entrada de blog Errores de intercambio de ranuras de implementación más comunes y cómo corregirlos.

También puede personalizar el comportamiento de preparación mediante la siguiente 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 es 200,202. Si el código de estado devuelto no está en la lista, las operaciones de preparación e intercambio se detienen. De forma predeterminada, 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, /.

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

Si tiene algún problema, consulte Solución de problemas de intercambios más adelante en este artículo.

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.

  1. En la página de recursos de la aplicación en el portal, en el menú de la izquierda, seleccione Registro de actividad.

  2. Una operación de intercambio aparece en la consulta de registro como Swap Web App Slots. Para ver los detalles, puede expandirlo y seleccionar una de las suboperaciones o errores.

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

De forma predeterminada, todas las solicitudes que realiza el cliente a la dirección URL de producción de la aplicación se enrutan al espacio de producción. Una parte del tráfico se puede enrutar a otro espacio. Esta característica es útil si necesita comentarios de usuario para una nueva actualización, pero no está listo para publicarla en producción.

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

  2. En la columna Traffic % de la ranura a la que desea enrutar, especifique un porcentaje (entre 0 y 100) para representar la cantidad de tráfico total al que desea enrutar. A continuación, seleccione Guardar.

    Captura de pantalla que muestra las selecciones del portal para enrutar un porcentaje de tráfico de solicitud a una ranura de implementación.

Después de guardar la configuración, 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.

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. Esta opción 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 nuevas ranuras tienen una regla de enrutamiento de 0%, que se muestra 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. No se enrutarán automáticamente al slot porque el porcentaje de enrutamiento está establecido en 0. Esta configuración es 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

  1. Busque y seleccione la aplicación.

  2. Seleccione implementación>ranuras de implementación>ranura para eliminar>información general. El tipo de aplicación aparece como App Service (ranura) para recordarle que está viendo una ranura de implementación.

  3. Detenga la ranura y establezca el tráfico en la ranura en cero.

  4. En la barra de comandos, seleccione Eliminar.

Captura de pantalla que muestra las selecciones para eliminar una ranura de implementación en el portal.

Automatización con plantillas de Resource Manager

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

  • buildVersion: 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: propiedad de cadena que especifica qué buildVersion valor debe tener la ranura. Si el targetBuildVersion valor no es igual al valor actual buildVersion , desencadena la operación de intercambio buscando la ranura con el valor especificado buildVersion .

Ejemplo de plantilla de Resource Manager

La siguiente plantilla de Resource Manager intercambia dos ranuras actualizando el valor buildVersion de la ranura staging y estableciendo el valor targetBuildVersion en el espacio de producción. Debe tener una ranura denominada staging.

{
    "$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. Puede ejecutarla repetidamente y generar el mismo estado de las ranuras. Sin ningún cambio en la plantilla, las ejecuciones posteriores de la misma plantilla no desencadenan ningún intercambio de ranura porque las ranuras ya están en el estado deseado.

Solución de problemas con los intercambios

Si se produce algún error durante un intercambio de ranuras, el error aparece 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 vuelve a intentarlo hasta cinco veces. Si se agota el tiempo de espera de todos los intentos, el intercambio se detiene.

  • Es posible que se produzca un error en la inicialización de caché local cuando el contenido de la aplicación supere la cuota de disco local especificada para la caché local. Para más información, consulte Introducción a la caché local de Azure App Service.

  • Durante una operación de actualización del sitio, puede producirse el siguiente error: "No se puede cambiar la ranura porque sus opciones de configuración se han preparado para el intercambio". Este error puede producirse si la primera fase de un intercambio de varias fases finaliza, pero no se ha producido la segunda fase. También puede producirse si se produce un error en un intercambio. Hay dos maneras de resolver este problema:

    • Cancele la operación de intercambio, que restablece el sitio al estado anterior.
    • Complete la operación de intercambio, que actualiza el sitio al nuevo estado deseado.

    Para obtener información sobre cómo cancelar o completar la operación de intercambio, consulte Intercambio con versión preliminar (intercambio en varias fases) anteriormente en este artículo.

  • 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 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 preparación lleguen al código de la aplicación. Para solucionar este problema, modifique las reglas de reescritura agregando las dos condiciones siguientes:

    <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 agregando 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. Los reinicios se producen porque después de un intercambio, la configuración de enlace de nombre de host deja de estar sincronizada. Esta situación por sí misma 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).

Paso siguiente