Partilhar via

Desenvolva modelos ARM para consistência na nuvem

  • Artigo

Importante

Usar esse recurso do Azure do PowerShell requer o AzureRM módulo instalado. Este é um módulo mais antigo disponível apenas para o Windows PowerShell 5.1 que não recebe mais novos recursos. Os Az módulos e AzureRM não são compatíveis quando instalados para as mesmas versões do PowerShell. Se você precisar de ambas as versões:

  1. Desinstale o módulo Az de uma sessão do PowerShell 5.1.
  2. Instale o módulo AzureRM a partir de uma sessão do PowerShell 5.1.
  3. Baixe e instale o PowerShell Core 6.x ou posterior.
  4. Instale o módulo Az em uma sessão do PowerShell Core.

Um dos principais benefícios do Azure é a consistência. Os investimentos de desenvolvimento para um local são reutilizáveis em outro. Um modelo do Azure Resource Manager (modelo ARM) torna suas implantações consistentes e repetíveis entre ambientes, incluindo o Azure global, as nuvens soberanas do Azure e o Azure Stack. Para reutilizar modelos em nuvens, no entanto, você precisa considerar dependências específicas da nuvem, como explica este guia.

A Microsoft oferece serviços de nuvem inteligentes e prontos para empresas em muitos locais, incluindo:

  • A plataforma global Azure suportada por uma rede crescente de datacenters geridos pela Microsoft em regiões de todo o mundo.
  • Nuvens soberanas isoladas como Azure Germany, Azure Government e Microsoft Azure operadas pela 21Vianet. As nuvens soberanas fornecem uma plataforma consistente com a maioria dos mesmos excelentes recursos aos quais os clientes globais do Azure têm acesso.
  • Azure Stack, uma plataforma de nuvem híbrida que permite fornecer serviços do Azure a partir do datacenter da sua organização. As empresas podem configurar o Azure Stack em seus próprios datacenters ou consumir os Serviços do Azure de provedores de serviços, executando o Azure Stack em suas instalações (às vezes conhecidas como regiões hospedadas).

No núcleo de todas essas nuvens, o Azure Resource Manager fornece uma API que permite que uma ampla variedade de interfaces de usuário se comunique com a plataforma Azure. Essa API oferece recursos poderosos de infraestrutura como código. Qualquer tipo de recurso disponível na plataforma de nuvem do Azure pode ser implantado e configurado com o Azure Resource Manager. Com um único modelo, você pode implantar e configurar seu aplicativo completo para um estado final operacional.

Diagrama de vários ambientes do Azure, incluindo Azure global, nuvens soberanas e Azure Stack.

A consistência do Azure global, das nuvens soberanas, das nuvens hospedadas e de uma nuvem em seu datacenter ajuda você a se beneficiar do Gerenciador de Recursos do Azure. Você pode reutilizar seus investimentos em desenvolvimento nessas nuvens ao configurar a implantação e a configuração de recursos baseados em modelos.

No entanto, embora as nuvens globais, soberanas, hospedadas e híbridas forneçam serviços consistentes, nem todas as nuvens são idênticas. Como resultado, você pode criar um modelo com dependências em recursos disponíveis apenas em uma nuvem específica.

O restante deste guia descreve as áreas a serem consideradas ao planejar o desenvolvimento de modelos ARM novos ou atualizados para o Azure Stack. Em geral, a sua lista de verificação deve incluir os seguintes itens:

  • Verifique se as funções, pontos de extremidade, serviços e outros recursos em seu modelo estão disponíveis nos locais de implantação de destino.
  • Armazene modelos aninhados e artefatos de configuração em locais acessíveis, garantindo o acesso entre nuvens.
  • Use referências dinâmicas em vez de links e elementos codificados.
  • Certifique-se de que os parâmetros de modelo usados funcionem nas nuvens de destino.
  • Verifique se as propriedades específicas do recurso estão disponíveis nas nuvens de destino.

Para obter uma introdução aos modelos ARM, consulte Implantação de modelos.

Garantir que as funções do modelo funcionem

A sintaxe básica de um modelo ARM é JSON. Os modelos usam um superconjunto de JSON, estendendo a sintaxe com expressões e funções. O processador de linguagem de modelo é atualizado com freqüência para suportar funções de modelo adicionais. Para obter uma explicação detalhada das funções de modelo disponíveis, consulte Funções de modelo ARM.

As novas funções de modelo introduzidas no Azure Resource Manager não estão imediatamente disponíveis nas nuvens soberanas ou no Azure Stack. Para implantar um modelo com êxito, todas as funções referenciadas no modelo devem estar disponíveis na nuvem de destino.

Os recursos do Azure Resource Manager sempre serão apresentados ao Azure global primeiro. Você pode usar o seguinte script do PowerShell para verificar se as funções de modelo recém-introduzidas também estão disponíveis no Azure Stack:

  1. Faça um clone do repositório GitHub: https://github.com/marcvaneijk/arm-template-functions.

  2. Depois de ter um clone local do repositório, conecte-se ao Azure Resource Manager do destino com o PowerShell.

  3. Importe o módulo psm1 e execute o cmdlet Test-AzureRmTemplateFunctions:

    # Import the module
Import-module <path to local clone>\AzTemplateFunctions.psm1

# Execute the Test-AzureRmTemplateFunctions cmdlet
Test-AzureRmTemplateFunctions -path <path to local clone>

O script implanta vários modelos minimizados, cada um contendo apenas funções de modelo exclusivas. A saída do script relata as funções de modelo suportadas e indisponíveis.

Trabalhando com artefatos vinculados

Um modelo pode conter referências a artefatos vinculados e conter um recurso de implantação vinculado a outro modelo. Os modelos vinculados (também conhecidos como modelo aninhado) são recuperados pelo Gerenciador de Recursos em tempo de execução. Um modelo também pode conter referências a artefatos para extensões de máquina virtual (VM). Esses artefatos são recuperados pela extensão VM em execução dentro da VM para configuração da extensão VM durante a implantação do modelo.

As seções a seguir descrevem considerações para a consistência da nuvem ao desenvolver modelos que incluem artefatos externos ao modelo de implantação principal.

Usar modelos aninhados entre regiões

Os modelos podem ser decompostos em modelos pequenos e reutilizáveis, cada um com uma finalidade específica e podem ser reutilizados em cenários de implantação. Para executar uma implantação, especifique um único modelo conhecido como modelo principal ou mestre. Ele especifica os recursos a serem implantados, como redes virtuais, VMs e aplicativos Web. O modelo principal também pode conter um link para outro modelo, o que significa que você pode aninhar modelos. Da mesma forma, um modelo aninhado pode conter links para outros modelos. Você pode aninhar até cinco níveis de profundidade.

O código a seguir mostra como o parâmetro templateLink se refere a um modelo aninhado:

"resources": [
  {
     "type": "Microsoft.Resources/deployments",
     "apiVersion": "2020-10-01",
     "name": "linkedTemplate",
     "properties": {
       "mode": "incremental",
       "templateLink": {
          "uri":"https://mystorageaccount.blob.core.windows.net/AzureTemplates/vNet.json",
          "contentVersion":"1.0.0.0"
       }
     }
  }
]

O Azure Resource Manager avalia o modelo principal em tempo de execução e recupera e avalia cada modelo aninhado. Depois que todos os modelos aninhados são recuperados, o modelo é nivelado e o processamento adicional é iniciado.

Torne os modelos vinculados acessíveis nas nuvens

Considere onde e como armazenar os modelos vinculados que você usa. No tempo de execução, o Azure Resource Manager busca — e, portanto, requer acesso direto a — todos os modelos vinculados. Uma prática comum é usar o GitHub para armazenar os modelos aninhados. Um repositório GitHub pode conter arquivos acessíveis publicamente por meio de uma URL. Embora essa técnica funcione bem para a nuvem pública e as nuvens soberanas, um ambiente do Azure Stack pode estar localizado em uma rede corporativa ou em um local remoto desconectado, sem qualquer acesso de saída à Internet. Nesses casos, o Azure Resource Manager não conseguiria recuperar os modelos aninhados.

Uma prática melhor para implantações entre nuvens é armazenar seus modelos vinculados em um local acessível para a nuvem de destino. Idealmente, todos os artefatos de implantação são mantidos e implantados a partir de um pipeline de integração contínua/desenvolvimento contínuo (CI/CD). Como alternativa, você pode armazenar modelos aninhados em um contêiner de armazenamento de blob, do qual o Azure Resource Manager pode recuperá-los.

Como o armazenamento de blob em cada nuvem usa um FQDN (nome de domínio totalmente qualificado) de ponto de extremidade diferente, configure o modelo com o local dos modelos vinculados com dois parâmetros. Os parâmetros podem aceitar a entrada do usuário no momento da implantação. Os modelos geralmente são criados e compartilhados por várias pessoas, portanto, uma prática recomendada é usar um nome padrão para esses parâmetros. As convenções de nomenclatura ajudam a tornar os modelos mais reutilizáveis entre regiões, nuvens e autores.

No código a seguir, _artifactsLocation é usado para apontar para um único local, contendo todos os artefatos relacionados à implantação. Observe que um valor padrão é fornecido. No momento da implantação, se nenhum valor de entrada for especificado para _artifactsLocation, o valor padrão será usado. O _artifactsLocationSasToken é usado como entrada para o sasToken. O valor padrão deve ser uma cadeia de caracteres vazia para cenários em que o _artifactsLocation não está protegido — por exemplo, um repositório GitHub público.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.compute/vm-custom-script-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

Em todo o modelo, os links são gerados combinando o URI base (do _artifactsLocation parâmetro) com um caminho relativo ao artefato e o _artifactsLocationSasToken. O código a seguir mostra como especificar o link para o modelo aninhado usando a função de modelo uri:

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2020-10-01",
    "name": "shared",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "[uri(parameters('_artifactsLocation'), concat('nested/vnet.json', parameters('_artifactsLocationSasToken')))]",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

Usando essa abordagem, o valor padrão para o _artifactsLocation parâmetro é usado. Se os modelos vinculados precisarem ser recuperados de um local diferente, a entrada de parâmetro poderá ser usada no momento da implantação para substituir o valor padrão — nenhuma alteração no modelo em si é necessária.

Use _artifactsLocation em vez de links de codificação

Além de ser usado para modelos aninhados, a URL no _artifactsLocation parâmetro é usada como base para todos os artefatos relacionados de um modelo de implantação. Algumas extensões de VM incluem um link para um script armazenado fora do modelo. Para essas extensões, você não deve codificar os links. Por exemplo, as extensões Script Personalizado e DSC do PowerShell podem ser vinculadas a um script externo no GitHub, conforme mostrado:

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/scripts/configure-music-app.ps1"
    ]
  }
}

A codificação dos links para o script potencialmente impede que o modelo seja implantado com êxito em outro local. Durante a configuração do recurso VM, o agente VM em execução dentro da VM inicia um download de todos os scripts vinculados na extensão VM e, em seguida, armazena os scripts no disco local da VM. Essa abordagem funciona como os links de modelo aninhados explicados anteriormente na seção "Usar modelos aninhados entre regiões".

O Resource Manager recupera modelos aninhados em tempo de execução. Para extensões de VM, a recuperação de quaisquer artefatos externos é executada pelo agente de VM. Além do diferente iniciador da recuperação do artefato, a solução na definição do modelo é a mesma. Use o parâmetro _artifactsLocation com um valor padrão do caminho base onde todos os artefatos são armazenados (incluindo os scripts de extensão da VM) e o _artifactsLocationSasToken parâmetro para a entrada para o sasToken.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

Para construir o URI absoluto de um artefato, o método preferido é usar a função de modelo de uri, em vez da função de modelo concat. Ao substituir links codificados para os scripts na extensão VM pela função de modelo uri, essa funcionalidade no modelo é configurada para consistência na nuvem.

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "[uri(parameters('_artifactsLocation'), concat('scripts/configure-music-app.ps1', parameters('_artifactsLocationSasToken')))]"
    ]
  }
}

Com essa abordagem, todos os artefatos de implantação, incluindo scripts de configuração, podem ser armazenados no mesmo local com o próprio modelo. Para alterar o local de todos os links, você só precisa especificar uma URL base diferente para os parâmetros artifactsLocation.

Fator em diferentes capacidades regionais

Com o desenvolvimento ágil e o fluxo contínuo de atualizações e novos serviços introduzidos no Azure, as regiões podem diferir na disponibilidade de serviços ou atualizações. Após rigorosos testes internos, novos serviços ou atualizações de serviços existentes geralmente são apresentados a um pequeno público de clientes que participam de um programa de validação. Após a validação bem-sucedida do cliente, os serviços ou atualizações são disponibilizados em um subconjunto de regiões do Azure e, em seguida, apresentados a mais regiões, implantados nas nuvens soberanas e potencialmente disponibilizados também para clientes do Azure Stack.

Sabendo que as regiões e nuvens do Azure podem diferir em seus serviços disponíveis, você pode tomar algumas decisões proativas sobre seus modelos. Um bom lugar para começar é examinando os provedores de recursos disponíveis para uma nuvem. Um provedor de recursos informa o conjunto de recursos e operações disponíveis para um serviço do Azure.

Um modelo implanta e configura recursos. Um tipo de recurso é fornecido por um provedor de recursos. Por exemplo, o provedor de recursos de computação (Microsoft.Compute) fornece vários tipos de recursos, como virtualMachines e availabilitySets. Cada provedor de recursos fornece uma API para o Azure Resource Manager definida por um contrato comum, permitindo uma experiência de criação consistente e unificada em todos os provedores de recursos. No entanto, um provedor de recursos que está disponível no Azure global pode não estar disponível em uma nuvem soberana ou em uma região do Azure Stack.

Diagrama ilustrando a relação entre provedores de recursos, tipos de recursos e versões de API.

Para verificar os provedores de recursos disponíveis em uma determinada nuvem, execute o seguinte script na CLI do Azure:

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

Você também pode usar o seguinte cmdlet do PowerShell para ver os provedores de recursos disponíveis:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

Verificar a versão de todos os tipos de recursos

Um conjunto de propriedades é comum para todos os tipos de recursos, mas cada recurso também tem suas próprias propriedades específicas. Novos recursos e propriedades relacionadas são adicionados aos tipos de recursos existentes às vezes por meio de uma nova versão da API. Um recurso em um modelo tem sua própria propriedade de versão da API - apiVersion. Esse controle de versão garante que uma configuração de recurso existente em um modelo não seja afetada por alterações na plataforma.

As novas versões de API introduzidas em tipos de recursos existentes no Azure global podem não estar imediatamente disponíveis em todas as regiões, nuvens soberanas ou Azure Stack. Para exibir uma lista dos provedores de recursos, tipos de recursos e versões de API disponíveis para uma nuvem, você pode usar o Gerenciador de Recursos no portal do Azure. Procure o Explorador de Recursos no menu Todos os Serviços. Expanda o nó Provedores no Gerenciador de Recursos para retornar todos os provedores de recursos disponíveis, seus tipos de recursos e versões de API nessa nuvem.

Para listar a versão da API disponível para todos os tipos de recursos em uma determinada nuvem na CLI do Azure, execute o seguinte script:

az provider list --query "[].{namespace:namespace, resourceType:resourceType[]}"

Você também pode usar o seguinte cmdlet do PowerShell:

Get-AzureRmResourceProvider | select-object ProviderNamespace -ExpandProperty ResourceTypes | ft ProviderNamespace, ResourceTypeName, ApiVersions

Consulte os locais de recursos com um parâmetro

Um modelo é sempre implantado em um grupo de recursos que reside em uma região. Além da implantação em si, cada recurso em um modelo também tem uma propriedade location que você usa para especificar a região a ser implantada. Para desenvolver seu modelo para consistência na nuvem, você precisa de uma maneira dinâmica de fazer referência a locais de recursos, porque cada Pilha do Azure pode conter nomes de locais exclusivos. Normalmente, os recursos são implantados na mesma região que o grupo de recursos, mas para dar suporte a cenários como a disponibilidade de aplicativos entre regiões, pode ser útil distribuir recursos entre regiões.

Embora você possa codificar os nomes de região ao especificar as propriedades do recurso em um modelo, essa abordagem não garante que o modelo possa ser implantado em outros ambientes do Azure Stack, porque o nome da região provavelmente não existe lá.

Para acomodar regiões diferentes, adicione um local de parâmetro de entrada ao modelo com um valor padrão. O valor padrão será usado se nenhum valor for especificado durante a implantação.

A função [resourceGroup()] de modelo retorna um objeto que contém os seguintes pares chave/valor:

{
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
  "name": "{resourceGroupName}",
  "location": "{resourceGroupLocation}",
  "tags": {
  },
  "properties": {
    "provisioningState": "{status}"
  }
}

Ao fazer referência à chave de local do objeto no defaultValue do parâmetro de entrada, o Azure Resource Manager substituirá, em tempo de execução, a [resourceGroup().location] função de modelo pelo nome do local do grupo de recursos no qual o modelo é implantado.

"parameters": {
  "location": {
    "type": "string",
    "metadata": {
      "description": "Location the resources will be deployed to."
    },
    "defaultValue": "[resourceGroup().location]"
  }
},
"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2015-06-15",
    "name": "storageaccount1",
    "location": "[parameters('location')]",
    ...

Com essa função de modelo, você pode implantar seu modelo em qualquer nuvem sem nem mesmo saber os nomes das regiões com antecedência. Além disso, um local para um recurso específico no modelo pode diferir do local do grupo de recursos. Nesse caso, você pode configurá-lo usando parâmetros de entrada adicionais para esse recurso específico, enquanto os outros recursos no mesmo modelo ainda usam o parâmetro de entrada de local inicial.

Rastreie versões usando perfis de API

Pode ser muito desafiador acompanhar todos os provedores de recursos disponíveis e versões de API relacionadas que estão presentes no Azure Stack. Por exemplo, no momento da redação, a versão mais recente da API para Microsoft.Compute/availabilitySets no Azure é 2018-04-01, enquanto a versão de API disponível comum ao Azure e ao Azure Stack é 2016-03-30. A versão comum da API para Microsoft.Storage/storageAccounts compartilhada entre todos os locais do Azure e do Azure Stack é 2016-01-01, enquanto a versão mais recente da API no Azure é 2018-02-01.

Por esse motivo, o Resource Manager introduziu o conceito de perfis de API nos modelos. Sem perfis de API, cada recurso em um modelo é configurado com um apiVersion elemento que descreve a versão da API para esse recurso específico.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
          "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2016-01-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "apiVersion": "2016-03-30",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

Uma versão de perfil de API atua como um alias para uma única versão de API por tipo de recurso comum ao Azure e ao Azure Stack. Em vez de especificar uma versão da API para cada recurso em um modelo, especifique apenas a versão do perfil da API em um novo elemento raiz chamado apiProfile e omita o apiVersion elemento para os recursos individuais.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

O perfil da API garante que as versões da API estejam disponíveis em todos os locais, portanto, não é necessário verificar manualmente as apiVersions disponíveis em um local específico. Para garantir que as versões de API referenciadas pelo seu perfil de API estejam presentes em um ambiente do Azure Stack, os operadores do Azure Stack devem manter a solução atualizada com base na política de suporte. Se um sistema estiver mais de seis meses desatualizado, ele é considerado fora de conformidade e o ambiente deve ser atualizado.

O perfil da API não é um elemento obrigatório em um modelo. Mesmo se você adicionar o elemento , ele só será usado para recursos para os quais não apiVersion é especificado. Este elemento permite alterações graduais, mas não requer alterações nos modelos existentes.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2016-01-01",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

Verificar referências de pontos finais

Os recursos podem ter referências a outros serviços na plataforma. Por exemplo, um IP público pode ter um nome DNS público atribuído a ele. A nuvem pública, as nuvens soberanas e as soluções Azure Stack têm seus próprios namespaces de ponto de extremidade distintos. Na maioria dos casos, um recurso requer apenas um prefixo como entrada no modelo. Durante o tempo de execução, o Azure Resource Manager acrescenta o valor do ponto de extremidade a ele. Alguns valores de ponto de extremidade precisam ser explicitamente especificados no modelo.

Nota

Para desenvolver modelos para consistência na nuvem, não codifice namespaces de ponto final.

Os dois exemplos a seguir são namespaces de ponto de extremidade comuns que precisam ser explicitamente especificados ao criar um recurso:

  • Contas de armazenamento (blob, fila, tabela e arquivo)
  • Cadeias de conexão para bancos de dados e Cache do Azure para Redis

Os namespaces de ponto de extremidade também podem ser usados na saída de um modelo como informações para o usuário quando a implantação for concluída. Seguem-se exemplos comuns:

  • Contas de armazenamento (blob, fila, tabela e arquivo)
  • Cadeias de conexão (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
  • Gestor de Tráfego
  • domainNameLabel de um endereço IP público
  • Serviços cloud

Em geral, evite pontos de extremidade codificados em um modelo. A prática recomendada é usar a função de modelo de referência para recuperar os pontos de extremidade dinamicamente. Por exemplo, o ponto de extremidade mais comumente codificado é o namespace de ponto de extremidade para contas de armazenamento. Cada conta de armazenamento tem um FQDN exclusivo que é construído concatenando o nome da conta de armazenamento com o namespace do ponto de extremidade. Uma conta de armazenamento de blob chamada mystorageaccount1 resulta em FQDNs diferentes, dependendo da nuvem:

  • mystorageaccount1.blob.core.windows.net quando criado na nuvem global do Azure.
  • mystorageaccount1.blob.core.chinacloudapi.cn quando criado no Azure operado pela nuvem 21Vianet.

A seguinte função de modelo de referência recupera o namespace do ponto de extremidade do provedor de recursos de armazenamento:

"diskUri":"[concat(reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob, 'container/myosdisk.vhd')]"

Ao substituir o valor codificado do ponto de extremidade da conta de armazenamento pela reference função de modelo, você pode usar o mesmo modelo para implantar em ambientes diferentes com êxito sem fazer alterações na referência do ponto de extremidade.

Consultar recursos existentes por ID exclusivo

Você também pode fazer referência a um recurso existente do mesmo ou de outro grupo de recursos, e dentro da mesma assinatura ou de outra assinatura, dentro do mesmo locatário na mesma nuvem. Para recuperar as propriedades do recurso, você deve usar o identificador exclusivo do próprio recurso. A resourceId função de modelo recupera a ID exclusiva de um recurso, como o SQL Server, como mostra o código a seguir:

"outputs": {
  "resourceId":{
    "type": "string",
    "value": "[resourceId('otherResourceGroup', 'Microsoft.Sql/servers', parameters('serverName'))]"
  }
}

Em seguida, você pode usar a resourceId função dentro da reference função de modelo para recuperar as propriedades de um banco de dados. O objeto return contém a fullyQualifiedDomainName propriedade que contém o valor completo do ponto de extremidade. Esse valor é recuperado em tempo de execução e fornece o namespace de ponto de extremidade específico do ambiente de nuvem. Para definir a cadeia de conexão sem codificar o namespace do ponto de extremidade, você pode consultar a propriedade do objeto de retorno diretamente na cadeia de conexão, conforme mostrado:

"[concat('Server=tcp:', reference(resourceId('sql', 'Microsoft.Sql/servers', parameters('test')), '2015-05-01-preview').fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('database'),';User ID=', parameters('username'), ';Password=', parameters('pass'), ';Encrypt=True;')]"

Considerar as propriedades do recurso

Recursos específicos em ambientes do Azure Stack têm propriedades exclusivas que você deve considerar em seu modelo.

Verifique se as imagens de VM estão disponíveis

O Azure fornece uma seleção rica de imagens de VM. Essas imagens são criadas e preparadas para implantação pela Microsoft e parceiros. As imagens formam a base para VMs na plataforma. No entanto, um modelo consistente com a nuvem deve referir-se apenas aos parâmetros disponíveis — em particular, o editor, a oferta e a SKU das imagens de VM disponíveis para o Azure global, as nuvens soberanas do Azure ou uma solução do Azure Stack.

Para recuperar uma lista das imagens de VM disponíveis em um local, execute o seguinte comando da CLI do Azure:

az vm image list -all

Você pode recuperar a mesma lista com o cmdlet do Azure PowerShell Get-AzureRmVMImagePublisher e especificar o local desejado com o -Location parâmetro. Por exemplo:

Get-AzureRmVMImagePublisher -Location "West Europe" | Get-AzureRmVMImageOffer | Get-AzureRmVMImageSku | Get-AzureRmVMImage

Este comando leva alguns minutos para retornar todas as imagens disponíveis na região Europa Ocidental da nuvem global do Azure.

Se você disponibilizasse essas imagens de VM para o Azure Stack, todo o armazenamento disponível seria consumido. Para acomodar até mesmo a menor unidade de escala, o Azure Stack permite que você selecione as imagens que deseja adicionar a um ambiente.

O exemplo de código a seguir mostra uma abordagem consistente para fazer referência aos parâmetros de editor, oferta e SKU em seus modelos ARM:

"storageProfile": {
    "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "2016-Datacenter",
    "version": "latest"
    }
}

Verifique os tamanhos das VMs locais

Para desenvolver seu modelo para consistência na nuvem, você precisa garantir que o tamanho da VM desejado esteja disponível em todos os ambientes de destino. Os tamanhos de VM são um agrupamento de características e recursos de desempenho. Alguns tamanhos de VM dependem do hardware em que a VM é executada. Por exemplo, se você quiser implantar uma VM otimizada para GPU, o hardware que executa o hipervisor precisa ter as GPUs de hardware.

Quando a Microsoft introduz um novo tamanho de VM que tem determinadas dependências de hardware, o tamanho da VM geralmente é disponibilizado primeiro em um pequeno subconjunto de regiões na nuvem do Azure. Mais tarde, é disponibilizado para outras regiões e nuvens. Para garantir que o tamanho da VM exista em cada nuvem na qual você implanta, você pode recuperar os tamanhos disponíveis com o seguinte comando da CLI do Azure:

az vm list-sizes --location "West Europe"

No Azure PowerShell, utilize:

Get-AzureRmVMSize -Location "West Europe"

Para obter uma lista completa dos serviços disponíveis, consulte Produtos disponíveis por região.

Verificar o uso dos Discos Gerenciados do Azure no Azure Stack

Os discos gerenciados manipulam o armazenamento para um locatário do Azure. Em vez de criar explicitamente uma conta de armazenamento e especificar o URI para um VHD (disco rígido virtual), você pode usar discos gerenciados para executar implicitamente essas ações ao implantar uma VM. Os discos gerenciados aumentam a disponibilidade colocando todos os discos de VMs no mesmo conjunto de disponibilidade em unidades de armazenamento diferentes. Além disso, os VHDs existentes podem ser convertidos de armazenamento Standard para Premium com significativamente menos tempo de inatividade.

Embora os discos gerenciados estejam no roteiro do Azure Stack, eles não são suportados no momento. Até que estejam, você pode desenvolver modelos consistentes com a nuvem para o Azure Stack especificando explicitamente VHDs usando o vhd elemento no modelo para o recurso de VM, conforme mostrado:

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "name": "osdisk",
    "vhd": {
      "uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
    },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

Por outro lado, para especificar uma configuração de disco gerenciado em um modelo, remova o vhd elemento da configuração do disco.

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

As mesmas alterações também se aplicam a discos de dados.

Verifique se as extensões de VM estão disponíveis no Azure Stack

Outra consideração para a consistência da nuvem é o uso de extensões de máquina virtual para configurar os recursos dentro de uma VM. Nem todas as extensões de VM estão disponíveis no Azure Stack. Um modelo pode especificar os recursos dedicados à extensão VM, criando dependências e condições dentro do modelo.

Por exemplo, se você quiser configurar uma VM executando o Microsoft SQL Server, a extensão da VM poderá configurar o SQL Server como parte da implantação do modelo. Considere o que acontece se o modelo de implantação também contiver um servidor de aplicativos configurado para criar um banco de dados na VM que executa o SQL Server. Além de também usar uma extensão de VM para os servidores de aplicativos, você pode configurar a dependência do servidor de aplicativos no retorno bem-sucedido do recurso de extensão de VM do SQL Server. Essa abordagem garante que a VM que executa o SQL Server esteja configurada e disponível quando o servidor de aplicativos for instruído a criar o banco de dados.

A abordagem declarativa do modelo permite definir o estado final dos recursos e suas interdependências, enquanto a plataforma cuida da lógica necessária para as dependências.

Verifique se as extensões de VM estão disponíveis

Existem muitos tipos de extensões de VM. Ao desenvolver um modelo para consistência na nuvem, certifique-se de usar apenas as extensões disponíveis em todas as regiões de destino do modelo.

Para recuperar uma lista das extensões de VM disponíveis para uma região específica (neste exemplo, myLocation), execute o seguinte comando da CLI do Azure:

az vm extension image list --location myLocation

Você também pode executar o cmdlet Get-AzureRmVmImagePublisher do Azure PowerShell e usá-lo -Location para especificar o local da imagem da máquina virtual. Por exemplo:

Get-AzureRmVmImagePublisher -Location myLocation | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version

Certifique-se de que as versões estão disponíveis

Como as extensões de VM são recursos primários do Gerenciador de Recursos, elas têm suas próprias versões de API. Como mostra o código a seguir, o tipo de extensão VM é um recurso aninhado no provedor de recursos Microsoft.Compute.

{
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "apiVersion": "2015-06-15",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

A versão da API do recurso de extensão de VM deve estar presente em todos os locais que você planeja segmentar com seu modelo. A dependência de local funciona como a disponibilidade da versão da API do provedor de recursos discutida anteriormente na seção "Verificar a versão de todos os tipos de recursos".

Para recuperar uma lista das versões de API disponíveis para o recurso de extensão de VM, use o cmdlet Get-AzureRmResourceProvider com o provedor de recursos Microsoft.Compute , conforme mostrado:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachines/extensions"}

Você também pode usar extensões de VM em conjuntos de dimensionamento de máquina virtual. Aplicam-se as mesmas condições de localização. Para desenvolver seu modelo para consistência na nuvem, verifique se as versões da API estão disponíveis em todos os locais nos quais você planeja implantar. Para recuperar as versões de API do recurso de extensão de VM para conjuntos de escala, use o mesmo cmdlet anterior, mas especifique o tipo de recurso de conjuntos de escala de máquina virtual conforme mostrado:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachineScaleSets/extensions"}

Cada extensão específica também é versionada. Esta versão é mostrada na typeHandlerVersion propriedade da extensão VM. Verifique se a versão especificada no typeHandlerVersion elemento das extensões de VM do modelo está disponível nos locais onde você planeja implantar o modelo. Por exemplo, o código a seguir especifica a versão 1.7:

{
    "type": "extensions",
    "apiVersion": "2016-03-30",
    "name": "MyCustomScriptExtension",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/myVM', copyindex())]"
    ],
    "properties": {
        "publisher": "Microsoft.Compute",
        "type": "CustomScriptExtension",
        "typeHandlerVersion": "1.7",
        ...

Para recuperar uma lista das versões disponíveis para uma extensão de VM específica, use o cmdlet Get-AzureRmVMExtensionImage . O exemplo a seguir recupera as versões disponíveis para a extensão de VM DSC (Configuração de Estado Desejado) do PowerShell de myLocation:

Get-AzureRmVMExtensionImage -Location myLocation -PublisherName Microsoft.PowerShell -Type DSC | FT

Para obter uma lista de editores, use o comando Get-AzureRmVmImagePublisher . Para solicitar o tipo, use a recomendação Get-AzureRmVMExtensionImageType .

Dicas para testes e automação

É um desafio acompanhar todas as configurações, recursos e limitações relacionados durante a criação de um modelo. A abordagem comum é desenvolver e testar modelos em uma única nuvem antes que outros locais sejam direcionados. No entanto, quanto mais cedo os testes forem realizados no processo de criação, menos solução de problemas e reescrita de código sua equipe de desenvolvimento terá que fazer. As implantações que falham devido a dependências de local podem ser demoradas para solucionar problemas. É por isso que recomendamos testes automatizados o mais cedo possível no ciclo de criação. Em última análise, você precisará de menos tempo de desenvolvimento e menos recursos, e seus artefatos consistentes com a nuvem se tornarão ainda mais valiosos.

A imagem a seguir mostra um exemplo típico de um processo de desenvolvimento para uma equipe usando um ambiente de desenvolvimento integrado (IDE). Em diferentes estágios da linha do tempo, diferentes tipos de teste são executados. Aqui, dois desenvolvedores estão trabalhando na mesma solução, mas esse cenário se aplica igualmente a um único desenvolvedor ou a uma grande equipe. Cada desenvolvedor normalmente cria uma cópia local de um repositório central, permitindo que cada um trabalhe na cópia local sem afetar os outros que podem estar trabalhando nos mesmos arquivos.

Diagrama mostrando testes de unidade paralelos e testes de integração em IDEs locais, mesclando no fluxo de desenvolvimento de CI/CD com testes de unidade, testes de integração, implantação de teste e implantação final.

Considere as seguintes dicas para testes e automação:

  • Faça uso de ferramentas de teste. Por exemplo, o Visual Studio Code e o Visual Studio incluem o IntelliSense e outros recursos que podem ajudá-lo a validar seus modelos.
  • Para melhorar a qualidade do código durante o desenvolvimento no IDE local, execute a análise estática de código com testes de unidade e testes de integração.
  • Para uma experiência ainda melhor durante o desenvolvimento inicial, os testes de unidade e os testes de integração só devem avisar quando um problema for encontrado e prosseguir com os testes. Dessa forma, você pode identificar os problemas a serem resolvidos e priorizar a ordem das alterações, também conhecida como TDD (test-driven deployment).
  • Lembre-se de que alguns testes podem ser executados sem estar conectado ao Azure Resource Manager. Outros, como a implantação de modelos de teste, exigem que o Gerenciador de Recursos execute determinadas ações que não podem ser executadas offline.
  • Testar um modelo de implantação em relação à API de validação não é igual a uma implantação real. Além disso, mesmo se você implantar um modelo a partir de um arquivo local, todas as referências a modelos aninhados no modelo serão recuperadas diretamente pelo Gerenciador de Recursos e os artefatos referenciados pelas extensões de VM serão recuperados pelo agente de VM em execução dentro da VM implantada.

Próximos passos