如何通过Bicep部署在ADX集群级别运行工作负载组配置脚本？

嗨，这个问题我之前也帮朋友处理过，你碰到的「Not a database-scope command」报错其实很典型——你用的是数据库级的脚本配置项来执行集群范围的命令，这个属性本身只支持数据库层面的操作，自然会被拒绝。

要解决这个问题，你需要换用ADX专门的集群级脚本资源（Microsoft.Kusto/clusters/scripts），这个资源就是为执行集群层面的Kusto命令设计的，完美适配你的场景，而且还能满足你私网环境的要求。

给你一个具体的Bicep实现示例：

首先，假设你已经定义了ADX集群的基础资源：

resource adxCluster 'Microsoft.Kusto/clusters@2023-08-15' = {
  name: 'your-adx-cluster-name'
  location: resourceGroup().location
  sku: {
    name: 'Standard_D13_v2'
    tier: 'Standard'
    capacity: 2
  }
  // 这里可以保留你原来的私网配置，比如虚拟网络集成、Private Link等
}

接下来，在这个集群资源下添加集群脚本资源，把你的工作负载组配置命令放进去：

resource updateWorkloadGroupScript 'Microsoft.Kusto/clusters/scripts@2023-08-15' = {
  parent: adxCluster
  name: 'update-default-workload-group'
  properties: {
    scriptContent: '''
.create-or-alter workload_group ['default'] 
<<workgroupConfig>>
'''
    // 如果你的配置内容很长，也可以用scriptUrl指向存储账户里的脚本文件（ARM能通过内部网络访问存储）
    // scriptUrl: 'https://your-storage-account.blob.core.windows.net/scripts/workload-group-config.kql'
    forceUpdateTag: utcNow() // 用当前时间确保每次部署都会执行脚本，避免因资源无变化被跳过
  }
}

这里有几个关键细节需要注意：

• parent: adxCluster 明确了这个脚本是属于集群的资源，而非某个数据库，所以能执行集群级命令
• scriptContent 用三重引号包裹多行命令，保证格式正确
• forceUpdateTag 是个小技巧：如果你的脚本内容没有变化，ARM可能会跳过执行，用utcNow()每次部署都会生成新的标签，强制脚本执行

关于你担心的私网问题：
这个脚本是通过Azure Resource Manager（ARM）触发执行的，ARM和ADX都是Azure原生服务，它们之间的通信走Azure内部专用网络，完全不需要你的ADX集群暴露公网端点——这就避免了用Azure DevOps数据库任务需要公网访问的问题，完美契合你的需求。

最后提个权限要求：
部署这个Bicep的身份（比如Azure DevOps的服务连接账号）需要拥有ADX集群的Cluster Admin权限，这样才能执行修改工作负载组的集群级命令。

备注：内容来源于stack exchange，提问作者Ricconnect