如何使用 Azure Bicep 调整现有资源？

Question

我目前正在将一些基础结构作为代码脚本从 Azure CLI 移植到 Azure Bicep。除此之外，Bicep 文件应该创建一个子网并允许从该子网访问现有的 Azure SQL Server 和现有的存储帐户。

对于 SQL Server，这很简单——我可以引用现有的服务器资源并声明一个代表 VNET 规则的子资源：

resource azureSqlServer 'Microsoft.Sql/servers@2021-05-01-preview' existing = {
  name: azureSqlServerName
  
  resource vnetRule 'virtualNetworkRules' = {
    name: azureSqlServerVnetRuleName
    properties: {
      virtualNetworkSubnetId: subnetId
    }
  }
}

但是，对于存储帐户，网络规则不是子资源，而是存储帐户资源 (properties.networkAcls.virtualNetworkRules) 的属性。我无法在我的 Bicep 文件中声明存储帐户的所有详细信息，因为该资源超出了我当前正在处理的部署的范围。本质上，我想调整现有资源，只需确保存在一条规则即可。

因为existing 不能与properties 结合使用，所以以下内容不起作用：

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' existing = {
  name: storageAccountName

  properties: {
    networkAcls: {
      virtualNetworkRules: [
        {
          id: subnetId
          action: 'Allow'
        }
      ]
    }
  }
}

有什么方法可以让我使用 Bicep 调整现有资源的一小部分？

Answer 1

更新：我刚刚意识到你 来自 Azure CLI 并试图在二头肌中找到一种方法 - 很抱歉没有回答你的实际问题 - 无论如何你的帖子让我以另一种方式思考这个问题比二头肌，所以我的“答案”就是我想出的......

...听起来我们以同样的方式考虑过这个问题；使用二头肌拉皮条现有的存储帐户，授予新的子网访问权限。但是我最终使用了 AzureCLI az storage account network-rule add

例如

newSubnet='/subscriptions/<subscr-guid>/resourceGroups/<rg-name-where-vnet-resides>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>'

az storage account network-rule add -g <rg-name-where-sa-resides> --account-name <storage-account-name> --subnet $newSubnet

从终端运行它或将其放入 devops 管道中的 AzureCLI 任务中（这是我需要的）

Answer 2

bicep 中的 existing 关键字用于告诉 bicep 该资源已经存在，您只需要在代码中对该资源进行符号引用。如果资源不存在，部署可能会以某种方式失败。

你的第一个 sn-p 相当于：

resource vnetRule 'Microsoft.Sql/servers/virtualNetworkRules@2021-05-01-preview' = {
  name: '${azureSqlServerName}/${azureSqlServerVnetRuleName}'
  properties: {
    virtualNetworkSubnetId: subnetId
  }
}

在您的第二个 sn-p 中，由于您要更新属性，因此您必须提供资源的完整声明，IOW 您必须定义和部署 storageAccount。这不是二头肌独有的，它是 Azure 中声明性模型的工作方式。

也就是说，如果你想部署到二头肌的另一个作用域，你可以使用具有作用域属性的模块。例如

module updateStorage 'storage.bicep' = {
  scope: resourceGroup(storageResourceGroupName)
  name: 'updateStorage'
}

缺点是您需要确保定义/声明该 storageAccount 所需的所有属性，这并不理想。有一些方法可以围绕它进行创作，但如果 storageAccount 不存在，则部署肯定会失败。例如，您可以断言 storageAccount 存在，获取其属性，然后合并或修改模块中的属性。您也许可以完成这项工作（取决于您的更改程度），但这在声明性模型中有点反模式。

有帮助吗？