CloudFormation更新Elastic Beanstalk环境时如何避免回滚已部署ApplicationVersion？

嘿，我之前也踩过CloudFormation和Elastic Beanstalk版本管理的坑，给你分享下实用的解决方案：

一、为什么更新栈会把ApplicationVersion回滚到初始版本？ #

这是因为CloudFormation的核心逻辑是维护资源状态与模板定义的一致性。如果你的模板里硬编码了AWS::ElasticBeanstalk::ApplicationVersion的SourceBundle路径或版本名称，哪怕你后来通过CodePipeline部署了新的版本，CloudFormation在栈更新时会检测到这个资源的实际状态和模板不一致，就会强制把它改回模板里的初始配置——这就是你看到的回滚现象。

解决回滚问题的具体方法： #

• 方法1：不让CloudFormation管理ApplicationVersion
  把ApplicationVersion的创建和部署交给CodePipeline等外部工具，然后在CloudFormation的Elastic Beanstalk环境资源（AWS::ElasticBeanstalk::Environment）里，通过VersionLabel属性直接引用已经存在的版本名称（可以用栈参数传入，或者从其他栈的输出值获取）。这样CloudFormation只会管理环境的基础设施配置，不会干涉版本的变更。
• 方法2：动态管理模板里的ApplicationVersion
  如果一定要在模板里定义ApplicationVersion，别写死SourceBundle的路径或版本号，改用栈参数或者外部输出值来动态传入。示例代码：

  Parameters:
    AppVersionS3Bucket:
      Type: String
    AppVersionS3Key:
      Type: String
  Resources:
    MyAppVersion:
      Type: AWS::ElasticBeanstalk::ApplicationVersion
      Properties:
        ApplicationName: !Ref MyApplication
        SourceBundle:
          S3Bucket: !Ref AppVersionS3Bucket
          S3Key: !Ref AppVersionS3Key
  

  每次更新栈时，如果不需要变更版本，就保持这两个参数的值和当前运行的版本一致，CloudFormation就不会修改ApplicationVersion。另外可以给这个资源加上DeletionPolicy: Retain，防止栈删除时误删版本，但核心还是避免硬编码。

二、能否在CloudFormation中更新Elastic Beanstalk环境而不影响已部署的版本？ #

当然可以！关键是把环境配置和应用版本的管理解耦，具体做法：

• 方案1：移除模板中的ApplicationVersion资源
  完全用外部工具（CodePipeline、AWS CLI等）管理ApplicationVersion，然后在CloudFormation的环境资源里，将VersionLabel设置为当前正在运行的版本名称（可以用参数固定，或者通过Fn::ImportValue从其他栈导入）。之后你更新栈修改任何基础设施配置（比如实例类型、环境变量、负载均衡配置等），CloudFormation只会更新环境的这些配置项，不会触碰应用版本。
• 方案2：使用配置模板分离配置与版本
  创建AWS::ElasticBeanstalk::ConfigurationTemplate资源来管理环境的配置参数，然后在环境资源中引用这个模板。当你需要更新环境配置时，只修改配置模板的内容，CloudFormation会把新配置应用到环境，但不会改变当前的VersionLabel，也就不会影响已部署的版本。
• 注意事项
  如果你之前的模板里已经有ApplicationVersion资源，建议先把环境的VersionLabel手动更新到当前运行的版本，然后再从模板中移除ApplicationVersion资源，之后的栈更新就不会再影响版本了。

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