Desenvolver modelos arm para consistência na cloud

Importante

A utilização desta funcionalidade do Azure a partir do PowerShell requer a instalação do AzureRM módulo. Este é um módulo mais antigo disponível apenas para Windows PowerShell 5.1 que já não recebe novas funcionalidades. Os Az módulos e AzureRMnão são compatíveis quando instalados para as mesmas versões do PowerShell. Se precisar de ambas as versões:

1. Desinstale o módulo Az a partir 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. Transfira e instale o PowerShell Core 6.x ou posterior.
4. Instale o módulo Az numa sessão do PowerShell Core.

Uma das principais vantagens do Azure é a consistência. Os investimentos de desenvolvimento para uma localização são reutilizáveis noutra. Um modelo do Azure Resource Manager (modelo arm) torna as suas implementações consistentes e repetíveis em todos os ambientes, incluindo o Azure global, as clouds soberanas do Azure e o Azure Stack. No entanto, para reutilizar modelos em clouds, tem de considerar dependências específicas da cloud, como explica este guia.

A Microsoft oferece serviços cloud inteligentes e prontos para empresas em várias localizações, incluindo:

• A plataforma global do Azure suportada por uma rede crescente de datacenters geridos pela Microsoft em regiões de todo o mundo.
• Clouds soberanas isoladas como o Azure Germany, Azure Government e o Microsoft Azure operado pela 21Vianet. As clouds soberanas fornecem uma plataforma consistente com a maioria das mesmas funcionalidades fantásticas às quais os clientes globais do Azure têm acesso.
• O Azure Stack, uma plataforma de cloud híbrida que lhe permite fornecer serviços do Azure a partir do datacenter da sua organização. As empresas podem configurar o Azure Stack nos seus próprios datacenters ou consumir os Serviços do Azure a partir de fornecedores de serviços, executando o Azure Stack nas respetivas instalações (por vezes conhecidas como regiões alojadas).

No centro de todas estas clouds, o Azure Resource Manager fornece uma API que permite que uma grande variedade de interfaces de utilizador comuniquem com a plataforma do Azure. Esta API fornece-lhe poderosas capacidades de infraestrutura como código. Qualquer tipo de recurso disponível na plataforma cloud do Azure pode ser implementado e configurado com o Azure Resource Manager. Com um único modelo, pode implementar e configurar a sua aplicação completa para um estado final operacional.

A consistência do Azure global, das clouds soberanas, das clouds alojadas e de uma cloud no seu datacenter ajuda-o a beneficiar do Azure Resource Manager. Pode reutilizar os seus investimentos de desenvolvimento nestas clouds quando configurar a implementação e a configuração de recursos baseados em modelos.

No entanto, apesar de as clouds globais, soberanas, alojadas e híbridas fornecerem serviços consistentes, nem todas as clouds são idênticas. Como resultado, pode criar um modelo com dependências de funcionalidades disponíveis apenas numa nuvem específica.

O resto deste guia descreve as áreas a considerar ao planear desenvolver modelos arm novos ou atualizar modelos do ARM existentes para o Azure Stack. Em geral, a lista de verificação deve incluir os seguintes itens:

• Verifique se as funções, pontos finais, serviços e outros recursos no modelo estão disponíveis nas localizações de implementação de destino.
• Armazene modelos aninhados e artefactos de configuração em localizações acessíveis, garantindo o acesso entre clouds.
• Utilize referências dinâmicas em vez de ligações e elementos de codificação rígida.
• Certifique-se de que os parâmetros de modelo que utiliza funcionam nas clouds de destino.
• Verifique se as propriedades específicas do recurso estão disponíveis nas clouds de destino.

Para obter uma introdução aos modelos do ARM, veja Implementação de modelos.

Garantir que as funções de modelo funcionam

A sintaxe básica de um modelo do ARM é JSON. Os modelos utilizam um superconjunto de JSON, expandindo a sintaxe com expressões e funções. O processador de linguagem de modelo é atualizado frequentemente para suportar funções de modelo adicionais. Para obter uma explicação detalhada das funções de modelo disponíveis, veja Funções de modelo do ARM.

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

As capacidades do Azure Resource Manager serão sempre introduzidas no Azure global primeiro. Pode utilizar o seguinte script do PowerShell para verificar se as funções de modelo recentemente introduzidas também estão disponíveis no Azure Stack:

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

2. Assim que tiver um clone local do repositório, ligue-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 implementa vários modelos minimizados, cada um contendo apenas funções de modelo exclusivas. A saída do script comunica as funções de modelo suportadas e indisponíveis.

Trabalhar com artefactos ligados

Um modelo pode conter referências a artefactos ligados e conter um recurso de implementação que liga a outro modelo. Os modelos ligados (também conhecidos como modelo aninhado) são obtidos por Resource Manager no runtime. Um modelo também pode conter referências a artefactos para extensões de máquina virtual (VM). Estes artefactos são obtidos pela extensão de VM em execução dentro da VM para configuração da extensão da VM durante a implementação do modelo.

As secções seguintes descrevem considerações sobre a consistência da cloud ao desenvolver modelos que incluem artefactos externos ao modelo de implementação principal.

Utilizar modelos aninhados entre regiões

Os modelos podem ser decompostos em modelos pequenos e reutilizáveis, cada um dos quais tem um objetivo específico e pode ser reutilizado em cenários de implementação. Para executar uma implementação, especifique um único modelo conhecido como o modelo principal ou principal. Especifica os recursos a implementar, como redes virtuais, VMs e aplicações Web. O modelo principal também pode conter uma ligação para outro modelo, o que significa que pode aninhar modelos. Da mesma forma, um modelo aninhado pode conter ligações para outros modelos. Pode aninhar até cinco níveis de profundidade.

O código seguinte 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 no runtime e obtém e avalia cada modelo aninhado. Depois de todos os modelos aninhados serem obtidos, o modelo é achatado e o processamento adicional é iniciado.

Tornar os modelos ligados acessíveis em clouds

Considere onde e como armazenar quaisquer modelos ligados que utilize. No runtime, o Azure Resource Manager obtém e, por conseguinte, requer acesso direto a todos os modelos ligados. Uma prática comum é utilizar o GitHub para armazenar os modelos aninhados. Um repositório do GitHub pode conter ficheiros acessíveis publicamente através de um URL. Embora esta técnica funcione bem para a cloud pública e as clouds soberanas, um ambiente do Azure Stack pode estar localizado numa rede empresarial ou numa localização remota desligada, sem qualquer acesso à Internet de saída. Nesses casos, o Azure Resource Manager não conseguiria obter os modelos aninhados.

Uma melhor prática para implementações entre cloud é armazenar os seus modelos ligados numa localização acessível para a cloud de destino. Idealmente, todos os artefactos de implementação são mantidos e implementados a partir de um pipeline de integração/desenvolvimento contínuo (CI/CD). Em alternativa, pode armazenar modelos aninhados num contentor de armazenamento de blobs, a partir do qual o Azure Resource Manager pode obtê-los.

Uma vez que o armazenamento de blobs em cada nuvem utiliza um nome de domínio completamente qualificado (FQDN) de ponto final diferente, configure o modelo com a localização dos modelos ligados com dois parâmetros. Os parâmetros podem aceitar a entrada do utilizador no momento da implementação. Normalmente, os modelos são criados e partilhados por várias pessoas, pelo que a melhor prática é utilizar um nome padrão para estes parâmetros. As convenções de nomenclatura ajudam a tornar os modelos mais reutilizáveis entre regiões, clouds e autores.

No código seguinte, _artifactsLocation é utilizado para apontar para uma única localização, que contém todos os artefactos relacionados com a implementação. Repare que é fornecido um valor predefinido. No momento da implementação, se não for especificado nenhum valor de entrada para _artifactsLocation, é utilizado o valor predefinido. O _artifactsLocationSasToken é utilizado como entrada para o sasToken. O valor predefinido deve ser uma cadeia vazia para cenários em _artifactsLocation que o não está protegido , por exemplo, um repositório público do GitHub.

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

Ao longo do modelo, as ligações são geradas ao combinar o URI base (a _artifactsLocation partir do parâmetro) com um caminho relativo a artefactos e o _artifactsLocationSasToken. O código seguinte mostra como especificar a ligação para o modelo aninhado com 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"
      }
    }
  }
]

Ao utilizar esta abordagem, é utilizado o valor predefinido para o _artifactsLocation parâmetro. Se os modelos ligados precisarem de ser obtidos a partir de uma localização diferente, a entrada do parâmetro pode ser utilizada no momento da implementação para substituir o valor predefinido. Não é necessária qualquer alteração ao modelo propriamente dito.

Utilizar _artifactsLocation em vez de ligações de codificação

Além de ser utilizado para modelos aninhados, o URL no _artifactsLocation parâmetro é utilizado como base para todos os artefactos relacionados de um modelo de implementação. Algumas extensões de VM incluem uma ligação para um script armazenado fora do modelo. Para estas extensões, não deve codificar as ligações. Por exemplo, as extensões de Script Personalizado e DSC do PowerShell podem ligar 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"
    ]
  }
}

Codificar as ligações para o script potencialmente impede que o modelo seja implementado com êxito noutra localização. Durante a configuração do recurso da VM, o agente da VM em execução na VM inicia uma transferência de todos os scripts ligados na extensão da VM e, em seguida, armazena os scripts no disco local da VM. Esta abordagem funciona como as ligações de modelo aninhadas explicadas anteriormente na secção "Utilizar modelos aninhados entre regiões".

Resource Manager obtém modelos aninhados no runtime. Para extensões de VM, a obtenção de quaisquer artefactos externos é efetuada pelo agente da VM. Além do iniciador diferente da obtenção de artefactos, a solução na definição do modelo é a mesma. Utilize o parâmetro _artifactsLocation com um valor predefinido do caminho base onde todos os artefactos são armazenados (incluindo os scripts da extensão da VM) e o _artifactsLocationSasToken parâmetro para a entrada do 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 artefacto, o método preferencial é utilizar a função de modelo uri, em vez da função concat template. Ao substituir ligações codificadas para os scripts na extensão da VM pela função de modelo uri, esta funcionalidade no modelo está configurada para consistência na cloud.

"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 esta abordagem, todos os artefactos de implementação, incluindo scripts de configuração, podem ser armazenados na mesma localização com o próprio modelo. Para alterar a localização de todas as ligações, só precisa de especificar um URL base diferente para os parâmetros artifactsLocation.

Factor in differing regional capabilities (Factor in differing regional capabilities)

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 testes internos rigorosos, os novos serviços ou atualizações aos serviços existentes são normalmente introduzidos numa pequena audiência de clientes que participam num programa de validação. Após a validação bem-sucedida do cliente, os serviços ou atualizações são disponibilizados num subconjunto de regiões do Azure, depois introduzidos em mais regiões, implementados nas clouds soberanas e potencialmente disponibilizados para os clientes do Azure Stack.

Sabendo que as regiões e clouds do Azure podem ser diferentes nos serviços disponíveis, pode tomar algumas decisões proativas sobre os seus modelos. Um bom local para começar é examinar os fornecedores de recursos disponíveis para uma cloud. Um fornecedor de recursos informa-o sobre o conjunto de recursos e operações que estão disponíveis para um serviço do Azure.

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

Para verificar os fornecedores de recursos que estão disponíveis numa determinada cloud, execute o seguinte script na CLI do Azure:

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

Também pode utilizar o seguinte cmdlet do PowerShell para ver os fornecedores 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 as suas próprias propriedades específicas. Por vezes, são adicionadas novas funcionalidades e propriedades relacionadas aos tipos de recursos existentes através de uma nova versão da API. Um recurso num modelo tem a sua própria propriedade de versão da API – apiVersion. Esta versão garante que uma configuração de recursos existente num modelo não é afetada por alterações na plataforma.

As novas versões de API introduzidas nos tipos de recursos existentes no Azure global podem não estar imediatamente disponíveis em todas as regiões, clouds soberanas ou Azure Stack. Para ver uma lista dos fornecedores de recursos, tipos de recursos e versões de API disponíveis para uma cloud, pode utilizar o Explorador de Recursos no portal do Azure. Procure Explorador de Recursos no menu Todos os Serviços. Expanda o nó Fornecedores no Explorador de Recursos para devolver todos os fornecedores de recursos disponíveis, os respetivos tipos de recursos e versões de API nessa cloud.

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

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

Também pode utilizar o seguinte cmdlet do PowerShell:

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

Veja localizações de recursos com um parâmetro

Um modelo é sempre implementado num grupo de recursos que reside numa região. Além da própria implementação, cada recurso num modelo também tem uma propriedade de localização que utiliza para especificar a região a implementar. Para desenvolver o seu modelo de consistência na cloud, precisa de uma forma dinâmica de referenciar localizações de recursos, uma vez que cada Azure Stack pode conter nomes de localização exclusivos. Normalmente, os recursos são implementados na mesma região que o grupo de recursos, mas para suportar cenários como a disponibilidade de aplicações entre regiões, pode ser útil distribuir recursos por regiões.

Apesar de poder codificar os nomes das regiões ao especificar as propriedades do recurso num modelo, esta abordagem não garante que o modelo possa ser implementado noutros ambientes do Azure Stack, uma vez que o nome da região provavelmente não existe.

Para acomodar regiões diferentes, adicione uma localização de parâmetro de entrada ao modelo com um valor predefinido. O valor predefinido será utilizado se não for especificado nenhum valor durante a implementação.

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

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

Ao referenciar a chave de localização do objeto no valor predefinido do parâmetro de entrada, o Azure Resource Manager substituirá, no runtime, a [resourceGroup().location] função de modelo pelo nome da localização do grupo de recursos no qual o modelo é implementado.

"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 esta função de modelo, pode implementar o seu modelo em qualquer cloud sem sequer saber antecipadamente os nomes das regiões. Além disso, uma localização para um recurso específico no modelo pode ser diferente da localização do grupo de recursos. Neste caso, pode configurá-lo utilizando parâmetros de entrada adicionais para esse recurso específico, enquanto os outros recursos no mesmo modelo ainda utilizam o parâmetro de entrada de localização inicial.

Controlar versões com perfis de API

Pode ser muito difícil controlar todos os fornecedores de recursos disponíveis e versões de API relacionadas que estão presentes no Azure Stack. Por exemplo, no momento da escrita, a versão mais recente da API para Microsoft.Compute/availabilitySets no Azure é 2018-04-01, enquanto a versão da API disponível comum ao Azure e ao Azure Stack é 2016-03-30. A versão comum da API para Microsoft.Storage/storageAccounts partilhada entre todas as localizações do Azure e do Azure Stack é 2016-01-01, enquanto a versão mais recente da API no Azure é 2018-02-01.

Por este motivo, Resource Manager introduziu o conceito de perfis de API em modelos. Sem perfis de API, cada recurso num 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 do perfil de API funciona como um alias para uma única versão da API por tipo de recurso comum ao Azure e ao Azure Stack. Em vez de especificar uma versão da API para cada recurso num modelo, especifique apenas a versão do perfil da API num novo elemento de 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 estão disponíveis em todas as localizações, pelo que não tem de verificar manualmente as apiVersions que estão disponíveis numa localização específica. Para garantir que as versões da API referenciadas pelo seu perfil de API estão presentes num ambiente do Azure Stack, os operadores do Azure Stack têm de manter a solução atualizada com base na política de suporte. Se um sistema estiver mais de seis meses desatualizado, este é considerado fora de conformidade e o ambiente tem de ser atualizado.

O perfil de API não é um elemento necessário num modelo. Mesmo que adicione o elemento, este só será utilizado para recursos para os quais não apiVersion é especificado. Este elemento permite alterações graduais, mas não requer alterações aos 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 ao mesmo. A cloud pública, as clouds soberanas e as soluções do Azure Stack têm os seus próprios espaços de nomes de ponto final distintos. Na maioria dos casos, um recurso requer apenas um prefixo como entrada no modelo. Durante o runtime, o Azure Resource Manager acrescenta-lhe o valor do ponto final. Alguns valores de ponto final têm de ser explicitamente especificados no modelo.

Nota

Para desenvolver modelos para consistência na cloud, não codificar espaços de nomes de pontos finais.

Os dois exemplos seguintes são espaços de nomes de pontos finais comuns que têm de ser explicitamente especificados ao criar um recurso:

• Contas de armazenamento (blob, fila, tabela e ficheiro)
• Cadeias de ligação para bases de dados e Cache do Azure para Redis

Os espaços de nomes de ponto final também podem ser utilizados na saída de um modelo como informações para o utilizador quando a implementação for concluída. Seguem-se exemplos comuns:

• Contas de armazenamento (blob, fila, tabela e ficheiro)
• Cadeias de ligaçã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 em nuvem

Em geral, evite pontos finais codificados num modelo. A melhor prática é utilizar a função de modelo de referência para obter os pontos finais dinamicamente. Por exemplo, o ponto final mais codificado é o espaço de nomes de ponto final para contas de armazenamento. Cada conta de armazenamento tem um FQDN exclusivo que é construído concatenando o nome da conta de armazenamento com o espaço de nomes de ponto final. Uma conta de armazenamento de blobs com o nome mystorageaccount1 resulta em FQDNs diferentes, dependendo da cloud:

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

A seguinte função de modelo de referência obtém o espaço de nomes de ponto final do fornecedor 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 reference final da conta de armazenamento pela função de modelo, pode utilizar o mesmo modelo para implementar em diferentes ambientes com êxito sem efetuar alterações à referência do ponto final.

Veja os recursos existentes por ID exclusivo

Também pode referir-se a um recurso existente do mesmo ou de outro grupo de recursos e na mesma subscrição ou outra subscrição, dentro do mesmo inquilino na mesma cloud. Para obter as propriedades do recurso, tem de utilizar o identificador exclusivo para o próprio recurso. A resourceId função de modelo obtém o ID exclusivo de um recurso, como SQL Server como mostra o seguinte código:

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

Em seguida, pode utilizar a resourceId função dentro da função de reference modelo para obter as propriedades de uma base de dados. O objeto de retorno contém a fullyQualifiedDomainName propriedade que contém o valor de ponto final completo. Este valor é obtido no runtime e fornece o espaço de nomes de ponto final específico do ambiente da cloud. Para definir a cadeia de ligação sem codificar o espaço de nomes de ponto final, pode consultar a propriedade do objeto de retorno diretamente na cadeia de ligaçã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

Os recursos específicos nos ambientes do Azure Stack têm propriedades exclusivas que tem de considerar no seu modelo.

Certifique-se de que as imagens da VM estão disponíveis

O Azure fornece uma seleção avançada de imagens de VM. Estas imagens são criadas e preparadas para implementação pela Microsoft e pelos parceiros. As imagens formam a base das VMs na plataforma. No entanto, um modelo consistente com a cloud deve referir-se apenas aos parâmetros disponíveis — em particular, o publicador, a oferta e o SKU das imagens de VM disponíveis para o Azure global, clouds soberanas do Azure ou uma solução do Azure Stack.

Para obter uma lista das imagens de VM disponíveis numa localização, execute o seguinte comando da CLI do Azure:

az vm image list -all

Pode obter a mesma lista com o cmdlet Azure PowerShell Get-AzureRmVMImagePublisher e especificar a localização que pretende com o -Location parâmetro. Por exemplo:

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

Este comando demora alguns minutos a devolver todas as imagens disponíveis na região Europa Ocidental da cloud global do Azure.

Se disponibilizou estas imagens de VM para o Azure Stack, todo o armazenamento disponível será consumido. Para acomodar até a unidade de escala mais pequena, o Azure Stack permite-lhe selecionar as imagens que pretende adicionar a um ambiente.

O seguinte exemplo de código mostra uma abordagem consistente para se referir aos parâmetros do publicador, oferta e SKU nos seus modelos do ARM:

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

Verificar os tamanhos de VMs locais

Para desenvolver o seu modelo de consistência na cloud, tem de se certificar de que o tamanho da VM que pretende está disponível em todos os ambientes de destino. Os tamanhos das VMs são um agrupamento de características e capacidades de desempenho. Alguns tamanhos de VM dependem do hardware em que a VM é executada. Por exemplo, se quiser implementar uma VM otimizada para GPU, o hardware que executa o hipervisor tem de 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 é normalmente disponibilizado primeiro num pequeno subconjunto de regiões na cloud do Azure. Posteriormente, é disponibilizado para outras regiões e clouds. Para se certificar de que o tamanho da VM existe em cada nuvem em que implementa, pode obter 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, veja Produtos disponíveis por região.

Verificar a utilização do Azure Managed Disks no Azure Stack

Os discos geridos processam o armazenamento de um inquilino do Azure. Em vez de criar explicitamente uma conta de armazenamento e especificar o URI para um disco rígido virtual (VHD), pode utilizar discos geridos para executar implicitamente estas ações quando implementa uma VM. Os discos geridos melhoram a disponibilidade ao colocar todos os discos de VMs no mesmo conjunto de disponibilidade em unidades de armazenamento diferentes. Além disso, os VHDs existentes podem ser convertidos do armazenamento Standard para Premium com um período de indisponibilidade significativamente menor.

Embora os discos geridos estejam no mapa de objetivos do Azure Stack, atualmente não são suportados. Até que estejam, pode desenvolver modelos consistentes com a cloud para o Azure Stack ao especificar explicitamente VHDs com o vhd elemento no modelo do recurso da 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 gerido num 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 aplicam 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 cloud é a utilização 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 da VM, criando dependências e condições no modelo.

Por exemplo, se quiser configurar uma VM com o Microsoft SQL Server, a extensão da VM pode configurar SQL Server como parte da implementação do modelo. Considere o que acontece se o modelo de implementação também contiver um servidor de aplicações configurado para criar uma base de dados na VM em execução SQL Server. Além de utilizar também uma extensão de VM para os servidores de aplicações, pode configurar a dependência do servidor da aplicação na devolução bem-sucedida do recurso de extensão de VM SQL Server. Esta abordagem garante que a VM em execução SQL Server está configurada e disponível quando o servidor da aplicação é instruído para criar a base de dados.

A abordagem declarativa do modelo permite-lhe definir o estado final dos recursos e as respetivas inter-dependências, enquanto a plataforma trata 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 cloud, certifique-se de que utiliza apenas as extensões que estão disponíveis em todas as regiões que o modelo visa.

Para obter uma lista das extensões de VM que estão 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

Também pode executar o cmdlet Get-AzureRmVmImagePublisher Azure PowerShell e utilizar -Location para especificar a localização 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

Uma vez que as extensões de VM são recursos de Resource Manager originais, têm as suas próprias versões de API. Como mostra o seguinte código, o tipo de extensão da VM é um recurso aninhado no fornecedor 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 da VM tem de estar presente em todas as localizações que planeia direcionar com o seu modelo. A dependência de localização funciona como a disponibilidade da versão da API do fornecedor de recursos abordada anteriormente na secção "Verificar a versão de todos os tipos de recursos".

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

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

Também pode utilizar extensões de VM em conjuntos de dimensionamento de máquinas virtuais. Aplicam-se as mesmas condições de localização. Para desenvolver o seu modelo de consistência na cloud, certifique-se de que as versões da API estão disponíveis em todas as localizações para as qual planeia implementar. Para obter as versões da API do recurso de extensão da VM para conjuntos de dimensionamento, utilize o mesmo cmdlet que anteriormente, mas especifique o tipo de recurso dos conjuntos de dimensionamento de máquinas virtuais, 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 tem versões. Esta versão é apresentada na typeHandlerVersion propriedade da extensão da VM. Certifique-se de que a versão especificada no typeHandlerVersion elemento das extensões de VM do modelo está disponível nas localizações onde planeia implementar o modelo. Por exemplo, o código seguinte 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 obter uma lista das versões disponíveis para uma extensão de VM específica, utilize o cmdlet Get-AzureRmVMExtensionImage . O exemplo seguinte obtém as versões disponíveis para a extensão de VM do DSC (Desired State Configuration) do PowerShell a partir de myLocation:

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

Para obter uma lista de publicadores, utilize o comando Get-AzureRmVmImagePublisher . Para pedir tipo, utilize o elogio Get-AzureRmVMExtensionImageType .

Sugestões para testes e automatização

É um desafio controlar todas as definições, capacidades e limitações relacionadas ao criar um modelo. A abordagem comum é desenvolver e testar modelos numa única cloud antes de outras localizações serem direcionadas. No entanto, quanto mais cedo os testes forem realizados no processo de criação, menos resolução de problemas e reescrita de código a equipa de desenvolvimento terá de fazer. As implementações que falham devido às dependências de localização podem ser demoradas para resolver problemas. É por isso que recomendamos testes automatizados o mais cedo possível no ciclo de criação. Em última análise, precisará de menos tempo de desenvolvimento e menos recursos e os artefactos consistentes com a cloud tornar-se-ão ainda mais valiosos.

A imagem seguinte mostra um exemplo típico de um processo de desenvolvimento para uma equipa que utiliza um ambiente de desenvolvimento integrado (IDE). Em diferentes fases da linha cronológica, são executados diferentes tipos de teste. Aqui, dois programadores estão a trabalhar na mesma solução, mas este cenário aplica-se igualmente a um único programador ou a uma equipa grande. Normalmente, cada programador cria uma cópia local de um repositório central, permitindo que cada um trabalhe na cópia local sem afetar as outras pessoas que podem estar a trabalhar nos mesmos ficheiros.

Considere as seguintes sugestões para testar e automatizar:

• Utilize as ferramentas de teste. Por exemplo, o Visual Studio Code e o Visual Studio incluem o IntelliSense e outras funcionalidades que podem ajudá-lo a validar os seus modelos.
• Para melhorar a qualidade do código durante o desenvolvimento no IDE local, efetue a análise de código estático com testes de unidades e testes de integração.
• Para uma experiência ainda melhor durante o desenvolvimento inicial, os testes de unidades e os testes de integração só devem avisar quando for encontrado um problema e prosseguir com os testes. Desta forma, pode identificar os problemas a resolver e priorizar a ordem das alterações, também referida como implementação baseada em testes (TDD).
• Tenha em atenção que alguns testes podem ser realizados sem estarem ligados ao Azure Resource Manager. Outros, como a implementação de modelos de teste, exigem Resource Manager para executar determinadas ações que não podem ser executadas offline.
• Testar um modelo de implementação na API de validação não é igual a uma implementação real. Além disso, mesmo que implemente um modelo a partir de um ficheiro local, quaisquer referências a modelos aninhados no modelo são obtidas diretamente por Resource Manager e os artefactos referenciados por extensões de VM são obtidos pelo agente da VM em execução dentro da VM implementada.

Passos seguintes

• Considerações sobre o modelo do Azure Resource Manager
• Melhores práticas para modelos do ARM