Definir recursos

  • 5 minutos

Modelos Bicep são os arquivos que você cria que definem os recursos do Azure a serem implantados.

A empresa de brinquedos precisa que você crie um modelo Bicep 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 o lançamento.

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

Observação

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

Definir um recurso

A principal função dos modelos do Bicep é definir os recursos do Azure. Aqui está um exemplo de como é uma definição de recurso típica no Bicep. Este exemplo cria uma conta de armazenamento chamada toylaunchstorage.

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

Vamos examinar mais detalhadamente algumas partes principais dessa definição de recurso:

  • A palavra-chave resource no início diz 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. Nomes simbólicos são usados no Bicep para se referir ao recurso, mas eles nunca aparecem no Azure.

  • Microsoft.Storage/storageAccounts@2022-09-01 é o tipo de recurso e a versão da API do recurso. Microsoft.Storage/storageAccounts diz 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 usará ao criar o recurso.

    Dica

    A extensão do Bicep para Visual Studio Code ajuda você a encontrar os tipos de recursos e as versões de API ideais para os recursos que você cria. Se você tiver familiaridade com modelos do 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 será atribuído à conta de armazenamento no Azure. Defina um nome de recurso usando a palavra-chave name.

    Importante

    Nomes simbólicos são usados somente no modelo do Bicep, não aparecendo no Azure. Os nomes dos recursos aparecem no Azure.

  • Em seguida, defina outros detalhes do recurso, como o tipo, a localização e o SKU (tipo de preço). Também há propriedades que você pode definir, que são diferentes para cada tipo de recurso. Diferentes versões da API também podem apresentar propriedades distintas. Neste exemplo, estamos configurando a camada de acesso da conta de armazenamento como Hot.

Dica

Os nomes de recursos geralmente têm regras que você precisa 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. Entenda 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. Geralmente, você precisa de um recurso para depender de outro. Talvez seja necessário extrair algumas informações de um recurso para poder definir outro. Ou, se você estiver implantando um aplicativo Web, precisará 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á na inicialização do produto de brinquedo, mas para criar um aplicativo do Serviço de Aplicativo, primeiro você precisará criar um plano do Serviço de Aplicativo. O Plano do Serviço de Aplicativo representa os recursos de hospedagem de servidor e é declarado conforme o seguinte exemplo:

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

Essa definição de recurso está dizendo ao Bicep que você deseja implantar um Plano do Serviço de Aplicativo que tenha o tipo de recurso Microsoft.Web/serverFarms. O recurso do plano é chamado de toy-product-launch-plan e implantado na região Oeste dos EUA 3. Ele usa uma SKU de preço F1, que é a camada gratuita 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@2023-12-01' = {
  name: 'toy-product-launch-1'
  location: 'westus3'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Esse 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 do recurso do plano do Serviço de Aplicativo usando a propriedade id. Na verdade, ele está dizendo: a ID do farm de servidores deste aplicativo é a ID do Plano do Serviço de Aplicativo definido anteriormente.

Dica

No Azure, uma ID do recurso é um identificador exclusivo para cada recurso. A ID do recurso inclui a ID da assinatura do Azure, o nome do grupo de recursos e o nome do recurso, além de 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. Ao implantar os recursos, o Azure garantirá que ele implante completamente o plano antes de começar a implantar o aplicativo.