Configuración de entornos de ensayo en Azure App Service
Nota:
A partir del 1 de junio de 2024, todas las aplicaciones de App Service recién creadas tendrán la opción de generar un nombre de host predeterminado único mediante la convención de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Los nombres de aplicación existentes permanecerán sin cambios.
Ejemplo: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Para más información, consulte Nombre de host predeterminado único para el recurso 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.
En este vídeo se muestra cómo configurar entornos de ensayo en Azure App Service.
Los pasos del vídeo también se describen en las secciones siguientes.
Requisitos previos
Para obtener información sobre los permisos que necesita para realizar la operación de ranura que desee, consulte Operaciones del proveedor de recursos (busque ranura, por ejemplo).
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.
En Azure Portal, navegue hasta la página de administración de la aplicación.
En el panel izquierdo, seleccione Ranuras de implementación>Agregar ranura.
Nota
Si la aplicación aún no está en el nivel Estándar, Premium o Aislado , seleccione Actualizar y vaya a la pestaña Escalar de la aplicación antes de continuar.
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.
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.
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.
Seleccione la nueva ranura de implementación para abrir su página de recursos.
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.
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 obtención del perfil de publicación de Azure App Service puede proporcionar información necesaria para realizar la implementación en la ranura. El perfil lo puede importar Visual Studio 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 de DNS necesarios, el nombre del sitio se truncará en 40 caracteres y el nombre de espacio y el nombre de sitio combinados deben tener menos de 59 caracteres.
Qué ocurre durante un intercambio
Pasos del intercambio
Cuando intercambia dos ranuras (normalmente de un espacio de ensayo como origen al espacio de producción como destino), App Service hace lo siguiente para garantizar que el espacio de destino no experimenta tiempo de inactividad:
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:
- Opciones de configuración de aplicación y cadenas de conexión específicas de la ranura, si procede.
- Configuración de implementación continua, si está habilitada.
- Configuración de autenticación de App Service configuración, si está habilitada.
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 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.
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.
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.
Si el intercambio automático está habilitado con la preparación personalizada, desencadene el inicio de aplicación personalizado en cada instancia de la ranura de origen.
Si
applicationInitializationno 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.
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.
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:
- Pila de lenguaje y versión, 32/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 *
- 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:
- Configuración general no mencionada en Configuración que se intercambia
- 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 y configuración relacionada
- Configuración que termina con el sufijo _EXTENSION_VERSION
- Configuración creada por el Conector de servicio
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.
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:
Vaya a la página Ranuras de implementación y seleccione 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.
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.
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.
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.
Nota
No se puede usar el intercambio con vista previa si una de las ranuras tiene la autenticación de sitio habilitada.
Para realizar el intercambio con vista previa:
Siga los pasos que se indican en Intercambio de ranuras de implementación, pero seleccione Realizar intercambio con versión preliminar .
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.
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.netpara obtener una vista previa del intercambio en la ranura de origen.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 y, a continuación, seleccione Cancelar intercambio en la parte inferior.
Cuando haya terminado, seleccione Cerrar para cerrar el cuadro de diálogo.
Si tiene problemas, consulte Solución de problemas con los intercambios.
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:
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.
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.
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ía200,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/statuschecko 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 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 (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.
Para enrutar automáticamente el tráfico de producción:
Vaya a la página de recursos de la aplicación y seleccione Ranuras de implementación.
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.
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.
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. Antes de eliminar una ranura, asegúrese de detenerla y establecer el tráfico en la ranura en cero. En la barra de comandos, seleccione Eliminar.
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, establezca dos propiedades en los recursos Microsoft.Web/sites/slots y 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ébuildVersiondebe tener la ranura. Si eltargetBuildVersionno es igual albuildVersionactual, desencadena la operación de intercambio encontrando la ranura con elbuildVersionespecificado.
Ejemplo de plantilla de Resource Manager
La siguiente plantilla de Resource Manager intercambia dos ranuras actualizando el buildVersion de la ranura staging y estableciendo el targetBuildVersion en el espacio de producción. Se supone que ha creado 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, lo que significa que puede ejecutarse repetidamente y producir 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, 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 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". Esto puede ocurrir si se ha completado la fase 1 del intercambio con vista previa (intercambio multifásico), pero la fase 2 aún no se ha realizado o se ha producido un error en un intercambio. Hay dos maneras de resolver este problema:
- Cancelar la operación de intercambio que restablecerá el sitio de nuevo al estado anterior
- Completar la operación de intercambio que actualizará el sitio al nuevo estado deseado.
Consulte el intercambio con la versión preliminar (intercambio de varias fases) para obtener información sobre cómo cancelar o completar la operación de intercambio.
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=1en todas las ranuras. Sin embargo, esta configuración de la aplicación no funciona con aplicaciones de Windows Communication Foundation (WCF).