如何使用单个cloudformation模板创建多个Elasticbeanstalk环境

Question

如何使用cloudformation在单个Elasticbeanstalk应用程序下创建多个环境。

我创建了一个cloudformation模板，该模板基本上通过提供必要的资源在AWS上创建了CI / CD管道。使用模板在同一弹性beantalk应用程序下创建多个环境（例如暂存和生产）时，我遇到问题。当我第一次部署模板（例如，暂存环境）时，它可以完美运行，但是在这种情况下，如果将其重新部署到生产环境中，则该模板将失败，并显示应用程序名称已存在的错误。我尝试使用cloudformation条件，但未成功。我想知道是否可以通过某种方式来检查是否存在类似的ApplicationName，它会跳过应用程序名称的创建并在该名称下创建环境。

    WebApplication:
        Type: AWS::ElasticBeanstalk::Application
        Properties:
          ApplicationName: !Sub "${GithubRepo}"
          Description: "Application Description"

      WebApplicationEnvironment:
        Type: AWS::ElasticBeanstalk::Environment
        Properties:
          ApplicationName: !Ref WebApplication
          EnvironmentName: !Sub "${GithubRepo}-${Stage}"
          TemplateName: !Ref WebApplicationTemplate

我希望在第二次运行模板时创建时，应在指定的应用程序中创建一个新环境。

Answer 1

  

我想知道是否可以通过某种方式来检查是否存在类似的ApplicationName，它会跳过应用程序名称的创建并在该名称下创建环境。

如果您愿意构建一个可以检查并返回可用于WebApplication中的条件值的自定义资源，则简单的答案是肯定的。但这是一个糟糕的主意，这就是原因：您的阶段堆栈的资源也将在生产中使用，但是由于您隐式地将它们堆叠在堆栈之间，因此cloudformation不知道如何处理更新。

如果要在WebApplication和WebApplicationEnvironment之间建立一对多关系，最好在不同的堆栈中创建它们。您可以使用堆栈导出将一个堆栈的数据公开到另一个堆栈。堆栈导出将保护您避免意外更改其他堆栈所依赖的资源。

但是对您而言，更好的方法可能是为每个环境创建两个完全不同的堆栈。否则，您将无法测试产品升级过程（升级阶段时，将升级产品）。

如果您真的想削减成本，则将所有环境放在同一堆栈中。如果您仍然无法使用它们来保持不同的环境与众不同，那么共享堆栈要比在堆栈之间隐式共享资源更好。