Definir recursos

Concluído

Os modelos de bíceps são os arquivos criados que definem os recursos do Azure a serem implantados.

Sua empresa de brinquedos precisa que você crie um modelo de Bíceps reutilizável para lançamentos de produtos. O modelo precisa implantar uma conta de armazenamento do Azure e recursos do Serviço de Aplicativo do Azure, que serão usados para o marketing de cada novo produto durante seu lançamento.

Nesta unidade, você aprenderá como definir um recurso em um modelo Bicep, como os nomes de recursos funcionam e como você pode criar recursos que se relacionam entre si.

Nota

Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você vai praticar o que você aprende aqui em breve.

Definir um recurso

A principal coisa que você fará com os modelos do Bicep é definir seus recursos do Azure. Aqui está um exemplo de como uma definição de recurso típica se parece no Bicep. Este exemplo cria uma conta de armazenamento chamada toylaunchstorage.

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'toylaunchstorage'
  location: 'westus3'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Vejamos de perto algumas partes fundamentais dessa definição de recurso:

  • A resource palavra-chave no início informa ao Bicep que você está prestes a definir um recurso.

  • Em seguida, você dá ao recurso um nome simbólico. No exemplo, o nome simbólico do recurso é storageAccount. Os nomes simbólicos são usados no Bicep para se referir ao recurso, mas nunca aparecerão no Azure.

  • Microsoft.Storage/storageAccounts@2022-09-01é o tipo de recurso e a versão da API do recurso. Microsoft.Storage/storageAccounts informa ao Bicep que você está declarando uma conta de armazenamento do Azure. A data 2022-09-01 é a versão da API de Armazenamento do Azure que o Bicep usa quando cria o recurso.

    Gorjeta

    A extensão Bicep para Visual Studio Code ajuda você a encontrar os tipos de recursos e versões de API para os recursos que você cria. Se você estiver familiarizado com modelos ARM, observe que a versão da API corresponde à versão que você usaria lá também.

  • Você precisa declarar um nome de recurso, que é o nome que a conta de armazenamento será atribuída no Azure. Você definirá um nome de recurso usando a name palavra-chave.

    Importante

    Os nomes simbólicos são usados apenas no modelo Bicep e não aparecem no Azure. Os nomes dos recursos aparecem no Azure.

  • Em seguida, você definirá outros detalhes do recurso, como sua localização, SKU (nível de preço) e tipo. Há também propriedades que você pode definir que são diferentes para cada tipo de recurso. Diferentes versões de API também podem introduzir propriedades diferentes. Neste exemplo, estamos definindo a camada de acesso da conta de armazenamento como Hot.

Gorjeta

Os nomes de recursos geralmente têm regras que você deve seguir, como comprimentos máximos, caracteres permitidos e exclusividade em todo o Azure. Os requisitos para nomes de recursos são diferentes para cada tipo de recurso do Azure. Certifique-se de entender as restrições e os requisitos de nomenclatura antes de adicioná-los ao seu modelo.

O que acontece quando os recursos dependem uns dos outros?

Um modelo Bicep geralmente inclui vários recursos. Muitas vezes, você precisa de um recurso para depender de outro recurso. Talvez seja necessário extrair algumas informações de um recurso para poder definir outro. Ou, se você estiver implantando um aplicativo Web, terá que criar a infraestrutura do servidor antes de adicionar um aplicativo a ele. Essas relações são chamadas de dependências.

Você precisará implantar um aplicativo do Serviço de Aplicativo para o modelo que ajudará a iniciar o produto de brinquedo, mas para criar um aplicativo do Serviço de Aplicativo, primeiro você precisa criar um plano do Serviço de Aplicativo. O plano do Serviço de Aplicativo representa os recursos de hospedagem do servidor e é declarado como este exemplo:

resource appServicePlan 'Microsoft.Web/serverFarms@2022-03-01' = {
  name: 'toy-product-launch-plan'
  location: 'westus3'
  sku: {
    name: 'F1'
  }
}

Esta definição de recurso está informando ao Bicep que você deseja implantar um plano do Serviço de Aplicativo que tenha o tipo Microsoft.Web/serverFarmsde recurso . O recurso de plano é chamado toy-product-launch-plan, e é implantado na região Oeste dos EUA 3. Ele usa um SKU de preço de F1, que é o nível gratuito do Serviço de Aplicativo.

Agora que você declarou o plano do Serviço de Aplicativo, a próxima etapa é declarar o aplicativo:

resource appServiceApp 'Microsoft.Web/sites@2022-03-01' = {
  name: 'toy-product-launch-1'
  location: 'westus3'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Este modelo instrui o Azure a hospedar o aplicativo no plano que você criou. Observe que a definição do plano inclui o nome simbólico do plano do Serviço de Aplicativo nesta linha: serverFarmId: appServicePlan.id. Essa linha significa que o Bicep obterá a ID de recurso do plano do Serviço de Aplicativo usando a id propriedade. É efetivamente dizer: o ID do farm de servidores deste aplicativo é o ID do plano do Serviço de Aplicativo definido anteriormente.

Gorjeta

No Azure, uma ID de recurso é um identificador exclusivo para cada recurso. A ID do recurso inclui a ID de assinatura do Azure, o nome do grupo de recursos e o nome do recurso, juntamente com algumas outras informações.

Ao declarar o recurso do aplicativo com uma propriedade que faz referência ao nome simbólico do plano, o Azure entende a dependência implícita entre o aplicativo do Serviço de Aplicativo e o plano. Quando implanta os recursos, o Azure garante que implanta totalmente o plano antes de começar a implantar o aplicativo.