Implemente para slots de implantação do Serviço de Aplicações do Azure com o Azure Developer CLI

Azure Developer CLI (azd) suporta slots de implementação do Serviço de Aplicações do Azure para aplicações alojadas no App Service. Podes definir slots na tua infraestrutura, implementar código num slots específico e trocar slots quando estiveres pronto para promover um lançamento.

Utilize esta abordagem para staging, implementações blue-green, testes de fumo e revertimentos sem adicionar scripts personalizados de implementação.

Pré-requisitos

  • Um azd projeto que implementa um serviço para o Serviço de Aplicações do Azure.
  • Infraestrutura como código que define os seus recursos de Serviços de Aplicações no Bicep.
  • Um plano de App Service no nível Standard (S1) ou superior. Os níveis Livre, Partilhado e Básico não suportam slots de implementação.

Defina um slot de implantação no Bicep

Defina o seu local de produção como habitualmente, depois adicione um Microsoft.Web/sites/slots recurso para cada slot que pretende azd atingir.

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: {}
}

Se usar Azure Verified Modules (AVM), defina a aplicação web e os módulos de slot de implementação na mesma implementação e passe o nome da app para o módulo de slot.

Desloca-te para um slot com azd

Execute azd up ou azd provision e azd deploy como habitualmente.

azd up

Na primeira implementação, azd é implementado no site de produção e em quaisquer slots definidos na tua infraestrutura. Esta primeira implementação estabelece a mesma base em toda a aplicação principal e em cada slot.

Após a primeira implementação, azd deploy muda a forma como seleciona o destino de implementação quando existem slots. azd não continua a ser implementado diretamente na aplicação de produção quando há espaços disponíveis. Em vez disso, implementas para um slot, validas o lançamento e depois trocas para produção.

Como o azd seleciona o alvo de implementação

Quando azd deploy é executado para um Serviço de Aplicações que tem espaços de implementação, seleciona o destino verificando o histórico de implementação na aplicação principal e depois avaliando os espaços disponíveis.

O comportamento funciona da seguinte forma:

  • Se não existirem implementações anteriores, azd implementa na aplicação principal e em todos os slots.
  • Se existirem implementações anteriores e não houver slots, azd implementa apenas na aplicação principal.
  • Se existirem implementações anteriores e existir exatamente um slot, azd implementa apenas nesse espaço.
  • Se existirem implementações anteriores e existirem dois ou mais slots, azd usa o slot especificado por uma variável de ambiente ou pede-te para escolher um.

Importante

Após a primeira implementação, azd não é implementado diretamente na aplicação principal do App Service quando existem slots. Este comportamento é intencional e ajuda a prevenir implementações acidentais diretas para produção. Para atualizar a produção, implemente para um slot e depois troque o slot para produção (@main).

Selecione um slot com uma variável de ambiente

Quando o seu serviço tem dois ou mais slots após a primeira implementação, pode saltar o prompt interativo ao definir uma variável de ambiente para o serviço que pretende implementar.

Use o seguinte formato:

AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME

Constrói o nome da variável a partir do nome do serviço em azure.yaml usando maiúsculas e substituindo hífens por sublinhados.

Por exemplo, se o seu serviço tem um nome my-api, use AZD_DEPLOY_MY_API_SLOT_NAME.

azd env set AZD_DEPLOY_MY_API_SLOT_NAME staging
azd deploy my-api

Pode armazenar este valor no seu azd ambiente usando azd env set, ou defini-lo diretamente no seu sistema CI antes de executar azd deploy.

Se o teu serviço tiver exatamente um slot, azd ignora a variável de ambiente porque só existe um possível alvo de implementação.

Se o seu serviço tiver dois ou mais slots e a variável ambiente não estiver definida, ele azd convida-o a escolher um slot.

Ignorar a deteção de slots e implementar na aplicação principal

Em alguns cenários, é necessário azd efetuar a implementação diretamente na aplicação App Service principal, mesmo quando existem slots. Por exemplo:

  • O seu pipeline de CI precisa de atualizar a aplicação principal deixando os slots existentes intocados.
  • Estás a recuperar de um mau estado do slot e queres redistribuir diretamente o local de produção.
  • Estás a redefinir a linha de base da aplicação principal antes de configurares novos slots.

Para contornar a deteção de slots, defina a seguinte variável de ambiente para o serviço:

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS

Constrói o nome da variável a partir do nome do serviço em azure.yaml usando maiúsculas e substituindo hífens por sublinhados. Defina o valor como true para ignorar a deteção de slots e implementar na aplicação principal.

Por exemplo, se o seu serviço tem um nome my-api, use AZD_DEPLOY_MY_API_IGNORE_SLOTS.

azd env set AZD_DEPLOY_MY_API_IGNORE_SLOTS true
azd deploy my-api

Quando AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS está definido para true, azd é implementado para a aplicação principal e ignora qualquer AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME valor para o mesmo serviço. Remova a definição da variável ou defina-a como false para voltar ao comportamento padrão sensível a slots.

IC e comportamento não interativo

Quando executa azd deploy --no-prompt ou implementa a partir do CI, a seleção de slots comporta-se de forma diferente dependendo do número de slots disponíveis:

Slots Comportamento das variáveis ambientais Result
0 Não aplicável. azd É implementado na aplicação principal.
1 Ignorado a menos que AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS seja true. azd é implementado no único slot ou na aplicação principal quando os slots são ignorados.
2+ AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME é necessário para evitar pedidos de confirmação, a menos que AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS seja true. azd implementa no slot especificado, implementa na aplicação principal quando os slots são ignorados, ou falha se não for possível selecionar um destino.

Se automatizares implementações para um Serviço de Aplicações com dois ou mais slots, define AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME no ambiente do pipeline antes de executar azd deploy. Para forçar uma implementação direta para o principal a partir do CI quando existem slots, defina AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS para true em vez disso.

Trocar slots de implementação do Serviço de Aplicações do Azure

Use a azure.appservice extensão para trocar de slots após a validação. Se a extensão ainda não estiver instalada, azd pede-te para a instalar na primeira vez que executas o comando.

Execute a experiência interativa:

azd appservice swap

Se existir apenas um slot não-produtivo, azd ignora os prompts e troca diretamente com o ambiente de produção.

Para automação, especifique explicitamente os slots de origem e destino. Use @main para referenciar o slot de produção.

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

Use estes padrões para suportar fluxos de libertação comuns:

  • Promover uma implementação de etapas validada para produção com --src staging --dst @main.
  • Reverta substituindo a produção de volta para o slot de teste com --src @main --dst staging.
  • Direcionar um serviço específico apoiado por App Service num projeto multiserviço azd com --service.

O procedimento recomendado para atualizar a produção é a troca, após a configuração dos slots. Use azd deploy para atualizar um slot, e depois use azd appservice swap para promover esse slot à produção.

  1. Defina um ou mais espaços de implementação de Serviços de Aplicações nos seus modelos Bicep.
  2. Provisione os recursos do Serviço de Aplicações usando azd provision ou azd up.
  3. Deixe que a primeira implementação estabeleça uma base na aplicação principal e em cada slot.
  4. Implemente atualizações futuras da aplicação num slot de staging definindo AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME caso tenha dois ou mais slots, ou selecionando o slot quando solicitado. Para forçar uma implementação direta para o principal a partir do CI quando existem slots, defina AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS para true em vez disso.
  5. Valida a implementação em etapas.
  6. Executa azd appservice swap --src <slot> --dst @main para promover o lançamento.
  7. Se necessário, faz a troca inversa para recuar.