Implantar recursos condicionalmente

Concluído

Você pode usar condições em seu código Bicep para implantar recursos somente quando restrições específicas estiverem em vigor.

Por exemplo, na sua empresa de brinquedos, você precisa implantar recursos em vários ambientes. Ao implantá-los em um ambiente de produção, você precisa garantir que a auditoria esteja habilitada para seus servidores lógicos SQL do Azure. Mas quando você implanta recursos em ambientes de desenvolvimento, não deseja habilitar a auditoria. Você deseja usar um único modelo para implantar recursos em todos os seus ambientes.

Nesta unidade, você aprenderá como implantar recursos condicionalmente.

Condições básicas de utilização

Ao implantar um recurso no Bicep, você pode fornecer a if palavra-chave seguida por uma condição. A condição deve ser resolvida para um valor booleano (verdadeiro ou falso). Se o valor for true, o recurso será implantado. Se o valor for false, o recurso não será implantado.

É comum criar condições com base nos valores dos parâmetros fornecidos. Por exemplo, o código a seguir implanta uma conta de armazenamento somente quando o deployStorageAccount parâmetro é definido como true:

param deployStorageAccount bool

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (deployStorageAccount) {
  name: 'teddybearstorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  // ...
}

Observe que a if palavra-chave está na mesma linha que a definição de recurso.

Usar expressões como condições

O exemplo anterior foi bastante básico. O deployStorageAccount parâmetro era do tipo bool, então é claro se ele tem um valor de true ou false.

No Bicep, as condições também podem incluir expressões. No exemplo a seguir, o código implanta um recurso de auditoria SQL somente quando o valor do environmentName parâmetro é igual a Production:

@allowed([
  'Development'
  'Production'
])
param environmentName string

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (environmentName == 'Production') {
  parent: server
  name: 'default'
  properties: {
  }
}

Geralmente, é uma boa ideia criar uma variável para a expressão que você está usando como condição. Dessa forma, seu modelo fica mais fácil de entender e ler. Eis um exemplo:

@allowed([
  'Development'
  'Production'
])
param environmentName string

var auditingEnabled = environmentName == 'Production'

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
  }
}

Depende de recursos implantados condicionalmente

Quando você implanta recursos condicionalmente, às vezes precisa estar ciente de como o Bicep avalia as dependências entre eles.

Vamos continuar escrevendo algum código Bicep para implantar configurações de auditoria SQL. O arquivo Bicep também precisa declarar um recurso de conta de armazenamento, como mostrado aqui:

@allowed([
  'Development'
  'Production'
])
param environmentName string
param location string = resourceGroup().location
param auditStorageAccountName string = 'bearaudit${uniqueString(resourceGroup().id)}'

var auditingEnabled = environmentName == 'Production'
var storageAccountSkuName = 'Standard_LRS'

resource auditStorageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (auditingEnabled) {
  name: auditStorageAccountName
  location: location
  sku: {
    name: storageAccountSkuName
  }
  kind: 'StorageV2'
}

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
  }
}

Observe que a conta de armazenamento também tem uma condição. Isso significa que ele também não será implantado para ambientes que não sejam de produção. O recurso de configurações de auditoria SQL agora pode consultar os detalhes da conta de armazenamento:

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
    state: 'Enabled'
    storageEndpoint: environmentName == 'Production' ? auditStorageAccount.properties.primaryEndpoints.blob : ''
    storageAccountAccessKey: environmentName == 'Production' ? listKeys(auditStorageAccount.id, auditStorageAccount.apiVersion).keys[0].value : ''
  }
}

Observe que esse código Bicep usa o operador de ponto de interrogação (?) dentro das storageEndpoint propriedades e storageAccountAccessKey . Quando o código Bicep é implantado em um ambiente de produção, as expressões são avaliadas para os detalhes da conta de armazenamento. Quando o código é implantado em um ambiente que não é de produção, as expressões são avaliadas para uma cadeia de caracteres vazia ('').

Você pode se perguntar por que esse código é necessário, porque auditingSettings auditStorageAccount ambos têm a mesma condição, e assim você nunca precisará implantar um recurso de configurações de auditoria SQL sem uma conta de armazenamento. Embora isso seja verdade, o Azure Resource Manager avalia as expressões de propriedade antes das condicionais nos recursos. Isso significa que, se o código Bicep não tiver essa expressão, a implantação falhará com um ResourceNotFound erro.

Nota

Não é possível definir dois recursos com o mesmo nome no mesmo arquivo Bicep e, em seguida, implantar condicionalmente apenas um deles. A implantação falhará, porque o Resource Manager vê isso como um conflito.

Se você tiver vários recursos, todos com a mesma condição para implantação, considere usar módulos Bicep. Você pode criar um módulo que implanta todos os recursos e, em seguida, colocar uma condição na declaração do módulo no arquivo Bicep principal.