重跑vnet Bicep部署时如何保留NSG自定义规则避免业务停机？

你踩的是Bicep/ARM部署NSG的经典坑，核心原因是你把securityRules作为NSG父资源的内嵌属性定义了——这种写法下，每次部署NSG父资源，ARM会直接全量替换规则数组，所有不在模板内嵌列表里的规则都会被清除，和你选增量还是完整部署模式没有关系。以下是零停机的落地方案，按推荐优先级排序：

1. 最优方案：拆分NSG规则为独立子资源，解耦两个流程的部署边界 #

这个方案完全没有规则覆盖风险，也不存在任何业务停机空窗，是企业级IaC落地的标准做法：

• 调整网络部署的Bicep逻辑：
  • NSG父资源只保留位置、标签这类基础属性，彻底删掉模板里内嵌的securityRules数组块
  • 网络团队需要管控的通用基础规则（比如堡垒机放行、默认拦截规则等），全部定义为和NSG关联的独立securityRules子资源，规则优先级统一预留100-399号段，规则名加net-前缀做标识
• 调整应用部署的Bicep逻辑：
  • 不要去更新整个NSG对象，直接通过existing关键字引用已经存在的NSG
  • 应用需要的放行规则，全部作为独立的securityRules子资源部署在应用自己的发布流程里，规则名加app-<应用标识>-前缀，优先级统一用400以上的预留号段，避免和网络侧规则冲突
• 参考代码：
  网络侧NSG定义：

  // 仅定义NSG基础属性，不内嵌任何规则
  resource coreNsg 'Microsoft.Network/networkSecurityGroups@2024-01-01' = {
    name: 'core-shared-nsg'
    location: 'chinaeast3'
    tags: {
      managedBy: 'network-team'
    }
  }
  
  // 网络侧管控的基础规则，作为独立子资源声明
  resource allowBastionSsh 'Microsoft.Network/networkSecurityGroups/securityRules@2024-01-01' = {
    parent: coreNsg
    name: 'net-allow-bastion-ssh'
    properties: {
      priority: 200
      access: 'Allow'
      direction: 'Inbound'
      protocol: 'Tcp'
      sourcePortRange: '*'
      destinationPortRange: '22'
      sourceAddressPrefix: '10.0.1.0/24' // 堡垒机子网段
      destinationAddressPrefix: '*'
    }
  }
  

  应用侧规则定义：

  // 引用网络侧已部署好的共享NSG，不需要重新部署NSG本身
  resource coreNsg 'Microsoft.Network/networkSecurityGroups@2024-01-01' existing = {
    name: 'core-shared-nsg'
    resourceGroup: 'network-prod-rg'
  }
  
  // 应用专属放行规则，独立部署，不会被网络侧部署覆盖
  resource allowAppTraffic 'Microsoft.Network/networkSecurityGroups/securityRules@2024-01-01' = {
    parent: coreNsg
    name: 'app-orderapi-allow-http'
    properties: {
      priority: 501
      access: 'Allow'
      direction: 'Inbound'
      protocol: 'Tcp'
      sourcePortRange: '*'
      destinationPortRange: '8080'
      sourceAddressPrefix: '10.0.5.0/24' // 应用网关子网段
      destinationAddressPrefix: '10.0.10.0/24' // 应用自身子网段
    }
  }
  

• 这个模式下，两边部署流程只操作自己管控的规则子资源，互不干扰，不管重跑多少次网络部署，应用侧创建的规则都不会被删除，全程没有规则清空的空窗期。还可以配合RBAC做权限隔离：应用发布的服务主体只需要授予NSG规则子资源的写入权限，不需要整个NSG的编辑权限，权责边界非常清晰。
• 注意：网络侧的ARM/Bicep部署必须使用Incremental增量模式，禁止用Complete完整部署模式，否则完整模式会直接删除资源组下所有不在模板里的资源，还是会清掉应用侧的规则。

2. 备选方案：按子网拆分NSG所有权 #

如果团队权责划分清晰，也可以直接从资源层面拆分边界：

• 网络部署流程只负责VNet、基础设施子网（堡垒机、防火墙、网关等）以及对应子网的NSG，完全不碰业务应用所在子网的资源
• 应用部署流程全生命周期管理自己业务子网对应的NSG，从创建到规则更新全流程自主管控，网络侧部署根本不会触碰到这部分资源，从根源上避免覆盖问题。

不要用网络部署后读取规则重刷的方案，那个不仅会有几秒到几分钟不等的流量拦截空窗，还很容易因为规则读取不全、优先级冲突引出脏数据问题，属于典型的治标不治本。

内容的提问来源于stack exchange，提问作者JacksWastedLife