在Elastic Beanstalk中提交.elasticbeanstalk / config.yml

Question

在使用.elasticbeanstalk/config.yml的项目的git仓库中提交eb deploy是一种好方法吗？

我们希望使用CI进行部署，因此我们无法使用交互式eb init。 我们现在想的是在config.yml中定义我们的dev，uat和prod（如果可能的话）并使用eb deploy指向该环境。

我们看到我们可以在ebcli版本2中执行eb init所有必需参数但不再在版本3中执行了吗？所以看来这种方法有所改变吗？

有人可以解释如何在没有互动的情况下为多个环境部署EB吗？

Answer 1

EB CLI实际上是用于工作站的。我认为您最好使用AWS CLI编写CI脚本。

使用eb deploy的部署将在S3（或CodeCommit）中归档您的代码，创建新的应用程序版本，然后使用新版本标签更新环境。 AWS CLI命令支持所有这些操作。

或者，您可以使用boto3在Python中编写自己的部署脚本。这也是一个简单的选择。这基本上就是EB CLI。

Answer 2

  

  
1. 我们希望使用CI进行部署，因此我们无法使用交互式allTransactions
  

您可以按如下方式禁止交互模式：

eb init

  

  
1. 在使用eb deploy的项目的git repo中提交.elasticbeanstalk / config.yml是一个好方法吗？
  
2. 有人可以解释如何在没有互动的情况下为多个环境部署EB吗？
  

按照设计，EBCLI避免提交eb init --platform <platform-name> --region <region-name> <application-name> 目录，因为它可以包含特定于开发人员的信息，这些信息在提交给VC时会引起混淆。因此，最好从VC中避免。您可以将其提交到版本控制。确保此处没有敏感信息。日志和保存的配置通常存储在.elasticbeanstalk/。

中

1. 您可以将.elasticbeanstalk/文件的相关部分复制到根级文件中，CI可以从中读取信息，例如要使用的环境名称。
2. 在本地，你可以创建一个预提交Git钩子，它将.elasticbeanstalk/config.yml文件中的默认环境名称读入根级文件 - 让我们称之为.elasticbeanstalk/config.yml。它可以是一个简单的声明.environment_config.sh

3. 在CI服务器上：

   3.1。确保PWD为export BEANSTALK_ENVIRONMENT_NAME=<environment name from .elasticbeanstalk/config.yml> - ed。像Jenkins这样的系统通常git init具有必要的分支，因此此时CI只能git init-ed并加载要部署的环境名称。

   3.2。 source .environment_config.sh

   3.3。 eb init --platform <platform-name> --region <region-name> <application-name>

   3.4。 eb use $BEANSTALK_ENVIRONMENT_NAME

（您可以通过执行eb deploy来结合3.3。和3.4。我只是想演示eb deploy $BEANSTALK_ENVIRONMENT_NAME）的使用