Configurar ambientes de teste no Serviço de Aplicações do Azure

Artigo
09/27/2022
20 minutos para ler

Quando implementar a sua aplicação web, web app no Linux, back end móvel ou app API para Serviço de Aplicações do Azure, pode utilizar uma faixa de implementação separada em vez da faixa de produção padrão quando estiver a executar o nível de plano standard, premium ou Serviço de Aplicações isolado. As slots de implementação são aplicações ao vivo com os seus próprios nomes de hospedeiros. Os elementos de conteúdo e configurações da aplicação podem ser trocados entre duas ranhuras de implantação, incluindo a ranhura de produção.

A implementação da sua aplicação numa faixa horária não-produção tem os seguintes benefícios:

Pode validar alterações de aplicações numa ranhura de implementação de encenação antes de a trocar com a ranhura de produção.
A implementação de uma aplicação num bloco primeiro e trocá-la para produção garante que todas as instâncias do bloco são preparadas antes de serem trocadas para produção. Isto elimina o tempo de inatividade quando implementa a aplicação. A reorientação do tráfego é perfeita, e nenhum pedido é retirado por causa de operações de troca. Pode automatizar todo este fluxo de trabalho configurando o swap automático quando não é necessária validação de pré-troca.
Depois de uma troca, a ranhura com app previamente encenada tem agora a aplicação de produção anterior. Se as alterações trocadas na ranhura de produção não forem como espera, pode efetuar a mesma troca imediatamente para recuperar o seu "último bom site conhecido".

Cada Serviço de Aplicações nível de plano suporta um número diferente de slots de implantação. Não há nenhuma taxa adicional para usar slots de implantação. Para saber o número de slots que a sua aplicação suporta, consulte Serviço de Aplicações limites.

Para escalar a sua aplicação para um nível diferente, certifique-se de que o nível alvo suporta o número de slots que a sua aplicação já utiliza. Por exemplo, se a sua aplicação tiver mais de cinco slots, não pode escaloná-la para o nível Standard , porque o nível Standard suporta apenas cinco slots de implementação.

Adicionar um bloco

A aplicação deve estar a ser executada no nível Standard, Premium ou Isolado para que possa ativar várias faixas de implantação.

no portal do Azure, procure e selecione Serviços de Aplicações e selecione a sua aplicação.
No painel esquerdo, selecione Slotde>adicionar slot de implementação.

Nota

Se a aplicação ainda não estiver no nível Standard, Premium ou Isolado , recebe uma mensagem que indica os níveis suportados para permitir a publicação encenada. Neste momento, tem a opção de selecionar Upgrade e ir ao separador Escala da sua aplicação antes de continuar.
Na caixa de diálogo de ranhura , dê um nome à ranhura e selecione se clone uma configuração de aplicação a partir de outra ranhura de implementação. Selecione Adicionar para continuar.

Pode clonar uma configuração a partir de qualquer ranhura existente. As definições que podem ser clonadas incluem configurações de aplicações, cadeias de conexão, versões de estrutura linguística, tomadas web, versão HTTP e bitness da plataforma.

Nota

Atualmente, a VNET e o Private Endpoint não são clonados através de slots.

Depois de adicionar a ranhura, selecione Perto para fechar a caixa de diálogo. A nova ranhura é agora mostrada na página de slots de Implementação . Por padrão, o tráfego % está definido para 0 para a nova ranhura, com todo o tráfego de clientes encaminhado para a ranhura de produção.
Selecione a nova ranhura de implementação para abrir a página de recursos da ranhura.

A ranhura de encenação tem uma página de gestão como qualquer outra aplicação Serviço de Aplicações. Pode alterar a configuração da ranhura. Para lembrá-lo que está a visualizar a ranhura de implementação, o nome da aplicação é apresentado como <nome> de aplicação/<nome> de slot, e o tipo de aplicação é Serviço de Aplicações (Slot). Também pode ver a ranhura como uma aplicação separada no seu grupo de recursos, com as mesmas designações.
Selecione o URL da aplicação na página de recursos da ranhura. A ranhura de implementação tem o seu próprio nome de anfitrião e é também uma aplicação ao vivo. Para limitar o acesso do público à faixa horária de implantação, consulte Serviço de Aplicações do Azure restrições IP.

A nova ranhura de implementação não tem conteúdo, mesmo que clone as definições de uma ranhura diferente. Por exemplo, podes publicar nesta slot com o Git. Você pode implantar para a ranhura a partir de um ramo de repositório diferente ou um repositório diferente.

O URL da ranhura será do formato http://sitename-slotname.azurewebsites.net. Para manter o comprimento do URL dentro dos limites necessários de DNS, o nome do site será truncado em 40 caracteres, o nome da ranhura será truncado em 19 caracteres, e um adicional de 4 caracteres aleatórios será anexado para garantir que o nome de domínio resultante é único.

O que acontece durante uma troca

Trocar etapas de operação

Quando troca duas ranhuras (normalmente de uma ranhura de paragem para a ranhura de produção), Serviço de Aplicações faz o seguinte para garantir que a ranhura do alvo não experimenta tempo de inatividade:

Aplicar as seguintes definições da ranhura-alvo (por exemplo, a ranhura de produção) a todas as instâncias da ranhura de origem:
- Se aplicável, definições de aplicações específicas de slot e cadeias de ligação.
- Definições de implementação contínua , se ativadas.
- Serviço de Aplicações configurações de autenticação, se ativado.
Qualquer um destes casos desencadeia todas as instâncias na ranhura de origem para reiniciar. Durante a troca com pré-visualização, isto marca o fim da primeira fase. A operação de troca é interrompida e pode validar que a ranhura de origem funciona corretamente com as definições da ranhura do alvo.
Aguarde por todas as instâncias da ranhura de origem para completar o seu reinício. Se alguma instância não reiniciar, a operação de troca reverte todas as alterações na ranhura de origem e interrompe o funcionamento.
Se a cache local estiver ativada, desencadeie a inicialização da cache local fazendo um pedido HTTP à raiz da aplicação ("/") em cada instância da ranhura de origem. Aguarde até que cada instância retorne qualquer resposta HTTP. A inicialização da cache local provoca um novo recomeço em cada instância.
Se a troca automática estiver ativada com aquecimento personalizado, desencadeie o Início da Aplicação fazendo um pedido HTTP à raiz da aplicação ("/") em cada instância da ranhura de origem.

Se applicationInitialization não for especificado, desemocione um pedido HTTP para a raiz de aplicação da ranhura de origem em cada instância.

Se um caso retornar qualquer resposta HTTP, é considerado como aquecido.
Se todas as instâncias da ranhura de origem forem aquecidas com sucesso, troque as duas ranhuras trocando as regras de encaminhamento para as duas ranhuras. Após este passo, a ranhura-alvo (por exemplo, a ranhura de produção) tem a aplicação que já foi aquecida na ranhura de origem.
Agora que a ranhura de origem possui a aplicação de pré-troca anteriormente na ranhura alvo, execute a mesma operação aplicando todas as definições e reiniciando as instâncias.

Em qualquer ponto da operação de troca, todo o trabalho de inicialização das aplicações trocadas ocorre na ranhura de origem. A ranhura do alvo permanece on-line enquanto a ranhura de origem está a ser preparada e aquecida, independentemente de onde a troca tenha sucesso ou falhe. Para trocar uma ranhura de encenação com a ranhura de produção, certifique-se de que a ranhura de produção é sempre a ranhura-alvo. Desta forma, a operação de troca não afeta a sua aplicação de produção.

Nota

Os casos nas suas instâncias de produção anteriores (aqueles que serão trocados em encenação após esta operação de troca) serão reciclados rapidamente no último passo do processo de troca. Caso tenha alguma operação de longa duração na sua aplicação, elas serão abandonadas quando os trabalhadores reciclam. Isto também se aplica a aplicações de função. Portanto, o seu código de aplicação deve ser escrito de forma tolerante a falhas.

Que configurações são trocadas?

Quando clona a configuração de outra ranhura de implantação, a configuração clonada é editável. Alguns elementos de configuração seguem o conteúdo através de uma troca (não específica para a ranhura), enquanto outros elementos de configuração permanecem na mesma ranhura após uma troca (específica slot). As listas que se seguem mostram as definições que mudam quando troca slots.

Definições que são trocadas:

Configurações gerais, tais como versão-quadro, tomadas web de 32/64 bits
Definições de aplicativos (pode ser configurado para manter uma ranhura)
Cadeias de ligação (podem ser configuradas para se colarem a uma ranhura)
Mapeamentos de manipulador
Certificados públicos
Conteúdo da WebJobs
Ligações híbridas *
Pontos finais de serviço *
Rede de Entrega de Conteúdos Azure *
Mapeamentos de caminhos

As características marcadas com um asterisco (*) estão planeadas para não seremgrafadas.

Definições que não são trocadas:

Pontos finais de publicação
Nomes de domínio personalizados
Certificados não públicos e definições de TLS/SSL
Configurações de escala
Agendadores WebJobs
Restrições ip
Sempre ligado
Definições de diagnóstico
Partilha de recursos transversais à origem (CORS)
Integração da rede virtual
Identidades geridas
Configurações que terminam com o sufixo _EXTENSION_VERSION

Nota

Para tornar permutáveis as definições acima mencionadas, adicione a definição WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS da aplicação em cada ranhura da aplicação e defina o seu valor para 0 ou false. Estas definições são todas permutáveis ou não são nada. Não podes fazer apenas algumas definições trocadas e não as outras. As identidades geridas nunca são trocadas e não são afetadas por esta definição de aplicações de substituição.

Algumas definições de aplicações que se aplicam a definições não mapeadas também não são trocadas. Por exemplo, uma vez que as definições de diagnóstico não são trocadas, as definições de aplicações relacionadas como WEBSITE_HTTPLOGGING_RETENTION_DAYS e DIAGNOSTICS_AZUREBLOBRETENTIONDAYS também não são trocadas, mesmo que não apareçam como configurações de slot.

Para configurar uma definição de aplicação ou cadeia de ligação para se manter numa ranhura específica (não trocada), aceda à página de Configuração para essa ranhura. Adicione ou edite uma definição e, em seguida, selecione a definição de ranhura de implementação. A seleção desta caixa de verificação diz Serviço de Aplicações que a definição não é permutável.

Definição de slot

Trocar duas ranhuras

Pode trocar slots de implementação na página de slots de implementação da sua aplicação e na página 'Vista Geral '. Para obter detalhes técnicos sobre a permuta de slot, consulte o que acontece durante a troca.

Importante

Antes de trocar uma aplicação de uma ranhura de implantação para a produção, certifique-se de que a produção é a sua ranhura alvo e que todas as definições na ranhura de origem estão configuradas exatamente como você quer ter em produção.

Para trocar slots de implementação:

Vá à página de slots de implementação da sua aplicação e selecione Swap.

A caixa de diálogo Swap mostra as definições na origem selecionada e slots de destino que serão alteradas.
Selecione as ranhuras de Origem e Destino desejadas. Normalmente, o alvo é a ranhura de produção. Além disso, selecione os separadores 'Alterações de Origem' e alterações de destino e verifique se as alterações de configuração são esperadas. Quando terminar, pode trocar as ranhuras imediatamente selecionando Swap.

Para ver como a sua ranhura de destino funcionaria com as novas definições antes de o swap realmente acontecer, não selecione Swap, mas siga as instruções em Swap com pré-visualização.
Quando terminar, feche a caixa de diálogo selecionando Close.

Se tiver algum problema, consulte as trocas de resolução de problemas.

Troca com pré-visualização (troca de várias fases)

Antes de trocar para a produção como a ranhura alvo, valide que a aplicação funciona com as definições trocadas. A ranhura de origem também é aquecida antes da conclusão do swap, o que é desejável para aplicações críticas da missão.

Quando executa uma troca com pré-visualização, Serviço de Aplicações executa a mesma operação de troca, mas faz uma pausa após o primeiro passo. Em seguida, pode verificar o resultado da ranhura de paragem antes de concluir a troca.

Se cancelar a troca, Serviço de Aplicações reaplica elementos de configuração para a ranhura de origem.

Para trocar com pré-visualização:

Siga os passos nas ranhuras de implementação de Swap , mas selecione 'Executar swap' com pré-visualização.

A caixa de diálogo mostra como a configuração na ranhura de origem muda na fase 1 e como a origem e a ranhura do alvo mudam na fase 2.
Quando estiver pronto para iniciar a troca, selecione Start Swap.

Quando a fase 1 terminar, é notificado na caixa de diálogo. Pré-visualizar a troca na ranhura de origem indo para https://<app_name>-<source-slot-name>.azurewebsites.net.
Quando estiver pronto para concluir a troca pendente, selecione Complete Swap in Swap action e selecione Complete Swap.

Para cancelar uma troca pendente, selecione Cancelar Troca .
Quando terminar, feche a caixa de diálogo selecionando Close.

Se tiver algum problema, consulte as trocas de resolução de problemas.

Para automatizar uma troca em várias fases, consulte Automação com PowerShell.

Reverta uma troca

Se ocorrerem erros na ranhura do alvo (por exemplo, a ranhura de produção) após uma troca de faixas, restaure as ranhuras nos seus estados de pré-troca troca trocando imediatamente as mesmas duas ranhuras.

Configurar a troca automática

Nota

A troca automática não é suportada em aplicações web em Linux e Web App para contentores.

A troca automática dinamiza cenários Azure DevOps onde pretende implementar a sua aplicação continuamente com zero arranques frios e zero tempo de inatividade para os clientes da app. Quando a troca automática é ativada a partir de uma ranhura para a produção, sempre que empurra as alterações de código para essa ranhura, Serviço de Aplicações troca automaticamente a aplicação em produção depois de aquecida na ranhura de origem.

Nota

Antes de configurar a troca automática para a ranhura de produção, considere testar a troca automática numa ranhura de alvo não produtivo.

Para configurar a troca automática:

Vá à página de recursos da sua aplicação. Selecione slots><de implementação desejadas Configuração geral de ranhura>>> de origem.
Para troca automática ativada, selecione On. Em seguida, selecione a ranhura de destino desejada para a ranhura de implementação de troca automática e selecione Guardar na barra de comando.
Execute um código de impulso para a ranhura de origem. A troca automática ocorre após um curto período de tempo e a atualização é refletida no URL da sua ranhura alvo.

Se tiver algum problema, consulte as trocas de resolução de problemas.

Especifique o aquecimento personalizado

Algumas aplicações podem necessitar de ações de aquecimento personalizadas antes da troca. O applicationInitialization elemento de configuração no web.config permite especificar as ações de inicialização personalizadas. A operação de troca aguarda que este aquecimento personalizado termine antes de trocar com a ranhura do alvo. Aqui está uma amostra web.config fragmento.

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

Para obter mais informações sobre a personalização do applicationInitialization elemento, consulte as falhas de swap de slot de implementação mais comuns e como corrigi-las.

Também pode personalizar o comportamento de aquecimento com uma ou ambas as seguintes definições de aplicações:

WEBSITE_SWAP_WARMUP_PING_PATH: O caminho para ping sobre HTTP para aquecer o seu site. Adicione esta definição de aplicação especificando um caminho personalizado que começa com um corte como o valor. Um exemplo é /statuscheck. O valor predefinido é /.
WEBSITE_SWAP_WARMUP_PING_STATUSES: Códigos de resposta HTTP válidos para o funcionamento do aquecimento. Adicione esta definição de aplicação com uma lista separada por vírgula de códigos HTTP. Um exemplo é 200,202 . Se o código de estado devolvido não estiver na lista, as operações de aquecimento e troca são interrompidas. Por predefinição, todos os códigos de resposta são válidos.
WEBSITE_WARMUP_PATH: Um caminho relativo no local que deve ser pingado sempre que o site reinicie (não só durante as trocas de ranhuras). Os valores de exemplo incluem /statuscheck ou o caminho da raiz, /.

Nota

O <applicationInitialization> elemento de configuração faz parte de cada arranque de aplicações, enquanto as duas configurações de aplicações de comportamento de aquecimento se aplicam apenas a trocas de slots.

Se tiver algum problema, consulte as trocas de resolução de problemas.

Monitorizar uma troca

Se a operação de troca demorar muito tempo a ser concluída, poderá obter informações sobre a operação de troca no registo de atividade.

Na página de recursos da sua aplicação no portal, no painel esquerdo, selecione Registo de Atividade.

Uma operação de troca aparece na consulta de registo como Swap Web App Slots. Pode expandi-lo e selecionar uma das suboperações ou erros para ver os detalhes.

Tráfego de rotas

Por padrão, todos os pedidos do cliente para o URL de produção da aplicação (http://<app_name>.azurewebsites.net) são encaminhados para a ranhura de produção. Pode encaminhar uma parte do tráfego para outra ranhura. Esta funcionalidade é útil se necessitar de feedback do utilizador para uma nova atualização, mas não está pronto para a lançar para a produção.

Tráfego de produção de rotas automaticamente

Para encaminhar automaticamente o tráfego de produção:

Vá à página de recursos da sua aplicação e selecione slots de implementação.
Na coluna Traffic % da faixa horária para a qual pretende encaminhar, especifique uma percentagem (entre 0 e 100) para representar a quantidade total de tráfego que pretende encaminhar. Selecione Guardar.

Após a definição ser guardada, a percentagem especificada de clientes é encaminhada aleatoriamente para a ranhura de não produção.

Depois de um cliente ser automaticamente encaminhado para uma faixa específica, é "fixado" para essa ranhura durante a vida dessa sessão de clientes. No navegador cliente, pode ver a ranhura a que a sua sessão está fixada, olhando para o x-ms-routing-name cookie nos seus cabeçalhos HTTP. Um pedido que é encaminhado para a ranhura de "encenação" tem o cookie x-ms-routing-name=staging. Um pedido que é encaminhado para a ranhura de produção tem o cookie x-ms-routing-name=self.

Nota

Também pode utilizar o az webapp traffic-routing set comando no CLI Azure para definir as percentagens de encaminhamento de ferramentas CI/CD como GitHub Actions, oleodutos DevOps ou outros sistemas de automatização.

Tráfego de produção de rotas manualmente

Além do encaminhamento automático de tráfego, Serviço de Aplicações podem encaminhar os pedidos para uma faixa horária específica. Isto é útil quando pretende que os seus utilizadores possam optar ou optar pela sua aplicação beta. Para encaminhar o tráfego de produção manualmente, utilize o x-ms-routing-name parâmetro de consulta.

Para permitir que os utilizadores optem pela sua aplicação beta, por exemplo, pode colocar este link na sua página web:

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

A cadeia x-ms-routing-name=self especifica a ranhura de produção. Depois de o navegador cliente aceder ao link, é redirecionado para a ranhura de produção. Cada pedido subsequente tem o x-ms-routing-name=self cookie que fixa a sessão para a ranhura de produção.

Para permitir que os utilizadores optem pela sua aplicação beta, desaprote o mesmo parâmetro de consulta para o nome da ranhura de não produção. Eis um exemplo:

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

Por predefinição, são dadas novas ranhuras de 0%, mostrada em cinza. Quando definir explicitamente este valor para 0% (mostrado em texto preto), os seus utilizadores podem aceder manualmente à ranhura de paragem utilizando o x-ms-routing-name parâmetro de consulta. Mas não serão encaminhados automaticamente para a ranhura porque a percentagem de encaminhamento está definida para 0. Este é um cenário avançado onde pode "esconder" a sua ranhura de encenação do público, ao mesmo tempo que permite que as equipas internas testem alterações na ranhura.

Eliminar uma ranhura

Procure e selecione a sua aplicação. Selecione slots><de implementação para eliminar>>o Visão Geral. O tipo de aplicação é mostrado como Serviço de Aplicações (Slot) para lembrá-lo que está a visualizar uma ranhura de implementação. Selecione Excluir na barra de comando.

Eliminar uma ranhura de implantação

Automatizar com o PowerShell

Nota

Para interagir com o Azure, recomenda-se o módulo Azure Az PowerShell. Consulte a instalação Azure PowerShell para começar. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.

Azure PowerShell é um módulo que fornece cmdlets para gerir o Azure através de Windows PowerShell, incluindo suporte para gerir slots de implementação em Serviço de Aplicações do Azure.

Para obter informações sobre a instalação e configuração Azure PowerShell, bem como autenticar Azure PowerShell com a sua assinatura Azure, consulte como instalar e configurar Microsoft Azure PowerShell.

Criar uma aplicação Web

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

Criar uma ranhura

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

Inicie uma troca com uma pré-visualização (troca de várias fases) e aplique a configuração da ranhura de destino na ranhura de origem

$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

Cancelar uma troca pendente (trocar com revisão) e restaurar a configuração da ranhura de origem

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

Troca de blocos de implementação

$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

Monitorize eventos de troca no registo de atividades

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

Eliminar uma ranhura

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

Para efetuar uma permuta de slot a partir da ranhura de produção, a identidade necessita (no mínimo) de permissões para realizar a Microsoft.Web/sites/slotsswap/Action operação. Para mais informações, consulte as operações do fornecedor de recursos

Automatize com modelos de Resource Manager

Os modelos Resource Manager Azure são ficheiros JSON declarativos usados para automatizar a implementação e configuração dos recursos Azure. Para trocar slots utilizando modelos de Resource Manager, irá definir duas propriedades no Microsoft.Web/sites/slots e recursos Microsoft.Web/sites:

buildVersion: trata-se de uma propriedade de cordas que representa a versão atual da aplicação implantada na ranhura. Por exemplo: "v1", "1.0.0.1", ou "2019-09-20T11:53:25.2887393-07:00".
targetBuildVersion: esta é uma propriedade de cordas que especifica o que buildVersion a ranhura deve ter. Se o targetBuildVersion não for igual à corrente buildVersion, então isto irá desencadear a operação de troca encontrando a ranhura que tem a especificada buildVersion.

Modelo de Resource Manager exemplo

O modelo seguinte Resource Manager atualizará a buildVersion ranhura de paragem e definirá a targetBuildVersion ranhura de produção. Isto vai trocar as duas ranhuras. O modelo pressupõe que já tem um webapp criado com uma ranhura chamada "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')]"
            }
        }        
    ]
}

Este modelo de Resource Manager é idempotente, o que significa que pode ser executado repetidamente e produzir o mesmo estado das ranhuras. Após a primeira execução, targetBuildVersion corresponderá à corrente buildVersion, para que não seja acionada uma troca.

Automatize com o CLI

Para os comandos Azure CLI para slots de implementação, consulte a ranhura de implementação do webapp az.

Trocas de resolução de problemas

Se ocorrer algum erro durante uma troca de ranhuras, é registado no D:\home\LogFiles\eventlog.xml. Também está registado no registo de erros específico da aplicação.

Aqui estão alguns erros de troca comuns:

Um pedido HTTP para a raiz da aplicação é cronometrado. A operação de troca aguarda 90 segundos por cada pedido HTTP e retrição até 5 vezes. Se todas as recauchuções forem cronometradas, a operação de troca é interrompida.
A inicialização de cache local pode falhar quando o conteúdo da aplicação exceder a quota de disco local especificada para a cache local. Para mais informações, consulte a visão geral da cache local.
Durante o aquecimento personalizado, os pedidos HTTP são feitos internamente (sem passar pelo URL externo). Podem falhar com certas regras de reescrita de URL em Web.config. Por exemplo, as regras para redirecionar nomes de domínio ou fazer cumprir HTTPS podem impedir que os pedidos de aquecimento cheguem ao código da aplicação. Para contornar esta questão, modifique as suas regras de reescrita adicionando as seguintes duas condições:
```
<conditions>
  <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
Sem um aquecimento personalizado, as regras de reescrita de URL ainda podem bloquear pedidos HTTP. Para contornar esta questão, modifique as suas regras de reescrita adicionando a seguinte condição:
```
<conditions>
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
Após trocas de slot, a aplicação pode experimentar recomeços inesperados. Isto porque, após uma troca, a configuração de ligação do nome anfitrião sai de sincronização, o que por si só não provoca reinício. No entanto, certos eventos de armazenamento subjacentes (tais como falhas no volume de armazenamento) podem detetar estas discrepâncias e forçar todos os processos dos trabalhadores a reiniciar. Para minimizar este tipo de reinicialização, defina a definição daWEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 aplicação em todas as ranhuras. No entanto, esta configuração da aplicação não funciona com aplicações da Windows Communication Foundation (WCF).

Passos seguintes

Bloquear o acesso a faixas horárias não produção