CDK栈依赖资源值/ARN生成网站配置脚本的处理方案咨询

业务场景约束 #

• 所有构造（Construct）默认部署在同一个CDK栈（Stack）中
• 网站A（Website A）的部署配套脚本A（Script A），需要依赖同栈内的构造A（Construct A）的资源值/ARN
• 部署顺序强约束：必须等网站A构建完成后，才能继续部署构造B、C、D
• 构建顺序强约束：网站A的构建必须依赖脚本A提前生成好的配置文件才能正常运行

核心疑问 #

• 该场景下是否必须将原有单栈拆分为栈A、栈B两个独立栈？哪怕实际仅需要提前部署单个构造即可生成所需配置脚本？
• 是否存在全链路自动化打通该流程的方案？
• 是否必须按照「先部署栈A、手动运行配置生成脚本、构建网站、再部署栈B」的手动分段流程执行？

完全不需要拆分单栈，也不需要走手动分段部署流程，通过CDK原生的依赖声明+生命周期触发能力即可实现全自动化流程，具体实现逻辑如下：

• 显式声明拓扑依赖，用CDK自带的addDependency()方法把整个部署流程的执行顺序锁死：
  • 构造A作为最前置节点，无前置依赖
  • 脚本A的执行触发器（推荐用CDK原生的Trigger构造或AwsCustomResource）依赖构造A，构造A部署完成后自动触发脚本A运行，脚本运行时可直接通过CDK Token引用构造A的ARN、资源属性，自动生成网站A所需的配置文件写入构建目录
  • 网站A的构建步骤（可通过静态网站部署构造的本地构建钩子、资产预构建逻辑实现）依赖脚本A的执行触发器，配置文件生成完成前不会启动网站构建
  • 构造B、C、D全部依赖网站A的构建部署产物，网站A部署完成前不会启动这三个构造的部署流程
• 如果你担心同栈内出现循环引用，可以把构造A+脚本A+配置生成的逻辑封装为独立的L3构造，内部闭环处理资源创建、配置生成的逻辑，对外只暴露网站构建所需的配置路径、依赖节点即可，不会出现依赖冲突。

不推荐拆栈的原因 #

• 拆栈会额外增加跨栈参数传递的复杂度，还需要维护多栈的部署版本一致性，反而提升运维成本
• 该场景下所有资源属于同一个部署生命周期边界，拆栈没有实际架构收益，仅为绕开手动流程拆栈属于过度设计
• 单栈配合显式依赖的实现方式，所有资源的更新、回滚、销毁逻辑都可以统一管控，变更审计、故障排查都更简单

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