问可以在Cloudformation中更新Elastic Beanstalk环境而不影响部署到它的版本吗？

EN

CloudFormation想要掌控一切。根据您执行的堆栈更新，CloudFormation将根据模板中定义的内容重新创建版本。

执行以下操作，而不是将您的版本从代码管道直接部署到Elastic Beanstalk：

1. 不要将初始版本硬编码到您的CloudFormation模板中。
2. 将部署的版本与CloudFormation堆栈的输入参数挂钩。例如，将输入参数设置为版本内部版本号，并在模板中构造一个指向该参数的URL作为版本源。
3. 在部署时，指示代码管道使用更新后的内部版本号更新堆栈。CloudFormation应该会通过构建新的网址并部署版本来接管工作。

一个例子：

假设堆栈中有一个参数ZipBucket和ZipObject，您可以在AWS::ElasticBeanstalk::ApplicationVersion资源上执行以下操作：

"SourceBundle"    : {
    "S3Bucket" : {
        "Ref" : "ZipBucket"
    },
    "S3Key"    : {
        "Ref" : "ZipObject"
    }
}

另一种选择是使用一个BuildNumber参数，然后在S3Key属性中使用Fn::Join从内部版本号中构建一个S3Key。

我一直在尝试Elastic Beanstalk，CodePipeline和CloudFormation，并找到了一种方法来实现你想要的东西(我想)。

我使用CloudFormation命令行(create-stack)和命令行中的单个模板来创建：

• 使用"Hello，World“应用程序的初始弹性豆茎应用程序和环境，该应用程序之前已上载到S3 bucket
• 用于GitHub集成的web钩子
• A CodePipeline continuous delivery pipeline

堆栈创建成功了，我最初在Elastic Beanstalk上运行了我的"Hello，World“应用程序。然后，我可以通过GitHub web钩子和CodePipeline部署我的实际应用程序，它覆盖了占位符应用程序。

我担心当我对环境进行更改(再次使用CloudFormation CLI，这次使用create-change-set和execute-change-set)时，我会重新部署“你好，世界”应用程序并覆盖我真正的应用程序，但事实并非如此。我的GitHub源应用程序仍然是在应用更改集之后部署的应用程序。请注意，对AWS::ElasticBeanstalk::ApplicationVersion的更改将导致在Elastic Beanstalk上部署新的应用程序，并覆盖实际版本。

这是一个不完美的解决方案，我不确定为什么AWS会这样设计Elastic Beanstalk-CloudFormation-CodePipeline集成，而且在部署真正的应用程序之前，必须先部署一个虚拟应用程序，这感觉很奇怪。我在Lambdas上也遇到过类似的问题，所以我猜这是由于设计而不是疏忽造成的。

上面给出的答案似乎是不正确的-或者可能是AWS自编写以来发生了一些变化。

根据我的经验，对AWS::ElasticBeanstalk::ApplicationVersion中的SourceBundle进行任何更改(无论资源是单独声明的还是作为AWS::ElasticBeanstalk::Application的ApplicationVersions参数的一部分声明的)都会导致执行变更集时出错。我得到的错误是“你不能更新ApplicationVersions”。我是否更改描述似乎并不重要。

到目前为止，我能想到的唯一解决方案就是将我的SourceBundle指向一个不会改变的url。例如，用于开发环境的develop，用于生产的main。在发布任何可能导致重新部署版本的更改集之前，我只需要确保我的最新代码部署在那里。

如果我在这里遗漏了什么，我很想了解我的方法是否可以改进。