• Artigo

Agosto de 2019

Volume 34 – Número 8

[Azure DevOps]

Introdução ao Gerenciador de Implantação do Azure

Por David Tepper

Qual o nível de complexidade dos seus serviços? Você tem dezenas de recursos divididos em vários grupos e regiões de recursos? Centenas? Milhares? Seu sistema de engenharia facilita a definição declarativa da topologia desses recursos, como eles funcionam juntos e como eles podem ser implantados e atualizados de forma segura e escalável?

Atualmente em versão prévia, o Azure Deployment Manager (ADM) fornece um novo conjunto de recursos para o Azure Resource Manager (bit.ly/2Ib6WHM) e expande consideravelmente seus recursos de implantação. O ADM é para você que precisa implantar um serviço complexo em várias regiões, ou obter mais controle sobre quando os recursos são implantados um com o outro, ou limitar a exposição de seus clientes a atualizações incorretas, capturando-os em andamento.

O ADM permite que você execute distribuições de recursos em fases, o que significa que eles são implantados região por região de maneira ordenada. Como parte dessa distribuição, a integridade de seus serviços é monitorada e, se for detectada uma degradação inaceitável do desempenho, a implantação será interrompida automaticamente, permitindo solucionar problemas e reduzir a escala do impacto. Essas ferramentas são usadas internamente por centenas de serviços da Microsoft para garantir implantações seguras e confiáveis, garantindo HA e prevenindo ou reduzindo drasticamente a indisponibilidade do serviço causada por regressões nas atualizações.

Conceitos do Gerenciador de Implantação do Azure

O ADM apresenta dois novos conceitos à história de implantação do ARM (Azure Resource Manager): topologias de serviço e distribuições.

Conforme mostrado na Figura 1, uma topologia de serviço descreve a hierarquia dos recursos que você implanta no Azure, organizando-os em grupos. Os arquivos de modelo e parâmetro formam a base de qualquer implantação do ARM. Eles representam as unidades de serviço ou partes implantáveis individualmente de um determinado serviço, como o front-end de um serviço. Um grupo de Unidades de Serviço compreende um Serviço, já uma Topologia de Serviço nada mais é do que um grupo de Serviços.

Estrutura de topologias de serviço
Figura 1 Estrutura de topologias de serviço

O ADM facilita a definição desses tipos de topologias complexas, mesmo quando os Serviços abrangem várias regiões, assinaturas e grupos de recursos. Uma vez definidos, eles podem ser implantados e, em seguida, atualizados inúmeras vezes por meio do uso de Distribuições, e isso define a estrutura e o tempo para implantar as unidades de serviço de maneira segura e em etapas.

Conforme representado na Figura 2, uma distribuição é composta por Grupos de etapas. Os Grupos de etapas definem a ordem de implantação e dão suporte a operações sequenciais e paralelas. Por exemplo, posso executar a Etapa 2 após a Etapa 1 (como mostrado), ou fazer com que as Etapas 1 e 2 sejam implantadas em paralelo antes de implantar a Etapa 3.

Estrutura de distribuição
Figura 2 Estrutura de distribuição

Como o nome indica, os Grupos de etapas são divididos em etapas, que abordam as etapas a serem executadas antes e após uma implantação. Exemplos dessas etapas incluem:

  • Aguardar: Pausa a implantação para uma quantidade específica de tempo antes de continuar, permitindo que os testes manuais, bem como o tempo para os recursos façam o bake.
  • Verificações de integridade: O ADM integra-se a provedores de monitoramento de serviços existentes para verificar a integridade dos serviços enquanto as implantações estão em andamento. Se a integridade de um serviço diminuir, a implantação será interrompida.

Mais etapas, incluindo aquelas que permitem a execução de código personalizado, estão chegando em breve. Para entender melhor esses conceitos, trabalharemos com um exemplo.

Implantar a Primeira Distribuição

Antes de começarmos, é uma boa ideia familiarizar-se com alguns dos recursos e ferramentas com os quais você trabalhará. Aqui estão alguns links para ajudar a configurar seu ambiente e fornecer o embasamento necessário para trabalhar com modelos ARM e seguir o exemplo:

  • Familiarizar-se com os modelos do Azure Resource Manager (bit.ly/2Ib6WHM)
  • Extensão do Visual Studio Code e do Resource Manager (bit.ly/2MH29lF)
  • Iniciar um terminal do PowerShell no Azure Cloud Shell (bit.ly/2yESmTP)
  • Baixar e instalar o Gerenciador de Armazenamento do Microsoft Azure (bit.ly/2IaaxWA)
  • Baixar e descompactar os arquivos de exemplo (bit.ly/2F6CInD)

Depois de baixar e instalar os arquivos de exemplo, você pode encontrar a pasta ArtifactStore, que contém uma pasta de modelos e uma pasta de binários.

A pasta de modelos contém os artefatos de modelo do ARM. 1.0.0.0 e 1.0.0.1 representam as duas versões dos artefatos binários. Em cada versão, há uma pasta para cada serviço (Serviço Leste dos EUA e Serviço Oeste dos EUA). Cada serviço possui um par de arquivos de modelo e parâmetro para criar uma conta de armazenamento e outro par para criar um aplicativo Web. O modelo de aplicativo Web chama um pacote compactado, que contém os arquivos de aplicativo Web. O arquivo compactado é um artefato binário armazenado na pasta binários.

A pasta binários contém os artefatos binários com 1.0.0.0 e 1.0.0.1, representando novamente as duas versões dos artefatos binários. Em cada versão, há um arquivo .zip para criar o aplicativo Web na região Oeste dos EUA e outro arquivo .zip para criar a aplicação Web na região Leste dos EUA.

Mesmo que os artefatos de modelo e os artefatos binários tenham duas versões, apenas os artefatos binários são diferentes entre as duas versões. Na prática, os artefatos binários são atualizados com mais frequência do que os artefatos de modelo. Para obter uma descrição completa do conteúdo desses arquivos de artefato, confira o tutorial do ADM em aka.ms/admtutorial.

Os artefatos de modelo são usados pelo modelo de topologia de serviço e os artefatos binários são usados pelo modelo de distribuição. O modelo de topologia e o modelo de distribuição definem um recurso do Azure de origem de artefato, que é um recurso usado para apontar o Gerenciador de Recursos para o modelo e artefatos binários usados na implantação. Para simplificar este exemplo, uma conta de armazenamento é usada para armazenar os artefatos de modelo e os artefatos binários. As duas fontes de artefato apontam para a mesma conta de armazenamento, então vamos configurar isso.

Primeiramente, crie uma conta de armazenamento do Azure. Para isso, você pode seguir as instruções publicadas no artigo “Quickstart: Upload, Download, and List Blobs Using the Azure Portal” disponível em bit.ly/2F6NMRt.

Em seguida, crie um contêiner de blob na conta de armazenamento e copie as duas pastas (binários e modelos) e o conteúdo das duas pastas no contêiner de blob. Depois, obtenha o local do SAS do contêiner usando as seguintes etapas. No Gerenciador de Armazenamento do Azure, navegue até o contêiner de blob e clique com o botão direito do mouse no contêiner de blob no painel esquerdo e selecione Obter assinatura de acesso compartilhado. Configure Hora de início e Hora de expiração e, em seguida, selecione Criar.

Faça uma cópia da URL. Essa URL é o URI do SAS necessário para preencher um campo nos dois arquivos de parâmetros, o arquivo de parâmetros de topologia e o arquivo de parâmetros de distribuição, durante uma etapa posterior.

Posteriormente neste exemplo, você implantará uma distribuição. É necessária uma identidade gerenciada atribuída pelo usuário para executar as ações de implantação. Essa identidade deve ter acesso concedido à assinatura do Azure na qual você está implantando o serviço e deve ter permissão suficiente para concluir a implantação do artefato. Vamos criar uma identidade gerenciada atribuída pelo usuário e configurar o controle de acesso para sua assinatura.

Entre no portal do Azure (portal.azure.com) e crie uma identidade gerenciada atribuída pelo usuário. Para mais informações, confira bit.ly/2F7lqqx. No portal, selecione Assinaturas no menu esquerdo e selecione sua assinatura. Selecione Controle de acesso (IAM) e, em seguida, selecione Adicionar atribuição de função. Você deve ver a caixa de diálogo da Figura 3.

Criação de uma identidade gerenciada atribuída ao usuário
Figura 3 Criação de uma identidade gerenciada atribuída ao usuário

Vamos inserir valores nos campos exibidos. O menu suspenso Função fornece permissão para concluir a implantação do artefato (os aplicativos Web e as contas de armazenamento). Neste exemplo, selecione Colaborador na lista. Na prática, você deseja restringir as permissões ao mínimo.

Em seguida, clique no menu suspenso Acesso atribuído e selecione Identidade gerenciada atribuída ao usuário. Em seguida, selecione a identidade gerenciada atribuída pelo usuário que você criou anteriormente no exemplo. Por fim, selecione Salvar e anote o nome da sua identidade gerenciada, pois você o usará posteriormente.

Preparar os Modelos

Agora que configuramos os recursos necessários da conta do Azure, é hora de fazer algumas pequenas edições nos arquivos fornecidos para que eles possam segmentar corretamente seu local de assinatura e armazenamento. Comece abrindo \ADMTemplates\CreateADMServiceTopology.Parameters no Visual Studio Code ou qualquer editor de texto. A Figura 4 mostra os parâmetros na Topologia de Serviço. Vamos examinar cada parâmetro agora.

Parâmetros de topologia de serviço
Figura 4 Parâmetros de topologia de serviço

namePrefix: Esse parâmetro é usado para criar os nomes para os recursos do Deployment Manager. Por exemplo, usando o prefixo “jdoe”, o nome da topologia do serviço fica jdoeServiceTopology. Os nomes dos recursos são definidos na seção de variáveis deste modelo. Para esse, use uma cadeia de caracteres com quatro a cinco caracteres. Esse prefixo é usado para criar nomes de recursos exclusivos do Azure.

azureResourceLocation: Para simplificar o exemplo, todos os recursos compartilharão esse local, a menos que especificado de outra forma. Não toque nesse parâmetro por enquanto.

artifactSourceSASLocation: Esse campo deve ser preenchido com o URI do SAS salvo no contêiner de blob em que o modelo da unidade de serviço e os arquivos de parâmetros são armazenados para implementação.

templateArtifactRoot: Esse parâmetro fornece o caminho de deslocamento do contêiner Blob onde os modelos e parâmetros são armazenados. O valor padrão é templates/1.0.0.0. Não altere esse valor, a menos que queira alterar a estrutura da pasta usada ao carregar os arquivos no Armazenamento do Microsoft Azure. Caminhos relativos são usados neste exemplo, e o caminho completo é construído automaticamente pelo ADM. Se, na prática, você deseja usar caminhos absolutos, o ADM também tem suporte para isso.

targetSubscriptionID: É simplesmente o ID da assinatura no qual os recursos do Deployment Manager serão implantados e cobrados. Use sua ID de assinatura nesse exemplo.

Agora, abra \ADMTemplates\CreateADMRollout.Parameters no Visual Studio Code ou em qualquer editor de texto. Digite os valores dos parâmetros conforme descrito abaixo. É importante que esses campos tenham os mesmos valores nos dois arquivos. Há um novo campo neste arquivo que também deve ser preenchido chamado managedIdentityID. Digite a identidade gerenciada atribuída pelo usuário, substituindo a parte <ManagedIdentity> pelo Nome salvo da sua identidade gerenciada.

Primeira Implantação

É hora de implantar os dois sites! Use o terminal do Azure CloudShell PowerShell para executar os scripts a seguir. Vamos começar executando um script para implantar a topologia de serviço, da seguinte maneira:

$resourceGroupName = “<Enter a Resource Group Name>”
$location = “Central US” 
$filePath = “<Enter the File Path to the Downloaded Example Files>”
# Create a resource group
New-AzResourceGroup -Name $resourceGroupName -Location “$location”
# Create the service topology
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateFile “$filePath\ADMTemplates\CreateADMServiceTopology.json” `
  -TemplateParameterFile “$filePath\ADMTemplates\CreateADMServiceTopology.Parameters.json”

Observe que New-AzResourceGroupDeployment é uma chamada assíncrona. A mensagem de sucesso significa apenas que a implantação foi iniciada com êxito. Daqui a pouco, falarei sobre como verificar o status da implantação. Por enquanto, verifique se a topologia do serviço e os recursos subjacentes foram criados com êxito usando o portal do Azure, conforme mostrado na Figura 5.

Exibição do recursos ocultos de implantação
Figura 5 Exibição do recursos ocultos de implantação

Agora, vamos implantar o modelo de distribuição, da seguinte maneira:

# Create the rollout
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateFile “$filePath\ADMTemplates\CreateADMRollout.json” `
  -TemplateParameterFile “$filePath\ADMTemplates\CreateADMRollout.Parameters.json”

Podemos verificar o progresso da implementação usando o seguinte script:

# Get the rollout status
$rolloutname = “<Enter the Rollout Name>”
# “adm0925Rollout” is the rollout name used in this example
Get-AzDeploymentManagerRollout `
  -ResourceGroupName $resourceGroupName `
  -Name $rolloutName `
  -Verbose

Depois que a distribuição for implantada com sucesso, você verá mais dois grupos de recursos criados, um para cada serviço. Abra o portal do Azure e navegue até os aplicativos Web recém-criados nos novos grupos de recursos criados pela implantação de distribuição. Abra o aplicativo Web em um navegador da Web e o HTML do site verificará o local e a versão.

Para tentar implantar uma nova versão (1.0.0.1) do aplicativo Web, abra CreateADMRollout.Parameters.json e atualize binaryArtifactRoot para binários/1.0.0.1. Reimplemente a distribuição conforme as instruções anteriores. Você não precisa implantar a topologia de serviço. Verifique a atualização navegando até o site e anotando o número da versão exibida pela página.

Parabéns, você acabou de implantar dois serviços em várias regiões usando uma distribuição em fases e os atualizou para uma nova versão! Em seguida, veremos a integração das verificações de integridade nessas etapas para que, se uma atualização de serviço não estiver íntegra, a implantação será interrompida automaticamente antes de afetar as regiões mais importantes.

Implantar uma Distribuição de Integridade Integrada

Os provedores de monitoramento de integridade oferecem vários mecanismos para monitorar e alertar você sobre problemas de integridade. O Azure Monitor (azure.microsoft.com/services/monitor) é um exemplo de um desses serviços, que dispara alertas quando determinados limites são excedidos. Alguns limites indicam um problema com a integridade do serviço quando excedido. Por exemplo, se você estiver implantando uma nova atualização no seu serviço e o pico de utilização da memória e da CPU passar dos níveis esperados, o Azure Monitor e os provedores de monitoramento de integridade notificarão você sobre os problemas para que você possa tomar as medidas corretivas.

Esses provedores de serviços de integridade geralmente oferecem APIs REST para que o status dos monitores do seu serviço possa ser examinado programaticamente. As APIs REST retornam com um sinal simples íntegro/não íntegro (geralmente determinado pelo código de resposta HTTP) ou com informações detalhadas sobre os sinais recebidos.

A nova etapa healthCheck no Azure Deployment Manager permite declarar códigos HTTP que indicam um serviço íntegro ou, para resultados REST mais complexos, você pode especificar expressões regulares que indicam uma resposta íntegra, caso correspondam. Para tornar isso ainda mais fácil de usar, a equipe do Azure Deployment Manager está trabalhando em estreita colaboração com os principais provedores de monitoramento de integridade para pré-criar esses códigos HTTP e expressões regulares, para que você possa simplesmente copiar e colar esta parte da etapa healthCheck, se estiver usando um desses provedores.

O processo de configuração com as verificações de integridade do Azure Deployment Manager é direto. Primeiro, você cria seus monitores de integridade por meio de um provedor de serviços de integridade de sua escolha. Em seguida, você cria uma ou mais etapas healthCheck como parte da distribuição do Azure Deployment Manager e preenche essas etapas com o seguinte:

  • URI para API REST para monitores de integridade, conforme definido pelo seu provedor de serviços de integridade.
  • Informações de autenticação (somente a autenticação de estilo da chave de API é compatível atualmente).
  • Códigos de status HTTP ou expressões regulares que definem uma resposta íntegra.

Por fim, você invoca as etapas healthCheck no momento apropriado na distribuição do Azure Deployment Manager, e o ADM cuida do restante.

Fases de uma Verificação de Integridade

Nesse momento, o ADM sabe como consultar a integridade do seu serviço e em que fases da distribuição o faz. No entanto, também permite uma configuração profunda do tempo dessas verificações. Uma etapa healthCheck é executada em um processo trifásico simples com durações configuráveis, rico o suficiente para suportar as necessidades de monitoramento de integridade dos maiores serviços da Microsoft que compõem o próprio Azure.

Após a conclusão de uma operação de implantação, pode não fazer sentido verificar a integridade do serviço imediatamente, pois a atualização precisa atingir um estado estável. Leva tempo para que os serviços comecem a emitir sinais de integridade para serem agregados pelo provedor de monitoramento de integridade em algo útil. Da mesma forma, as VMs podem iniciar pela primeira vez, reiniciar ou reconfigurar com base em novos dados. O resultado A integridade do serviço pode oscilar entre estados íntegros ou não íntegros Durante a fase de espera, a integridade do serviço não é monitorada, para que os recursos implantados tenham tempo de se estabelecerem antes de iniciar o processo de verificação de integridade.

Muitas vezes, é impossível saber quanto tempo leva para os recursos de inicialização se tornarem estáveis; portanto, a fase Elastic fornece um período flexível para que eles se estabeleçam em um estado estável e íntegro. Quando a fase Elastic começa, o Azure Deployment Manager pesquisa periodicamente o ponto de extremidade REST fornecido para verificar a integridade do serviço. O intervalo é definido como três minutos na visualização do Azure Deployment Manager, mas será configurável no futuro. Se o monitor de integridade voltar com sinais indicando que um serviço não está íntegro, esses sinais serão ignorados, a fase Elástica será mantida e a pesquisa continuará. Depois que o monitor de integridade retornar com sinais indicando que um serviço está íntegro, a fase Elastic termina e a fase HealthyState começa. Portanto, a duração especificada para a fase Elastic é o tempo máximo que pode ser gasto pesquisando a integridade do serviço antes que uma resposta saudável seja considerada obrigatória.

Durante a fase HealthyState, a integridade do serviço é pesquisada continuamente no mesmo intervalo da fase Elástica. Espera-se que o serviço mantenha sinais saudáveis do provedor de monitoramento de integridade por toda a duração especificada. Se a qualquer momento uma resposta não íntegra for detectada, o ADM interromperá toda a distribuição e retornará a resposta REST carregando os sinais de serviço não íntegros. Depois que a duração da fase HealthyState termina, o healthCheck é concluído e a implantação continua na próxima etapa.

Introdução

Na produção, você normalmente usa um ou mais provedores de monitoramento. Para facilitar a integração de integridade, a Microsoft tem trabalhado com as principais empresas de monitoramento de integridade de serviço para fornecer uma solução simples de copiar/colar para integrar as verificações de integridade às implantações. Você pode visualizar uma lista desses provedores de monitoramento de integridade em bit.ly/2XOpR0G.

Neste exemplo, você criará uma Função do Azure (bit.ly/2wPgq5d) para simular um serviço de monitoramento de integridade. Essa função simplesmente pega um código de status e retorna o mesmo código.

Para implantar a Função do Azure, use o mesmo terminal do Azure CloudShell PowerShell usado nas etapas anteriores e execute o script a seguir. Observe que projectName deve ter menos de 12 caracteres, com apenas letras minúsculas e números. Ele será reutilizado em todo este exemplo, portanto, salve-o. Eis aqui o script:

$projectName = <Enter a project name that is used to generate Azure resource names>
$location = <Enter the location (i.e. centralus)>
$resourceGroupName = “${projectName}rg”
New-AzResourceGroup -Name $resourceGroupName -Location $location
New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/deploy_hc_azure_function.json” -projectName $projectName

Para verificar e testar a função do Azure, acesse o portal do Azure e abra o grupo de recursos. O nome padrão é o nome do projeto com "rg" anexado. Selecione o serviço de aplicativo no grupo de recursos. O nome padrão do serviço de aplicativo é o nome do projeto com "webapp" anexado. Expanda Funções e selecione HttpTrigger1.

Conforme mostrado na Figura 6, selecione </> Obter URL da função e clique em Copiar para copiar a URL para a área de transferência. A URL deve ser semelhante a:

 

https://myhc0417webapp.azurewebsites.net/api/healthStatus/{healthStatus}?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

Trabalhando com o Azure Functions
Figura 6 Trabalhando com o Azure Functions

Agora substitua {healthStatus} na URL por um código de status. Neste exemplo, use não íntegro para testar o cenário não íntegro e use íntegro ou aviso para testar o cenário íntegro. Crie duas URLs: uma com o status não íntegro e a outra com o status íntegro. Por exemplo:

https://myhc0417webapp.azurewebsites.net/api/healthStatus/unhealthy?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

https://myhc0417webapp.azurewebsites.net/api/healthStatus/healthy?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

Salve os dois, pois você precisará deles para concluir este exemplo. Você pode testar as URLs simplesmente abrindo-as em um navegador. Você deve ver uma página simples com a mensagem "Status:", seguida do valor que você coloca na URL.

Executar a Segunda Implantação

Para acelerar o processo, os scripts do PowerShell a seguir farão referência a uma topologia de serviço atualizada e a um novo arquivo de distribuição que contém uma etapa de verificação de integridade. Esta etapa ocorre após a implantação no Oeste dos EUA, mas antes da implantação no Leste dos EUA. Portanto, se a verificação de integridade falhar, o serviço do Leste dos EUA nunca será implantado, impedindo que os usuários daquela região experimentem a falha. Esta verificação de integridade está configurada para procurar "Status: íntegro" como uma resposta de integridade da Função do Azure e qualquer outra coisa como uma resposta não íntegra.

Você passará as URLs para sua Função do Azure como parâmetro ao iniciar o script. Se você deseja fazer o download desses arquivos para inspecioná-los, verifique o modelo de topologia de serviço (bit.ly/2KdzW45) e o modelo de Distribuição (bit.ly/31wbP6e).

Primeiro, implante a Topologia de Serviço atualizada. Como o script é bastante longo, copie-o daqui: aka.ms/admhealthdeploy. Eis aqui o script:

$projectName = <Enter the same project name used earlier in this example>
$location = <Enter the location (i.e. centralus)>
$resourceGroupName = “${projectName}rg”
$artifactLocation = “https://aka.ms/admtutorialartifactstore” | ConvertTo-SecureString -AsPlainText -Force
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/ADMTemplatesHC/CreateADMServiceTopology.json” `
  -namePrefix $projectName -azureResourceLocation $location `
  -artifactSourceSASLocation $artifactLocation

Em seguida, verifique se a topologia do serviço e os recursos subjacentes foram criados com êxito usando o portal do Azure, conforme mostrado anteriormente na Figura 5.

Agora, usaremos a URL da função do Azure não íntegro criado anteriormente, juntamente com o nome da identidade gerenciada atribuída ao usuário, para implantar a distribuição. Como antes, sinta-se à vontade para copiar esse script de aka.ms/admhealthdeploy. A Figura 7 mostra o script.

Figura 7 Implantação de uma distribuição integrada de integridade

$projectName = <Enter the same project name used earlier in this example>
$location = <Enter the location (i.e. centralus)>
$managedIdentityID = <Enter the user-assigned managed identity Name>
$healthCheckUrl = <Enter the health check Azure function URL>
$healthCheckAuthAPIKey = $healthCheckUrl.Substring($healthCheckUrl.IndexOf(“?code=”)+6, $healthCheckUrl.Length-$healthCheckUrl.IndexOf(“?code=”)-6)
$healthCheckUrl = $healthCheckUrl.Substring(0, $healthCheckUrl.IndexOf(“?”))
$resourceGroupName = “${projectName}rg”
$artifactLocation = “https://aka.ms/admtutorialartifactstore” | ConvertTo-SecureString -AsPlainText -Force
# Create the rollout
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/ADMTemplatesHC/CreateADMRollout.json” `
  -namePrefix $projectName `
  -azureResourceLocation $location `
  -artifactSourceSASLocation $artifactLocation `
  -managedIdentityID $managedIdentityID `
  -healthCheckUrl $healthCheckUrl `
  -healthCheckAuthAPIKey $healthCheckAuthAPIKey
As with the previous rollout, you can check the progress using this script:
$projectName = <Enter the same project name used earlier in this example>
$resourceGroupName = “${projectName}rg”
$rolloutName = “${projectName}Rollout”
# Get the rollout status
Get-AzDeploymentManagerRollout `
  -ResourceGroupName $resourceGroupName `
  -Name $rolloutName `
  -Verbose

Após um tempo suficiente, a verificação do status da distribuição mostrará uma falha. Isso é esperado porque a Função do Azure não íntegra foi usada. Você também verá que um grupo de recursos foi criado para o serviço no Oeste dos EUA, mas não verá o grupo de recursos no Leste dos EUA porque a distribuição foi interrompida automaticamente antes de continuar em outras regiões. Repita esta implantação com a URL de status íntegro e, após a conclusão, você verá que os dois serviços foram implantados com sucesso!

Essa é a conclusão

O ADM permite que você execute implantações complexas, com várias regiões e com várias assinaturas que se integram às suas soluções de monitoramento de integridade de serviço existentes, usando os modelos ARM internos do Azure. Nenhuma ferramenta adicional é necessária e é totalmente gratuita. Comece revisando a documentação em aka.ms/admdocs ou explore o tutorial completo em aka.ms/admtutorial.

David Tepper é o principal gerente de programa da Microsoft na equipe do OneDeploy no Azure. Ele é especialista em aprendizado de máquina e trabalhou nas tecnologias de shell e de implantação do Windows.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Cristina del Amo Casado, Jonathan Gao, Devesh Guha Oleti Muni, Sriram Ramaswamy
Cristina del Amo Casado é gerente principal do programa de Computação do Azure na Microsoft.
Jonathan Gao (jgao@microsoft.com) é escritor técnico sênior do Azure Resource Manager na Microsoft.
Devesh Guha Oleti Muni (Devesh.Oleti@microsoft.com) é engenheiro de software sênior da equipe do Azure na Microsoft.

Discuta esse artigo no fórum do MSDN Magazine