跨Azure订阅的ADO Terraform Pipeline配置咨询：VM与DNS部署

一、两种Pipeline方案对比与推荐 #

1. 单Pipeline完成全部部署（推荐家庭项目使用） #

对于你的家庭项目场景，单Pipeline方案是更优选择，核心优势如下：

• 简洁易维护：所有操作在一个流程内完成，无需跨Pipeline触发，对刚接触ADO的新手友好，减少后续维护成本。
• 依赖关联可控：VM创建与DNS记录生成是强关联操作，单Pipeline能严格保证执行顺序（先创建VM获取IP，再生成DNS记录），避免异步触发可能出现的依赖失效问题。
• 资源统一管理：VM和DNS的Terraform代码可放在同一仓库的不同目录（如terraform-vm、terraform-dns），便于版本控制和变更追溯。

你可以基于现有配置补充完整执行步骤，示例如下：

# 第一步：部署Subscription-A中的虚拟机
- task: TerraformCLI@0
  displayName: 'VM Terraform Init'
  inputs:
    command: init
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform'
    backendType: azurerm
    backendServiceArm: sc-my-vm-subscription-A

- task: TerraformCLI@0
  displayName: 'VM Terraform Plan'
  inputs:
    command: plan
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform'
    backendType: azurerm
    backendServiceArm: sc-my-vm-subscription-A
    environmentServiceName: sc-my-vm-subscription-A

- task: TerraformCLI@0
  displayName: 'VM Terraform Apply'
  inputs:
    command: apply
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform'
    backendType: azurerm
    backendServiceArm: sc-my-vm-subscription-A
    environmentServiceName: sc-my-vm-subscription-A
    autoApprove: true

# 第二步：在Subscription-B中创建DNS A记录
- task: TerraformCLI@0
  displayName: 'DNS Terraform Init'
  inputs:
    command: init
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform-dns'
    backendType: azurerm
    backendServiceArm: sc-DNS-subscription-B

- task: TerraformCLI@0
  displayName: 'DNS Terraform Plan'
  inputs:
    command: plan
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform-dns'
    backendType: azurerm
    backendServiceArm: sc-DNS-subscription-B
    environmentServiceName: sc-DNS-subscription-B

- task: TerraformCLI@0
  displayName: 'DNS Terraform Apply'
  inputs:
    command: apply
    workingDirectory: '$(System.DefaultWorkingDirectory)/terraform-dns'
    backendType: azurerm
    backendServiceArm: sc-DNS-subscription-B
    environmentServiceName: sc-DNS-subscription-B
    autoApprove: true

注意：DNS的Terraform代码需要通过输出变量或Azure数据源获取VM的IP，确保记录能正确关联。

2. 单独搭建DNS Pipeline（适合未来复杂办公场景） #

如果未来办公环境中，DNS记录更新可能独立于VM部署（比如多服务共享DNS、DNS有单独变更流程），可考虑该方案：

• 职责解耦：VM部署与DNS管理分属独立Pipeline，适合大规模团队协作，各自负责专属业务域。
• 触发灵活：可通过ADO的Pipeline触发规则（如VM部署完成后自动触发、手动触发）实现异步执行。
  但该方案对新手维护成本较高，需配置跨Pipeline参数传递（如VM IP传递）、触发规则，家庭项目场景下无需引入此复杂度。

二、Azure/ADO家庭实验室蓝图建议 #

针对家庭项目，推荐以下简洁清晰的架构：

• 资源分层管理：
  • 用Azure管理组统一管理所有家庭订阅（Subscription-A、Subscription-B），便于权限控制和成本监控。
  • 按业务场景划分资源组（如rg-vm-lab、rg-dns-service），避免资源混乱。
• ADO结构规划：
  • 单个ADO项目管理所有实验室Pipeline，按功能划分文件夹（如VM部署、DNS管理、基础设施巡检）。
  • 统一使用Terraform作为IaC工具，所有代码放在同一Git仓库的不同目录，便于版本控制。
• 自动化扩展：
  • 新增成本监控Pipeline，定期导出Azure账单到存储账户，用Power BI做可视化分析。
  • 配置基础设施巡检Pipeline，自动检查VM状态、DNS记录有效性等。
• 安全配置：
  • 给ADO服务连接配置最小权限（如Subscription-A的服务连接仅拥有VM创建权限，Subscription-B的仅拥有DNS记录修改权限），遵循最小权限原则。
  • 开启Pipeline审批机制，重要操作（如Terraform Apply）需手动审批后执行。

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