如何处理Pulumi创建后转由其他系统管理的资源冲突问题

针对ECS蓝绿部署场景下Pulumi配置漂移冲突问题，有3种官方推荐的规范处理方案，按适配优先级排序如下：

• 首选方案：使用ignoreChanges参数忽略指定字段的外部变更
  这是最适配当前场景的方案，不需要将整个资源移出Pulumi管理，仅需声明哪些字段会被外部系统（CodeDeploy蓝绿控制器）修改，Pulumi后续对比配置漂移时会直接跳过这些字段。
  以ALB Listener资源为例，CodeDeploy每次蓝绿切换仅会修改Listener的defaultActions字段（调整转发绑定的目标组），你只需要在Pulumi的Listener资源定义中添加ignoreChanges配置即可：

  // TypeScript 示例，其他语言语法类似
  const appListener = new aws.alb.Listener("app-listener", {
    loadBalancerArn: loadBalancer.arn,
    port: 80,
    protocol: "HTTP",
    defaultActions: [{
      type: "forward",
      targetGroupArn: initialTargetGroup.arn,
    }],
  }, {
    // 忽略defaultActions字段的外部变更，不触发修复逻辑
    ignoreChanges: ["defaultActions"]
  });
  

  该方案的优势是Pulumi仍会管理资源的其他配置（如端口、协议、安全组绑定等），仅屏蔽会和外部系统冲突的字段校验，兼顾管理能力和部署兼容性。

• 次选方案：使用retainOnDelete参数完全移交资源管理权
  如果你确定后续该资源的所有配置都完全交由其他系统管理，Pulumi不再负责任何更新操作，可以通过该规范方式将资源移出Pulumi状态，且不会删除云上实际资源：

  1. 在对应资源的Pulumi定义中添加retainOnDelete: true配置
  2. 将该资源的定义从Pulumi代码中删除
  3. 执行pulumi up，Pulumi会自动将该资源从状态文件中移除，且保留云上实际运行的资源
     该方案比手动执行pulumi state delete更规范，所有操作都有代码提交记录可审计，团队成员可以明确感知该资源已移交管理权限。

• 场景适配方案：将蓝绿部署逻辑纳入Pulumi管理
  针对ECS+CodeDeploy蓝绿的特定场景，Pulumi官方提供了对应的集成组件，可以将蓝绿切换的逻辑也纳入Pulumi的管理范围，避免外部系统修改Pulumi管理的资源，从根源上消除配置漂移冲突的可能，你可以根据现有流水线的改造成本选择是否采用该方案。

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