Implementación en ranuras de implementación de Azure App Service con la CLI para desarrolladores de Azure

La CLI para desarrolladores de Azure (azd) admite ranuras de implementación de Azure App Service para aplicaciones hospedadas en App Service. Puede definir ranuras en la infraestructura, implementar código en una ranura específica e intercambiar ranuras cuando esté listo para promover una versión.

Use este enfoque para las implementaciones de ensayo, las implementaciones azul-verde, las pruebas de humo y las reversiones sin agregar scripts de implementación personalizados.

Prerrequisitos

Un azd proyecto que implementa un servicio en Azure App Service.
Infraestructura como código que define los recursos de App Service en Bicep.
Un plan de servicio de aplicaciones en el nivel estándar (S1) o superior. Los niveles gratis, compartido y básico no admiten slots de implementación.

Definir un espacio de implementación en Bicep

Define el sitio de producción como de costumbre y agregue un Microsoft.Web/sites/slots recurso para cada slot que quiera que azd apunte.

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: 'my-appservice-plan'
  location: resourceGroup().location
  sku: {
    name: 'S1'
    tier: 'Standard'
  }
}

resource webApp 'Microsoft.Web/sites@2021-03-01' = {
  name: 'my-appservice'
  location: resourceGroup().location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2021-03-01' = {
  name: '${webApp.name}/staging'
  location: webApp.location
  properties: {}
}

Si usa módulos comprobados de Azure (AVM), defina los módulos de aplicación web e ranura de implementación en la misma implementación y pase el nombre de la aplicación al módulo de ranura.

Desplegar a un entorno usando azd

Ejecute azd up o azd provision y azd deploy como de costumbre.

azd up

En la primera implementación, azd se implementa en el sitio de producción y en las ranuras definidas en la infraestructura. Esta primera implementación establece el mismo punto de referencia en la aplicación principal y en cada slot.

Después de la primera implementación, azd deploy cambia cómo selecciona el objetivo de implementación cuando existen espacios disponibles. azd no continúa implementando directamente en la aplicación de producción cuando hay espacios de despliegue disponibles. En su lugar, se despliega a un slot, se valida la versión y luego se cambia a producción.

Cómo azd selecciona el destino de implementación

Cuando azd deploy se ejecuta para una instancia de App Service que tiene ranuras de implementación, selecciona el destino comprobando el historial de implementación en la aplicación principal y evaluando las ranuras disponibles.

El comportamiento funciona de la siguiente manera:

Si no existen implementaciones anteriores, azd se implementa en la aplicación principal y en todas las ranuras.
Si existen implementaciones anteriores y no existen ranuras, azd solo se implementa en la aplicación principal.
Si existen implementaciones anteriores y existe exactamente una ranura, azd solo se implementa en esa ranura.
Si existen implementaciones anteriores y existen dos o más ranuras, azd usa la ranura especificada por una variable de entorno o le pide que elija una.

Important

Después de la primera implementación, azd no se implementa directamente en la aplicación principal del App Service cuando existen espacios. Este comportamiento es intencionado y ayuda a evitar implementaciones accidentales directamente en producción. Para actualizar la producción, implemente en un espacio y luego cambie ese espacio a producción (@main).

Seleccione un espacio con una variable de entorno

Cuando el servicio tiene dos o más ranuras después de la primera implementación, puede omitir la solicitud interactiva estableciendo una variable de entorno para el servicio que desea implementar.

Utilice el siguiente formato:

AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME

Construya el nombre de la variable a partir del nombre del servicio en azure.yaml utilizando mayúsculas y reemplace los guiones por caracteres de subrayado.

Por ejemplo, si el servicio se denomina my-api, use AZD_DEPLOY_MY_API_SLOT_NAME.

azd env set AZD_DEPLOY_MY_API_SLOT_NAME staging
azd deploy my-api

Puede almacenar este valor en el azd entorno mediante azd env seto definirlo directamente en el sistema de CI antes de ejecutar azd deploy.

Si el servicio tiene exactamente una ranura, azd omite la variable de entorno porque solo hay un destino de implementación posible.

Si el servicio tiene dos o más ranuras y no se establece la variable de entorno, azd le pedirá que elija una ranura.

Omisión de la detección de ranuras e implementación en la aplicación principal

En algunos escenarios, necesita implementar directamente en la aplicación principal de App Service azd incluso cuando existen slots de implementación. Por ejemplo:

Tu pipeline de CI debe actualizar la aplicación principal sin modificar los slots existentes.
Se está recuperando de un estado incorrecto de la ranura y desea volver a implementar directamente el sitio de producción.
Está rebaseando la aplicación principal antes de configurar nuevas ranuras.

Para omitir la detección de ranuras, establezca la siguiente variable de entorno para el servicio:

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS

Construya el nombre de la variable a partir del nombre del servicio en azure.yaml utilizando mayúsculas y reemplace los guiones por caracteres de subrayado. Establezca el valor en true para omitir la detección de ranuras y realizar la implementación en la aplicación principal.

Por ejemplo, si el servicio se denomina my-api, use AZD_DEPLOY_MY_API_IGNORE_SLOTS.

azd env set AZD_DEPLOY_MY_API_IGNORE_SLOTS true
azd deploy my-api

Cuando AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS se establece en true, azd se implementa en la aplicación principal e ignora cualquier valor de AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME para el mismo servicio. Quite el valor de la variable o asígnela a false para volver al comportamiento predeterminado con reconocimiento de ranuras.

Comportamiento de CI y no interactivo

Al ejecutar o implementar azd deploy --no-prompt desde CI, la selección de ranuras se comporta de forma diferente en función del número de ranuras disponibles:

Ranuras	Comportamiento de las variables de entorno	Resultado
`0`	No es aplicable.	`azd` se implementa en la aplicación principal.
`1`	Se omite a menos que `AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS` sea `true`.	`azd` se implementa en la única ranura o en la aplicación principal cuando se omiten las ranuras.
`2+`	`AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME` es necesario para evitar que se pregunte, a menos que `AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS` sea `true`.	`azd` se implementa en la ranura especificada, se implementa en la aplicación principal cuando se omiten las ranuras o se produce un error si no se puede seleccionar ningún destino.

Si automatiza las implementaciones de una instancia de App Service que tiene dos o más ranuras, establezca AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME en el entorno de canalización antes de ejecutar azd deploy. Para forzar una implementación directa en la rama principal desde CI cuando existan slots de implementación, configure AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS como true en su lugar.

Cambio de slots de implementación de Azure App Service

Use la azure.appservice extensión para intercambiar ranuras después de la validación. Si la extensión aún no está instalada, azd le pedirá que la instale la primera vez que ejecute el comando.

Ejecute la experiencia interactiva:

azd appservice swap

Si solo existe un único slot no de producción, azd omite las indicaciones y cambia directamente con producción.

Para la automatización, especifique explícitamente las ranuras de origen y destino. Use @main para hacer referencia al espacio de producción.

azd appservice swap --src staging --dst @main
azd appservice swap --src @main --dst staging
azd appservice swap --service myapi --src staging --dst @main

Utilice estos patrones para admitir flujos de lanzamiento comunes:

Promocionar un despliegue de prueba validado a producción con --src staging --dst @main.
Revierte mediante el intercambio de producción en el espacio de ensayo con --src @main --dst staging.
Dirigir un servicio específico respaldado por App Service en un proyecto multiservicio azd con --service.

El intercambio es el método previsto para actualizar el entorno de producción una vez configurados los espacios. Use azd deploy para actualizar un slot y, a continuación, use azd appservice swap para promover ese slot a producción.

Flujo de trabajo de ranura de implementación recomendada

Defina una o varias ranuras de implementación de App Service en las plantillas de Bicep.
Provisione los recursos de App Service utilizando azd provision o azd up.
Deje que la primera implementación establezca una referencia en la aplicación principal y en cada slot.
Implemente actualizaciones de aplicaciones posteriores en una ranura de ensayo estableciendo AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME cuando tenga dos o más ranuras, o seleccionando la ranura cuando se le solicite. Para forzar una implementación directa en la rama principal desde CI cuando existen slots, establezca AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS en true en su lugar.
Valide la implementación por etapas.
Ejecute azd appservice swap --src <slot> --dst @main para promover la versión.
Si es necesario, ejecute el intercambio inverso para restaurar el estado anterior.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-06-11