如何基于Azure存储高效管理每条流水线的Terraform状态

开启Azure存储的ADLS2层级文件系统存储Terraform状态是完全可行的，已有大量生产环境落地案例。Azure存储开启ADLS2后依然完整兼容标准Blob REST API，Terraform官方azurerm后端不需要做任何特殊适配即可正常读写状态文件，状态锁、版本管理等核心功能也不受任何影响。

方案1：单存储容器 + 按Pipeline分目录（优先推荐） #

该方案是绝大多数场景的最优选择，优势包括：

• 运维成本低：无需动态创建/销毁容器，权限、备份、生命周期策略只需在容器层面统一配置一次，无需为每条Pipeline单独维护资源规则
• 成本更优：无额外的容器资源管理开销，可统一对全量状态文件配置冷存储归档、版本保留周期等规则，降低存储成本
• 扩展性好：目录结构可灵活扩展，后续可按业务线、部署环境做二级/三级目录拆分，比如/prod/支付业务/pipeline-003/terraform.tfstate，管理逻辑清晰
• 权限控制更精细：开启ADLS2后可配置目录级别的POSIX权限，针对不同团队的Pipeline做最小粒度的访问权限管控，比普通Blob的SAS权限配置更灵活

注意事项：

• 配置Terraform后端时直接把目录路径写在key参数中即可，无需额外适配，不同Pipeline的状态锁是单文件粒度，互相之间不会产生干扰

方案2：每条Pipeline独立存储容器 #

仅适合有极强安全隔离要求的特殊场景：

• 适用场景：不同Pipeline属于完全独立的业务主体，需要容器级别的独立审计日志、权限规则、生命周期策略
• 缺陷：运维成本高，需要额外维护容器的创建、销毁、权限配置逻辑，后续统一治理难度大，普通场景完全不需要选用该方案

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "tfstateadls2prod"
    container_name       = "tfstate-central"
    key                  = "pipeline-xxx/terraform.tfstate"
  }
}

• 存储账户必须开启软删除、版本控制、blob变更feed功能，防止状态文件被误删误改
• 禁止普通用户直接访问状态存储账户，所有读写操作都通过Pipeline的服务主体完成，配置最小化访问权限
• 不要在状态文件中存储明文敏感信息，配合Azure Key Vault管理密钥、密码等敏感配置

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